In generale, ogni volta che hai due pezzi di codice che dovrebbero essere disaccoppiati ma dovrebbero funzionare insieme, li colleghi in una parte di codice terzo che dipende da entrambi (supponendo che non stai facendo affidamento su alcuni meccanismi basati su framework o linguistici che possono sfruttare la denominazione basata sulla convenzione, o qualcosa del genere).
Nel tuo design DrawingController dipende già da entrambi, quindi puoi farlo lì. Se ritieni che sia una responsabilità extra che non appartiene a quella classe, puoi farlo in Program , o introdurre un'altra classe che incapsulerà la logica wire-up (nota che Program farebbe quindi riferimento a questa classe extra). Il codice in Program può quindi ottenere il factory da questa classe e passarlo a DrawingController . Si noti inoltre che negli approcci che utilizzano l'iniezione delle dipendenze, la maggior parte del codice di hookup viene trasferito alla radice della composizione (essentialy, a main (), vedere ( 1 ), ( 2 )), in cui è necessario collegare manualmente tutte le dipendenze o utilizzare un contenitore DI (non dicendo che uno è migliore dell'altro).
Ancora qualche commento. Un'altra opzione per la creazione della forma consiste nell'utilizzare il modello di prototipo . Fondamentalmente, si mantiene un elenco di istanze AShape (delle sottoclassi concrete) e si crea una copia ogni volta che è necessario che l'utente aggiunga una forma al disegno. In questo approccio, il codice che "crea" la forma deve solo sapere come fare una copia (o chiamare qualcosa che può dargli una copia). Ciò è particolarmente utile se l'utente può creare le proprie forme - basta aggiungere un'istanza della forma personalizzata (definita dall'utente) alla lista dei prototipi (e si può anche fare tutto in fase di runtime). Un'altra cosa che potresti fare è usare il Pattern composito per consentire forme composite (ereditate da AShape , e mantenere un raccolta di AShape -s internamente; su draw() , chiama draw() su ciascuno). A proposito, le forme composite sono un altro modo per supportare le forme definite dall'utente, e puoi anche combinarle con il modello di Prototipo come descritto sopra.
A proposito, perché la tua classe Shape ha il campo shapeType : ShapeEnum ? Forse hai bisogno di essere in grado di manipolare i vertici, quindi a un certo punto hai lanciato la forma sul tipo concreto? Se stai usando quel campo in una condizione if da qualche parte, ciò potrebbe significare che il modo in cui hai modellato il sistema non si allinea con quello che devi fare il sistema (eccetto se stai usando solo ShapeEnum nel fabbrica), quindi dovrei passare attraverso il design per vedere se supporta realmente le tue esigenze. (Non deve essere "perfetto", ma considera quali sono le caratteristiche principali che vuoi che il sistema abbia, e assicurati che il design faccia effettivamente qualcosa in tal senso.) Vale anche la pena di considerare se sarebbe di aiuto se hai trovato un diverso set di astrazioni (ad esempio, le forme potrebbero essere ricavate da pochi oggetti componenti che gestiscono diverse responsabilità), o anche se hai cambiato la granularità dell'orientamento all'oggetto all'interno del sistema (es. rendilo OO solo in le linee generali e più procedurali e orientate ai dati nel codice che gestisce il disegno). Non complicare eccessivamente le cose, però. Inoltre, se non sbaglio, la tua applicazione sembra essere ancora in una fase in cui puoi praticamente riscrivere tutto, se necessario, quindi in qualsiasi modo tu non sia troppo attaccato al design che hai scelto in questo modo fase, e non cercare di fare qualcosa di troppo generale e "a prova di futuro". Con il passare del tempo capirai l'area problematica & i requisiti sono migliori e con questa conoscenza ti verrà proposto un design più adatto, uno che sarà migliore di qualsiasi cosa tu possa immaginare a questo punto.
