Gli oggetti di ginnastica ritmica sono semplicemente esercizi teorici, che forniscono un buon modo per i programmatori di scrivere codice più pulito. Ciò significa che:
-
Non dovresti usare Calisthenics quando scrivi un codice di produzione. Quelle non sono best practice e nemmeno linee guida per il codice di produzione.
-
Ci sarebbero sempre contro-esempi, vale a dire casi in cui l'applicazione di Calisthenics porterebbe a codice errato. Ad esempio, esistono numerosi casi in cui il codice che utilizza la parola chiave else sarebbe molto più semplice dell'ereditarietà.
Nel tuo caso, l'oggetto sembra abbastanza chiaro. Puoi mettere alcune delle sue proprietà in oggetti ed ereditarle o usarle come proprietà, ma probabilmente nel tuo preciso contesto, porterebbe solo a:
- Altro codice,
- Più difficile capire l'architettura,
- Difficoltà ad applicare altre Calisthenics, come, insieme, mantenendo le entità piccole e usando un punto per linea.
Ad esempio, puoi iniziare facendo quanto segue:
// One property less.
public class Expense {
private Identifiers ids;
private AmountInCurrency amountInCurrency;
private UserList userList;
private ExpenseDate expenseDate;
}
public class CommentedExpense {
private Expense expense;
private Remarks remarks;
}
Seguendo i commenti alla domanda originale, penso sia utile dettagliare un po 'il contesto e l'obiettivo di Object Calisthenics.
Il documento originale (documento RTF) non è assolutamente chiaro sull'argomento, ma molto più chiaro rispetto ad alcuni dei siti web e articoli di Object Calisthenics adepti e follower, che fanno credere agli altri che tutti dovrebbero seguire le regole descritte ogni volta, ovunque.
Ecco una citazione pertinente del documento, enfasi sulla mia:
Do a simple project using far stricter coding standards than you’ve ever used in your life. Below, you’ll find 12 “rules of thumb” that will help push your code into good object-oriented shape.
By suspending disbelief, and rigidly applying these rules on a small, 1000 line project, you’ll start to see a significantly different approach to designing software. Once you’ve written 1000 lines of code, the exercise is done, and you can relax and go back to using these 12 rules as guidelines.
This is a hard exercise, especially because many of these rules are not universally applicable. The fact is, sometimes classes are a little more than 50 lines. But there’s great value in thinking about what would have to happen to move those responsibilities into real, first-class-objects of their own. It’s developing this type of thinking that’s the real value of the exercise. So stretch the limits of what you imagine is possible, and see whether you start thinking about your code in a new way.
In altre parole, l'intenzione dell'autore originale non era mai di incitare le persone a usare quelle regole per il codice di produzione. Quelle regole hanno solo un obiettivo teorico.
L'ho trovato molto utile per i programmatori con anni di esperienza che scrivono ancora funzioni 500-LOC con 15 blocchi if /% co_de incorporati. Applicare l'oggetto Calisthenics su un piccolo progetto è un buon modo per far scoprire loro la programmazione professionale, dare loro le abitudini di base che possono seguire per il codice di produzione e risvegliare la loro curiosità per cercare modelli di design, ereditarietà, dipendenza dalla dipendenza, ecc.