Le classi con un solo metodo (pubblico) sono un problema?

Attualmente sto lavorando a un progetto software che esegue compressione e indicizzazione su filmati di videosorveglianza. La compressione funziona dividendo gli oggetti di sfondo e di primo piano, quindi salvando lo sfondo come immagine statica e il primo piano come uno sprite.

Di recente, ho iniziato a rivedere alcune delle classi che ho progettato per il progetto.

Ho notato che ci sono molte classi che hanno un solo metodo pubblico. Alcune di queste classi sono:

• VideoCompressor (con un compressmetodo che accetta un video di input di tipo RawVideoe restituisce un video di output di tipo CompressedVideo).
• VideoSplitter (con un splitmetodo che accetta un video di input di tipo RawVideoe restituisce un vettore di 2 video di output, ciascuno di tipo RawVideo).
• VideoIndexer (con un indexmetodo che accetta un video di input di tipo RawVideoe restituisce un indice video di tipo VideoIndex).

Mi ritrovo a un'istanza di ogni classe solo per fare chiamate come VideoCompressor.compress(...), VideoSplitter.split(...), VideoIndexer.index(...).

In apparenza, penso che i nomi delle classi siano sufficientemente descrittivi della loro funzione prevista, e in realtà sono nomi. Di conseguenza, anche i loro metodi sono verbi.

Questo è davvero un problema?

No, questo non è un problema, al contrario. È un segno di modularità e chiara responsabilità della classe. L'interfaccia lean è facile da capire dal punto di vista di un utente di quella classe e incoraggerà un accoppiamento lento. Questo ha molti vantaggi ma quasi nessun inconveniente. Vorrei che più componenti fossero progettati in questo modo!

Non è più orientato agli oggetti. Poiché quelle classi non rappresentano nulla, sono solo vasi per le funzioni.

Ciò non significa che sia sbagliato. Se la funzionalità è sufficientemente complessa o quando è generica (ovvero gli argomenti sono interfacce, non tipi finali concreti), ha senso mettere quella funzionalità in un modulo separato .

Da lì dipende dalla tua lingua. Se la lingua ha funzioni gratuite, dovrebbero essere moduli che esportano funzioni. Perché fingere che sia una classe quando non lo è. Se la lingua non ha funzioni gratuite come ad esempio Java, allora si creano classi con un singolo metodo pubblico. Bene, questo mostra solo i limiti del design orientato agli oggetti. A volte funzionale è semplicemente la migliore corrispondenza.

