Ho realizzato un prgram semplice e orientato agli oggetti e penso al design. Mi chiedo quale dei due aspetti sia il design orientato agli oggetti.
La maggior parte delle classi di sinistra è classificata come "principale". La freccia nera significa che hanno relazioni "ha". Le frecce blu sono ereditarietà. Le frecce rosse indicano che crea una classe appuntita come oggetto e ne chiama il metodo. Grazie.
"Red arrows mean it create pointed class as a object and call the method of it."
Quindi non hai separato la creazione dall'utilizzo?
Questo è piuttosto opinato, ma un modo "consigliato" di creare programmi OO, specialmente quando sono coinvolte più classi, è di usare iniezione dipendenza . Un aspetto centrale di DI è: se un oggetto ha bisogno di un altro oggetto, non lo crea direttamente, ma ottiene l'oggetto "iniettato" dall'esterno (la logica dietro è che ti permetterà di scrivere test di unità iniettando mock invece di gli oggetti "reali").
Quindi, se si implementa DI "manualmente", senza un "componente contenitore DI generico" e senza alcuna classe di factory aggiuntiva, questo significa che, al di fuori del codice di test, deve esserci un posto centrale, spesso solo il "main" programma, in cui tutti gli oggetti sono creati e "assemblati". Questo porta direttamente a un grafico creazione che assomiglia alla tua prima immagine.
Tuttavia il nocciolo dell'orientamento agli oggetti è che hai un utilizzo come il secondo grafico - gli oggetti che sono correlati comunicano direttamente tra loro attraverso alcune interfacce definite e tu provi a mantenere le dipendenze come locali il più possibile L'intenzione è di mantenere basso l'impatto dei cambiamenti successivi.
Per i programmi di piccole dimensioni, lo sforzo di introdurre DI potrebbe non valere la pena, quindi seguire un altro "modo consigliato" - il YAGNI principio - potrebbe essere il modo migliore per andare, e avere un grafico di creazione come il secondo può andare bene, anche per molti scenari del mondo reale. Inoltre, gli scenari del mondo reale useranno generalmente un approccio misto. Ad esempio, se alcune delle tue classi rappresentano oggetti di dati puri, senza alcuna logica di business, non c'è molto vantaggio nel "deriderle", quindi creare quegli oggetti direttamente dove sono necessari potrebbe essere perfettamente ok, mentre per altre classi potresti scegli di applicare DI.
Questo è il problema di seguire la Legge di Demeter . Nel primo caso, la classe Main conosce tutte le altre classi. Se ha dipendenza su tutte quelle classi, allora devi controllare se Main funziona correttamente se cambi una di quelle classi + quella che lo sta usando. Se avessi bisogno di deridere le dipendenze della classe Main, allora dovresti prendere in giro tutte quelle dipendenze.
Nel secondo caso, non è un problema, supponendo che tali dipendenze siano incapsulate e non accessibili in modo transitorio. Ciascuna delle classi ha una sola dipendenza, rendendole più facili da testare e ragionare.
Se puoi accedere a tutte le classi in modo transitorio (ad esempio Main.A.B.C ), allora non c'è molta differenza tra il primo e il secondo caso e metterei davvero in discussione l'intero progetto.
Leggi altre domande sui tag object-oriented design-patterns object-oriented-design