Perché aggiungiamo metodi di istanza alle classi? [chiuso]

Una grande ragione è il polimorfismo (non l'ereditarietà, che è solo una forma di polimorfismo).

Considera il seguente esempio:

interface Payable {
  ...
  double calculatePay();
  ...
}

public class HourlyEmployee implements Payable {
  ...
  public double calculatePay() {
    return hourlyRate * timeCards.totalHoursWorked();
  }
  ...
}

public class SalariedEmployee implements Payable {
  ...
  public double calculatePay() {
    return salary;
  }
  ...
}

public class PayRun {
  ...
  private PaySlip buildPaySlip(Payable payable) {
    PaySlip paySlip = new PaySlip();
    ...
    paySlip.setGrossPay(payable.calculatePay());
    ...
    return paySlip;
  }
  ...
}

Se i metodi di istanza erano solo funzioni che ricevevano l'oggetto come parametro nascosto, il codice sopra non funzionava. Il chiamante del metodo calculatePay dovrebbe conoscere quali tipi di oggetti Payable esistono per chiamare la funzione corretta. Con OO, questa conoscenza non è necessaria, quindi l'oggetto PayRun è in grado di generare PaySlips per qualsiasi tipo di oggetto Payable . Possiamo aggiungere CommissionedEmployee o qualsiasi altro tipo senza modificare il core del processo di gestione stipendi.

Naturalmente, il polimorfismo non è nemmeno vicino all'essere esclusivi di OO. Tuttavia, è un concetto inserito nel nucleo del paradigma (e dei linguaggi correlati), che lo rende una caratteristica di prima classe invece di solo qualcosa che puoi ottenere (di solito facendo le cose in modo scortese e non univoco , come i tavoli virtuali in C). Tuttavia, critico i linguaggi tipizzati staticamente come Java e C ++ come troppo restrittivi sul polimorfismo. Le lingue che supportano a buon mercato digitazione anatra sono argomenti di studio migliori per comprendere il ragionamento alla base di OO.

Non sottovalutare il potere della convenzione. Se tutti fanno le cose allo stesso modo, rende i grandi programmi più mantenibili.

Il tuo esempio %codice% sembra solo più semplice perché hai sorvolato i dettagli. Non hai effettivamente indicato dove vengono inizializzati i dati di StaticLib.Something(...some parameters...); , né li hai passati alla funzione MyStruct .

Suppongo che tu stia facendo una programmazione strutturata, piuttosto che un codice procedurale con migliaia di variabili dappertutto. Se vogliamo programmare strutturati, dobbiamo archiviare i dati del programma in una raccolta di strutture / classi. Tutte le linee guida di programmazione popolari insistono sul fatto che i dati devono essere inizializzati prima di essere utilizzati. Supponiamo quindi di avere una struttura MyClass per contenere dati su qualcosa. Abbiamo bisogno di creare la struttura e inizializzarla a uno stato conosciuto.

MyClass o = StaticLib.CreateMyClass(... initial state ...);

o forse

MyClass o; StaticLib.InitMyClass(o, ... initial state...);

Ora vogliamo fare qualcosa con Something .

StaticLib.Something(o, ...some parameters...);

Metti insieme e ottieni

MyClass o = StaticLib.CreateMyClass(... initial state ...);
StaticLib.Something(o, ...some parameters...);

A quel punto, si potrebbe anche fare il "modo orientato agli oggetti", e basta scrivere

MyClass o = new MyClass(... initial state ...);
o.Something(... some parameters...);

La programmazione orientata agli oggetti offre naturalmente una migliore struttura del programma. La definizione della struttura dei dati è sempre strettamente associata alle funzioni che operano su di esso. È più semplice da gestire rispetto a una definizione di una struttura dati in un posto e una libreria di funzioni che operano su di esso da qualche altra parte.

E infine, sembra più bello scrivere

lion.Roar(LOUDLY);

di

Animals.Roar(lion, LOUDLY);

Penso che potrebbe essere correlato a Java, dove tutto deve essere in una classe (anche quando, come fai notare, non è mai in un'istanza di una classe).

C ++ consente le normali funzioni, ma mantiene anche la parola chiave statica utilizzata per limitare l'ambito di una variabile o funzione al file contenente. Il C ++ ha mantenuto questo significato ma ha modificato l'ambito della classe contenente, anche questo è più una cosa dello spazio dei nomi, poiché è ancora necessario allocare esternamente lo spazio di archiviazione per esso.

Questa è una buona ragione per cui è stata fatta - per limitare l'ambito di definizione, quindi qualcuno che legge il tuo codice sa che una variabile o funzione statica è riferita solo all'interno (o in relazione a) di una particolare classe, anche se non è legata a istanze individuali.

Una volta rimosso il dispatch dinamico dal mix, la risposta è che non esiste alcuna ragione, oltre alla convenzione, che lo facciamo in questo modo.

In inglese, leggiamo / scriviamo da sinistra a destra. Perché? Nessun motivo diverso dalla convenzione. Ho l'impressione che tu stia procedendo troppo in fretta a scartare le convenzioni. Il codice convenzionale è più facile da scrivere, più facile da leggere e più facile da mantenere ...

a = b.c(d, e).f(g).h()

vs

a = h(f(c(b, d, e), g))

Il primo legge più naturalmente da sinistra a destra rispetto al secondo. Dal momento che noi madrelingua inglesi siamo abituati a leggere da sinistra a destra fin da un'età molto giovane, una tale costruzione rende il primo più facile da leggere e scrivere.

Nel primo caso non ci sono parentesi nidificate. Per questo motivo, è meno probabile che ne mettiamo troppi o troppo pochi, e possiamo vedere più facilmente che i paren sono equilibrati. Questo rende il primo più facile da scrivere e leggere.

Quando il codice è più facile da leggere, è più facile da mantenere e capire. Quando è più facile scrivere, è più probabile che venga scritto correttamente la prima volta.

Fai ai tuoi amici, incluso il tuo futuro, un favore e rendi il tuo codice più facile da leggere e scrivere.