C'è un caso in cui potresti aver bisogno di una classe con un singolo metodo pubblico perché deve implementare l'interfaccia con un singolo metodo pubblico. Sia per modello di osservatore o iniezione di dipendenza o altro. Anche in questo caso dipende dalla lingua. Nei linguaggi con funzioni di prima classe (C ++ ( std::functiono parametro modello), C # (delegato), Python, Perl, Ruby ( proc), Lisp, Haskell, ...) questi schemi usano tipi di funzione e non hanno bisogno di classi. Java non ha (ancora, sarà nella versione 8) i tipi di funzione, quindi usi interfacce a metodo singolo e corrispondenti classi a metodo singolo.

Ovviamente non sto sostenendo di scrivere un'unica enorme funzione. Dovrebbe avere subroutine private, ma possono essere private nel file di implementazione (spazio dei nomi statico o anonimo a livello di file in C ++) o in una classe di supporto privata che viene istanziata solo all'interno della funzione pubblica ( per archiviare o meno i dati? ).

Ci possono essere motivi per estrarre un determinato metodo in una classe dedicata. Uno di questi motivi è consentire l'iniezione di dipendenza.

Immagina di avere una classe chiamata VideoExporterche, alla fine, dovrebbe essere in grado di comprimere un video. Un modo pulito sarebbe avere un'interfaccia:

interface IVideoCompressor
{
    Stream compress(Video video);
}

che sarebbe implementato in questo modo:

class MpegVideoCompressor : IVideoCompressor
{
    // ...
}

class FlashVideoCompressor : IVideoCompressor
{
    // ...
}

e usato così:

class VideoExporter
{
    // ...
    void export(Destination destination, IVideoCompressor compressor)
    {
        // ...
        destination = compressor(this.source);
        // ...
    }
    // ...
}

Una cattiva alternativa sarebbe quella di avere un VideoExportermetodo che ha molti metodi pubblici e fa tutto il lavoro, compresa la compressione. Diventerebbe rapidamente un incubo per la manutenzione, rendendo difficile aggiungere supporto per altri formati video.

Questo è un segno che si desidera passare funzioni come argomenti ad altre funzioni. Immagino che la tua lingua (Java?) Non la supporti; in tal caso, non è tanto un fallimento nel tuo design quanto è un difetto nella tua lingua preferita. Questo è uno dei maggiori problemi con le lingue che insistono sul fatto che tutto deve essere una classe.

Se in realtà non stai passando queste funzioni false, allora vuoi solo una funzione libera / statica.

So di essere in ritardo alla festa, ma come sembra che tutti abbiano perso di sottolineare questo:

Questo è un modello di design ben noto chiamato: Pattern di strategia .

Il modello di strategia viene utilizzato quando esistono diverse possibili strategie per risolvere un sotto-problema. In genere si definisce un'interfaccia che impone un contratto su tutte le implementazioni e quindi si utilizza una forma di Iniezione delle dipendenze per fornire la strategia concreta per l'utente.

Ad esempio in questo caso potresti avere interface VideoCompressore quindi avere diverse implementazioni alternative per esempio class H264Compressor implements VideoCompressore class XVidCompressor implements VideoCompressor. Dall'OP non è chiaro che sia coinvolta un'interfaccia, anche se non lo è, potrebbe semplicemente essere che l'autore originale abbia lasciato la porta aperta per implementare il modello di strategia, se necessario. Che di per sé è anche un buon design.

Il problema che OP si trova costantemente a istanziare le classi per chiamare un metodo è un problema con lei che non usa correttamente l'iniezione di dipendenza e il modello di strategia. Invece di istanziarlo dove serve, la classe contenente dovrebbe avere un membro con l'oggetto strategia. E questo membro dovrebbe essere iniettato, ad esempio nel costruttore.

In molti casi il modello di strategia si traduce in classi di interfaccia (come si sta mostrando) con un solo doStuff(...)metodo.

public interface IVideoProcessor
{
   void Split();

   void Compress();

   void Index();
}

Quello che hai è modulare e va bene, ma se dovessi raggruppare queste responsabilità in IVideoProcessor, probabilmente avrebbe più senso dal punto di vista di DDD.

D'altra parte, se la divisione, la compressione e l'indicizzazione non fossero in alcun modo correlate, li terrei come componenti separati.

È un problema: stai lavorando dall'aspetto funzionale del design, piuttosto che dai dati. Quello che hai effettivamente sono 3 funzioni autonome che sono state richieste da OO.

Ad esempio, hai una classe VideoCompressor. Perché stai lavorando con una classe progettata per comprimere video - perché non hai una classe Video con metodi su di essa per comprimere i dati (video) che contiene ogni oggetto di questo tipo?

Quando si progettano sistemi OO, è meglio creare classi che rappresentano oggetti, piuttosto che classi che rappresentano attività che è possibile applicare. Ai vecchi tempi, le classi venivano chiamate tipi: OO era un modo per estendere una lingua con il supporto per nuovi tipi di dati. Se pensi a OO in questo modo, ottieni un modo migliore di progettare le tue lezioni.

MODIFICARE:

lasciami provare a spiegarmi un po 'meglio, immagina una classe di stringhe che ha un metodo concat. Puoi implementare una cosa del genere in cui ogni oggetto istanziato dalla classe contenga i dati della stringa, così puoi dire

string mystring("Hello"); 
mystring.concat("World");

ma l'OP vuole che funzioni così:

string mystring();
string result = mystring.concat("Hello", "World");

ora ci sono luoghi in cui una classe può essere usata per contenere una raccolta di funzioni correlate, ma che non è OO, è un modo pratico di usare le funzionalità OO di una lingua per aiutare a gestire meglio la tua base di codice, ma non è assolutamente possibile di "OO Design". L'oggetto in questi casi è totalmente artificiale, semplicemente usato così perché il linguaggio non offre niente di meglio per gestire questo tipo di problema. per esempio. In linguaggi come C # useresti una classe statica per fornire questa funzionalità: riutilizza il meccanismo di classe, ma non è più necessario creare un'istanza di un oggetto solo per chiamare i metodi su di esso. Ti ritrovi con metodi come quelli string.IsNullOrEmpty(mystring)che penso siano poveri rispetto a mystring.isNullOrEmpty().

Quindi, se qualcuno chiede "come faccio a progettare le mie classi", consiglio di pensare ai dati che la classe conterrà piuttosto che alle funzioni che contiene. Se scegli "una classe è un mucchio di metodi", finisci per scrivere il codice di stile "migliore C". (che non è necessariamente una cosa negativa se stai migliorando il codice C) ma non ti darà il miglior programma progettato da OO.

L' ISP (principio di segregazione dell'interfaccia) afferma che nessun client dovrebbe essere costretto a dipendere da metodi che non utilizza. I vantaggi sono molteplici e chiari. Il tuo approccio rispetta totalmente l'ISP, e va bene.

