3 ms·
I think this article ignores or glosses over the hardest part about naming, which is when you have to start naming things with abstract behavior. Naming things
by kornork 10y ago
I think this article ignores or glosses over the hardest part about naming, which is when you have to start naming things with abstract behavior. Naming things with analogs in the domain is easy, but when you find yourself trying to follow the Single Responsibility principle and breaking pieces off you run into trouble.
My AccountingRow is something the user sees, and there's also a SummaryAccountingRow with similarities; both of these need SQL generated, so there's a AccountingRowSQLGenerator and a AccountingRowSummarySQLGenerator. These generally share some of the same business logic around how to join different tables, so there's a AccountingRowCommonQueries class. We also need to spit this out in JSON, so there's a AccountingRowSerializer and AccountingRowsSerializer and AccountingRowSummarySerializer, AccountingRowSummaryRowsSerializer. An AccountingRow also has an AccountingRowBehavior, and AccountRowAdder, and onward into infinity.
Now you have name soup, and if you are looking at this system for the first time your eyes glaze over.
- jt2190 10y agoThis example would benefit from a namespace/package named "Accounting". Then you could drop all of the "Accounting-" prefixes.
- kornork 10y agoWhoops - there's also a BudgetingRow that needs a very similar hierarchy of support structures! Clearly, the system needs some refactoring - perhaps there's a pattern that can be extracted. Hopefully, though, my point came across.
- paxcoder 10y agoMy eyes would glaze over those self-documenting names were it not for your comment(!)
- jwatte 10y agoSounds like most of that is functions, not objects, so lose the classes and use free functions!