Perché vedo così tante classi istantanee senza stato?

I'm seeing a lot of instantiable classes in the C++ and Java world that don't have any state.

Alcuni possibili motivi per creare classi senza ivars:

• Lo stato è o potrebbe essere contenuto in una superclasse.

• La classe implementa un'interfaccia e deve essere istantanea in modo che le istanze possano essere passate ad altri oggetti.

• La classe è destinata alla sottoclasse.

• Modo pratico per raggruppare le funzioni correlate. (Sì, potrebbero esserci modi migliori o diversi per fare lo stesso.)

Am I getting this wrong? Is it not OOP if I don't put everything into objects (i.e. instantiated classes)?

OOP è un paradigma, non una legge della natura. Ci sono alcune lingue in cui tutto è un oggetto, quindi in realtà non hai scelta. Altre lingue (ad esempio C) non forniscono alcun supporto per OOP, ma è comunque possibile programmare in uno stile orientato agli oggetti. Direi che puoi avere OOP se non fai tutto in classi ... potresti dire che hai solo less OOP in quel caso.

Caleb e Robert Harvey hanno già indicato quali sono le classi di utilità e alcuni motivi legittimi per avere classi "senza dati". Queste descrizioni sono azzeccate, ma gestiscono gli aspetti positivi.

Vorrei solo menzionare che l' abuso delle classi di utilità può sicuramente essere un anti-pattern OO (vedi descrizione di c2wiki ). Questa citazione lo riassume bene:

A large number of such classes (particularly those with only a single method) indicates that the designers are thinking upside-down, ie. thinking of that which can be done to an object rather than that which can done by the object.

Se stai sostenendo di praticare la progettazione orientata agli oggetti, ma la tua base di codice è composta quasi interamente da classi di utilità, direi che stai sicuramente facendo qualcosa di sbagliato. Detto questo, un approccio funzionale ha altrettanti meriti e può anche essere eccellente. Semplicemente non pretendere di seguire l'uno, mentre implementa l'altro a metà.

Le classi di utilità in Java e C ++ vengono utilizzate per mantenere una libreria di metodi che accettano uno o più parametri di input e restituiscono un risultato. Non hanno bisogno di mantenere lo stato, se restituiscono semplicemente un valore. A tale riguardo, questi metodi possono essere considerati come una forma grezza di programmazione funzionale, con tutti i suoi vantaggi (nessun problema con la concorrenza, per una cosa).

In ogni caso, queste classi servono solo a raggruppare i metodi correlati in un singolo contenitore, metodi che non richiedono che l'istanziazione di un oggetto funzioni correttamente. Un esempio di tale classe è una classe Math contenente le funzioni SINE e COSINE (e altre funzioni matematiche).

Molte di queste classi interagiscono con i dati, anche se non li contengono esplicitamente e devono farlo in modi che richiedono l'attivazione di più istanze simultanee. Per esempio. un bean di sessione stateless che interagisce con una stored procedure del database, trasferendo i dati in ingresso in alcuni pacchetti PL / SQL e trasferendo i risultati all'applicazione chiamante. Quella cosa deve esistere in più istanze, ma non contiene alcun campo dati.

Nei linguaggi orientati agli oggetti in cui le classi non sono oggetti, puoi fare molto di più con un oggetto che con una classe.

Puoi passare un oggetto come parametro, puoi sostituire un oggetto compatibile di tipo, puoi implementare un'interfaccia (immagino ci siano linguaggi in cui le classi sono oggetti ma puoi fare alcune di queste cose, ma in ogni caso. ..). Tutte queste cose sono piuttosto importanti quindi la decisione di default è di solito rendere una classe istantanea.

Per alcune classi sembra improbabile che siano necessarie le capacità offerte dall'istanziazione. Ad esempio, probabilmente non sarà necessario sostituire un'implementazione di Cosine con un'altra. Risulta che sono per lo più funzioni di utilità che non hanno bisogno di queste funzionalità, quindi sono per lo più funzioni di utilità che hanno classi che non sono istantanee.