Un approccio diverso anche nel rispetto dell'ISP è, ad esempio, creare un'interfaccia per ciascun metodo (o insieme di metodi con una coesione elevata) e quindi avere un'unica classe che implementa tutte quelle interfacce. Se questa è una soluzione migliore dipende dallo scenario. Il vantaggio di questo è che, quando si utilizza l'iniezione di dipendenza, si potrebbe avere un client con diversi collaboratori (uno per ogni interfaccia) ma alla fine tutti i collaboratori punteranno alla stessa istanza di oggetto.

A proposito, hai detto

Mi ritrovo a creare un'istanza per ogni classe

, queste classi sembrano essere servizi (e quindi apolidi). Hai pensato di farli diventare dei singoli?

Sì, c'è un problema. Ma non grave. Voglio dire che puoi strutturare il tuo codice in questo modo e non accadrà nulla di brutto, è mantenibile. Ma ci sono alcuni punti deboli in questo tipo di strutturazione. Ad esempio, considera se la rappresentazione del tuo video (nel tuo caso è raggruppato nella classe RawVideo) cambia, dovrai aggiornare tutte le tue classi operative. Oppure considera che potresti avere più rappresentazioni di video che variano in fase di esecuzione. Quindi dovrai abbinare la rappresentazione a una particolare classe "operativa". Inoltre soggettivamente è fastidioso trascinare una dipendenza per ogni operazione che si desidera eseguire su smth. e per aggiornare l'elenco delle dipendenze trasmesse ogni volta che decidi che l'operazione non è più necessaria o hai bisogno di nuove operazioni.

Inoltre, questa è in realtà una violazione di SRP. Alcune persone trattano SRP come una guida per dividere le responsabilità (e lo portano lontano trattando ciascuna operazione come una responsabilità distinta) ma dimenticano che SRP è anche una guida per raggruppare le responsabilità. E secondo le responsabilità dell'SRP che cambiano per lo stesso motivo dovrebbero essere raggruppate in modo tale che se il cambiamento si verifica, è localizzato nel minor numero possibile di classi / moduli. Per quanto riguarda le grandi classi, non è un problema avere più algoritmi nella stessa classe, purché tali algoritmi siano correlati (cioè condividono alcune conoscenze che non dovrebbero essere conosciute al di fuori di quella classe). Il problema sono le grandi classi che hanno algoritmi che non sono in alcun modo correlati e cambiano / variano per diversi motivi.