Perché vedo tante classi istanziabili senza stato?

Sto vedendo molte classi istanziabili nel mondo C ++ e Java che non hanno alcuno stato.

Non riesco davvero a capire perché le persone lo facciano, potrebbero semplicemente usare uno spazio dei nomi con funzioni gratuite in C ++ o una classe con un costruttore privato e solo metodi statici in Java.

L'unico vantaggio che mi viene in mente è che non è necessario modificare la maggior parte del codice se in seguito si decide che si desidera un'implementazione diversa in determinate situazioni. Ma non è un caso di design prematuro? Potrebbe essere trasformato in una classe in seguito, quando / se diventa appropriato.

Sto sbagliando? Non è OOP se non metto tutto negli oggetti (ad es. Classi istanziate)? Allora perché ci sono così tanti spazi dei nomi e classi di utilità nelle librerie standard di C ++ e Java?

Aggiornamento: ho sicuramente visto molti esempi di questo nei miei precedenti lavori, ma sto lottando per trovare esempi open source, quindi forse non è poi così comune. Tuttavia, mi chiedo perché la gente lo faccia e quanto sia comune.

Sto vedendo molte classi istanziabili nel mondo C ++ e Java che non hanno alcuno stato.

Alcuni possibili motivi per creare lezioni senza i loro propri:

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

• La classe implementa alcune interfacce e deve essere istantanea in modo che le istanze possano essere passate ad altri oggetti.

• La classe deve essere sottoclassata.

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

Sto sbagliando? Non è OOP se non metto tutto negli oggetti (cioè le classi istanziate)?

OOP è un paradigma, non una legge della natura. Ci sono alcune lingue in cui tutto è un oggetto, quindi non hai davvero scelta. Altre lingue (ad es. 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 classe ... potresti dire che hai solo meno OOP in quel caso.

Caleb e Robert Harvey hanno già sottolineato quali sono le classi di utilità e alcuni motivi legittimi per avere classi "senza dati". Queste descrizioni sono esatte, ma trattano degli aspetti positivi.

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

Un gran numero di tali classi (in particolare quelle con un solo metodo) indicano che i progettisti stanno pensando a testa in giù, vale a dire. pensando a ciò che può essere fatto a un oggetto piuttosto che a ciò che può fare l'oggetto.

Se stai affermando 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 con cui lavorare. Basta non pretendere di seguire l'uno, mentre implementare con tutto il cuore l'altro.

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 semplicemente restituiscono un valore. A tale proposito, questi metodi possono essere considerati una forma grezza di programmazione funzionale, con tutti i suoi vantaggi (nessun problema con la concorrenza, per prima cosa).

In ogni caso, queste classi servono solo a raggruppare i metodi correlati in un singolo contenitore, metodi che non richiedono l'istanza di un oggetto per funzionare correttamente. Un esempio di tale classe è una classe di matematica contenente 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 più istanze simultanee per essere attive. Ad esempio un bean di sessione senza stato che interagisce con una procedura memorizzata del database, passando i dati in arrivo a un pacchetto PL / SQL e restituendo 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 istantanea una classe.

Per alcune classi è improbabile che siano necessarie le capacità concesse dall'istanza. Probabilmente non sarà necessario scambiare un'implementazione di Cosine con un'altra, per esempio. Si scopre che per lo più sono funzioni di utilità che non richiedono queste funzionalità, quindi sono principalmente funzioni di utilità che hanno classi che non sono istanziabili.