14 ms·
The article ends with a diagram showing a bunch of classes whose names end with "er". In my experience, that's usually a strong indicator of confusing design. O
by Aleman360 11y ago
The article ends with a diagram showing a bunch of classes whose names end with "er". In my experience, that's usually a strong indicator of confusing design. Objects that have a single method and no real state should just be functions.
- lowbloodsugar 11y agoConversely, objects should have a single responsibility [1] and so functions that are unrelated should go on different objects. An InvoiceFetcher is definitely unrelated to a PaymentApplier, unless one takes the argument that "Its about money", in which case you have to argue for a single giant class. [1] http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign
- Aleman360 11y agoI dunno, I always thought objects were about managing state. If an object does nothing except provide a method, why can't the method just be a free function instead? InvoiceFetcher.FetchInvoice() PaymentApplier.ApplyPayment() just seems terrible.
- marcosdumay 11y agoOn Java and Java-like languages, objects are also a good option for providing namespaces.
- ta0967 11y agoyou're not alone. http://steve-yegge.blogspot.cz/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.cz/2006/03/execution-in-kingdom-...
- s73v3r 11y agoIn several languages coughJavacough you can't really have free functions.
- lowbloodsugar 11y agoBecause Java. At least I can use an interface to define the function's specification, and then use that in mocks. On the one hand, it seems very different to what I learned about OOP twenty odd years ago, but on the other, it makes for extremely well designed and easy to understand code.