È 'sicuro' aspettarsi che myClasses accetti di non chiamare solo i metodi del pacchetto scope da altri metodi di scope del pacchetto?

0

Le domande dicono tutto, ma una rapida panoramica della situazione. Sto creando un modello che contiene classi (tutte che ereditano myObject) che hanno una grande quantità di interconnessione. Voglio che il controller sia in grado di creare uno qualsiasi di questi oggetti in qualsiasi momento, senza modificare il modello. Solo un riferimento esplicito al modello per "AddToModel" dovrebbe "installare" l'oggetto nel modello (incluso l'aggiornamento di tutti gli oggetti connessi). myObjects utilizzerà un modello factory, se un utente tenta di creare qualcosa già rappresentato nel modello, l'oggetto già istanziato nel modello verrà restituito invece di crearne uno nuovo.

Per aiutare con l'incapsulamento, voglio che tutti i miei oggetti siano immutabili per il controller, indipendentemente da ciò che fa con un oggetto che non può cambiare il modello senza chiamare l'add / remove del modello. Il modello deve ancora essere in grado di cambiare lo stato di myObject; quindi metterei tutti gli oggetti nel pacchetto del modello. Ogni oggetto avrà quindi metodi per l'ambito del pacchetto per l'aggiornamento dello stato, inclusi i metodi di aggiunta / rimozione che li installano nel modello e aggiornano gli oggetti connessi. Quindi, in sostanza, i metodi dell'ambito del pacchetto possono cambiare lo stato del modello, il pubblico non può.

La mia preoccupazione è che tutto questo si interromperà se qualcuno di myObjects chiama uno dei loro metodi di scope del pacchetto da un metodo pubblico; scherzando con il mio stato senza chiamate esplicite a Model. Sto scrivendo tutto questo, così posso rispettare il contratto che "solo pacchetti di metadati possono chiamare altri metodi di pacchetto" Ma cosa succede se qualcuno arriva più tardi e prova a chiamare "addToModel" da un costruttore perché non hanno letto i miei commenti e non capisci che questo rompe un contratto presunto?

È "sicuro" aspettarsi che gli altri leggano i commenti e si attengano a un contratto così implicito quando si scherza con il "mio" modello? Posso farlo rispettare con una sorta di pattern (preferibile senza troppe astrazioni / interfacce in quanto potrebbe confondere alcuni degli altri sviluppatori).

ps, sto usando Java se questo aiuta. Penso che potrei persino essere in grado di applicarlo con l'API di sicurezza, anche se ciò potrebbe rivelarsi più confuso / complicato dal momento che comporterebbe un'eccezione di runtime oscura.

    
posta dsollen 19.04.2013 - 18:29
fonte

2 risposte

1

Sembra che tu stia progettando di rendere il modello e tutte queste classi di oggetti reciprocamente dipendenti. Penso che questa sia una cattiva idea che renderà molto difficili i test e la manutenzione. Probabilmente nessuna delle classi oggetto dovrebbe dipendere dal modello. Se il modello deve reagire alle modifiche dello stato dell'oggetto, è possibile che il modello osservi gli oggetti.

    
risposta data 19.04.2013 - 21:32
fonte
0

No. Le classi / oggetti dovrebbero avere il proprio stato. Sembra che ti aspetti che Model gestisca lo stato di myObject .

Per elaborare, sembra

  1. myObject ha metodi "di sola lettura" pubblici e metodi "mutator" di accesso al pacchetto.
  2. Se myObject richiama i propri metodi "mutator", Model sarà / potrebbe rompersi.

Idealmente, un futuro programmatore dovrebbe essere in grado di cambiare "myObject" senza interrompere Model .

    
risposta data 19.04.2013 - 20:29
fonte

Leggi altre domande sui tag