Linee guida sui campi delle classi nel software gestibile?

1

Recentemente ho letto il libro Building Maintainable Software di Joost Visser e sento che c'è qualcosa che non hanno discusso. Il titolo suggerisce tanto, non so se seguire le linee guida abbia qualcosa a che fare con il campo / gli attributi. Le linee guida pertinenti:

-Scrivi unità di codice brevi

: tieni le basi dei codici piccole

Posso avere tutti i campi che mi piacciono / ho bisogno? E i commenti e i campi? Dato che i commenti sono vietati quando si seguono le linee guida, ciò vale anche per i campi?

    
posta RabbitBones22 16.02.2017 - 11:19
fonte

1 risposta

5

Non hai citato il contenuto effettivo di tali linee guida, quindi la domanda è difficile da rispondere per le persone che non hanno il libro disponibile. Proverò a rispondere più in generale.

La parte importante con "linee guida" o "best practice" è capire il ragionamento dietro di loro, per capire perché aiutano a rendere il codice mantenibile. Se lo capisci bene, allora sarai anche in grado di capire come si applicano a situazioni che non sono menzionate esplicitamente, e - ancora più importante - saprai dove non apply.

puoi avere tanti campi quanti ne hai bisogno, ma per rendere il codice più mantenibile, il numero di campi dovrebbe essere limitato. Se hai troppi campi in una classe, la classe è probabilmente troppo grande e non segue il Principio di Responsabilità Unica.

Un'altra cosa da fare è evitare l'uso scorretto dei campi come parametri del metodo nascosto. Se hai un campo che viene scritto solo nel metodo A, leggi solo nel metodo B e A chiama anche B, quindi dovrebbe essere un parametro di B invece di un campo. Ciò deriva dalle linee guida più generali per mantenere il più possibile il campo di applicazione di tutti gli stati per ridurre al minimo la quantità di stato a cui devi pensare in un dato luogo.

Per quanto riguarda i commenti, se quelle linee guida ti dicono che sono "tipo di proibito", devo davvero mettere in dubbio la loro utilità. È vero che i commenti possono essere negativi se sono solo una stampella per rendere comprensibile un codice strutturato malamente anziché renderlo più semplice da comprendere, ma non sono proprio i commenti a rappresentare il problema, è il codice mal strutturato. E i commenti sono sempre inferiori al codice che non ha bisogno di commenti, perché tendono a diventare obsoleti.

Ma se hai un campo il cui nome non può trasmettere le informazioni necessarie per comprenderne il significato, e non puoi rifattorizzare il codice per renderlo più facile da capire (es. usando enumerazioni per specificare e nominare i possibili valori), quindi puoi e dovresti assolutamente commentare un campo con semantica complessa.

    
risposta data 16.02.2017 - 11:40
fonte

Leggi altre domande sui tag