Quando è stato raggiunto troppo incapsulamento

Il fatto che il tuo codice non venga scritto come API pubblica non è proprio il punto - la manutenibilità di cui parli.

Sì, lo sviluppo di applicazioni è un centro di costo e il cliente non vuole pagare per il lavoro non necessario. Tuttavia, un'applicazione mal progettata o implementata sta per costare molto più denaro al cliente quando decide che ha bisogno di un'altra funzionalità o (come accadrà certamente) cambierà le regole aziendali. I buoni principi OO ci sono perché aiutano a rendere più sicuro modificare e aggiungere il codice di base.

Quindi, al cliente potrebbe non interessare direttamente l'aspetto del tuo codice, ma sicuramente il prossimo che dovrà modificarlo lo farà. Se l'incapsulamento (come lo stai definendo) non è lì, ci vorrà molto più tempo e sarà molto più rischioso per lui per fare ciò che deve fare per soddisfare le esigenze del cliente.

Risposta: una volta completata l'interfaccia, allora automaticamente hai finito con l'incapsulamento. Non importa se la parte di implementazione o consumo è incompleta, hai finito dato che l'interfaccia è stata accettata come finale.

Gli strumenti di sviluppo adeguati dovrebbero ridurre i costi più degli stessi strumenti.

Suggerisci che se l'incapsulamento o qualsiasi altra proprietà non è rilevante per l'offerta di mercato, se il cliente non si cura, la proprietà non ha valore. Corretta. E al cliente importa quasi nessuna proprietà interna del codice.

Quindi perché esistono queste e altre proprietà misurabili del codice? Perché deve essere curato da deveoper? Penso che la ragione sia anche il denaro: qualsiasi lavoro laborioso e costoso nello sviluppo del software richiederà una cura. L'incapsulamento è mirato non al cliente ma all'utente della biblioteca. Stai dicendo che non hai utenti esterni, ma per il tuo codice tu stesso sei il numero utente 1.

• Se introduci il rischio di errori nell'uso quotidiano, allora aumenta il costo dello sviluppo .
• Se spendi per ridurre il rischio, aumenti il costo dello sviluppo .

Il mercato e l'evoluzione continuano a forzare questa scelta. Scegli l'aumento minimo.

Questo è tutto ben capito. Ma stai chiedendo di questa particolare caratteristica. Non è il più difficile da mantenere. È sicuramente redditizio. Ma sii consapevole delle leggi della natura umana e dell'economia. Gli strumenti hanno il loro mercato. Il costo etichettato per alcuni può essere $ 0, ma c'è sempre un costo nascosto in termini di tempo speso per l'adozione. E questo mercato è invaso da metodologie e pratiche con valore negativo.

Esiste l'incapsulamento per proteggere gli invarianti di classe. Questa è la misura principale per "quanto è sufficiente". Qualsiasi modo per rompere gli invarianti interrompe la semantica della classe ed è cattivo (tm).

Una preoccupazione secondaria è la limitazione della visibilità e come tale il numero di posti che possono / accederanno ai dati e quindi aumenteranno l'accoppiamento e / o il numero di dipendenze. Questo deve essere fatto con cura però. Man mano che cambiano i requisiti, spesso le volte che la decisione di limitare ciò che la classe espone porta a hack disonesti per affrontare il nuovo requisito.

Questo però è una di quelle preoccupazioni progettuali che derivano dall'esperienza. Nel dubbio, favorire l'incapsulamento. Le preoccupazioni sono indipendentemente dall'API "pubblica" o meno. Anche per il codice interno, i programmatori nuovi o smemorati o assonnati scriveranno codice non valido. Se la tua classe deve essere resistente al codice errato, fallo.