È buona pratica avvolgere tutti i primitivi e le stringhe? [duplicare]

Immagina una situazione in cui hai un tipo di base:

int distanceInKm;

Questo è in molti, molti posti nel tuo codice.

Un giorno Mr Client viene da te e dice: "Vorremmo che tutto fosse visualizzato in miglia ora, per favore".

Ora devi cambiare ovunque si usi distanceInKm.

Ora immagina una situazione alternativa in cui hai il tuo tipo:

class Distance
{
    private int _distanceInKm;

    public string DescriptionOfDistance()
    {
        return ...;
    }
}

Ora hai solo bisogno di cambiare un posto per far visualizzare tutto in miglia.

Come @DanielFisherlennybacon ha menzionato nei commenti, è necessario essere pragmatici su quando applicare le "regole" della programmazione. In questo caso specifico, vale la pena notare che Object Calisthenics è un esercizio per allungare i muscoli di programmazione. I maratoneti eseguono scatti in allenamento per migliorare la loro velocità di base; non significa che debbano correre per tutta la gara.

In effetti, l' articolo afferma ripetutamente che è non il migliore pratica per avvolgere ciecamente tutti i primitivi:

The Challenge Do a simple project using far stricter coding standards than you’ve ever used in your life. Below, you’ll find 12 “rules of thumb” that will help push your code into good object-oriented shape.

By suspending disbelief, and rigidly applying these rules on a small, 1000 line project, you’ll start to see a significantly different approach to designing software. Once you’ve written 1000 lines of code, the exercise is done, and you can relax and go back to using these 12 rules as guidelines.

This is a hard exercise, especially because many of these rules are not universally applicable. The fact is, sometimes classes are a little more than 50 lines. But there’s great value in thinking about what would have to happen to move those responsibilities into real, first-class-objects of their own. It’s developing this type of thinking that’s the real value of the exercise. So stretch the limits of what you imagine is possible, and see whether you start thinking about your code in a new way.

Perché dovresti pubblicare una domanda che ti chiede di spiegare un articolo che non hai letto?

Ecco cosa dice:

Rule 3: Wrap all primitives and Strings In the Java language, int is a primitive, not a real object, so it obeys different rules than objects. It is used with a syntax that isn’t object-oriented. More importantly, an int on its own is just a scalar, so it has no meaning. When a method takes an int as a parameter, the method name needs to do all of the work of expressing the intent. If the same method takes an Hour as a parameter, it’s much easier to see what’s going on. Small objects like this can make programs more maintainable, since it isn’t possible to pass a Year to a method that takes an Hour parameter. With a primitive variable the compiler can’t help you write semantically correct programs. With an object, even a small one, you are giving both the compiler and the programmer additional info about what the value is and why it is being used.

Small objects like Hour or Money also give us an obvious place to put behavior that would otherwise have been littered around other classes. This becomes especially true when you apply the Rule X, and only the small object can access the value.

La risposta di Scroog1 copre l'aggiunta di contesto a un valore. Un altro esempio: dì che hai

public void SubmitOrder(int productId, int customerId) { ... }

quindi c'è sempre la possibilità che tu lo chiami così:

processor.SubmitOrder(customerId, productId);

Ouch. Speriamo che tu abbia scritto un test unitario per verificare quale valore è stato superato in quale luogo. Ma se definisci:

public void SubmitOrder(ProductID pid, CustomerID cid) { ... }

allora il compilatore ti impedirà di sbagliare. Per un piccolo progetto questo potrebbe essere eccessivo; per una grande in cui gli insetti hanno conseguenze di vita o di morte, potrebbe benissimo impedirti di avere notti insonni.

No vivamente. Assolutamente no. È una cattiva idea per la stessa ragione per cui if(boolValue==true) è una cattiva idea. Se fosse una buona idea, farlo due volte sarebbe ancora meglio: if((boolValue==true)==true) o WrappedWrappedString . Ma un booleano è già un booleano e una stringa è già un'astrazione che racchiude un contenitore di caratteri.

Un modello di progettazione di successo modifica un componente primitivo per eseguire un'attività correlata ma diversa. Un modello di progettazione che modifica un componente primitivo per eseguire la stessa attività non aggiunge valore e causa confusione completamente evitabile.