Come strutturare le classi in una base di codice estesa

Question

Come strutturare le classi in una base di codice estesa

#1 da (1 voti)
#2 da (0 voti)

1

Una delle regole più reclamate di OOP è mantenere le classi piccole. Ciò significa che in un progetto di dimensioni significative ci sono migliaia di classi.

Logicamente sembra logico combinare classi correlate in vari "sottosistemi" (o vari livelli di sottosistema). La mia comprensione della legge di Demeter qui è che una classe nel sottosistema X non dovrebbe parlare direttamente con una classe nel sottosistema Y; invece il sottosistema Y dovrebbe fornire una facciata per astrarre i dettagli delle singole classi al suo interno. Tuttavia, in un'applicazione complessa, la facciata deve per definizione essere una grande classe. con molti metodi, anche se in realtà non fa molto.

Quindi dovrei usare le classi di facciata (presumibilmente a diversi livelli) per mantenere una struttura gerarchica di sottosistemi, o dovrei trattare ogni classe come entità separata e usarla direttamente?

code-organization

posta Andy 13.11.2015 - 15:48

fonte

2 risposte

Leggi altre domande sui tag code-organization

Configurare il mio modello di ereditarietà? BigData: numero di parole basato sul tempo

score 1 · Answer 1

So should I be using façade classes (presumably at several levels) to maintain a hierarchical structure of subsystems, or should I treat each class as a separate entity and use it directly?

La tua concentrazione dovrebbe generalmente essere su accoppiamento .

Per alcune classi (dtos di base, utilità che sono invarianti), solo usarle direttamente va bene. Non è necessario implementare un'astrazione che non offra alcun vantaggio.

Ma per la maggior parte del codice, vorrai introdurre le astrazioni di disaccoppiamento (interfacce, messaggi, eventi) in modo da poter cambiare l'implementazione sottostante senza interrompere il contratto tra quel codice e i suoi consumatori.

Questo modello generale vale quando passi da funzioni e classi a sottosistemi e moduli. Alcuni saranno funzionalità fondamentali che richiederebbero modifiche all'ingrosso se smettete di usarlo. Ma molti vorranno fornire un contratto (una libreria API, una web API, un protocollo, code di messaggi, bus di dati, ecc.) Che annullino la loro implementazione in modo da poter cambiare l'implementazione senza interrompere il contratto tra il codice e il suo consumatori.

Come fare ciò e dove fare ciò dipende molto da quali problemi si stanno affrontando, ed è ben oltre ciò che qualsiasi risposta qui può fornire.

score 0 · Answer 2

Sembra un incubo da mantenere. Crea solo ancora più classi da mantenere.

Se la tua lingua supporta pacchetti, namespace o simili, usali. Utilizza la lingua o sviluppa convenzioni di denominazione dei pacchetti per nascondere i componenti interni del sottosistema da sottosistemi esterni.

Ma non c'è motivo per cui una classe in un pacchetto non dovrebbe parlare a una classe in un'altra se è la cosa giusta da fare.