4 ms·
Conversely, objects should have a single responsibility [1] and so functions that are unrelated should go on different objects. An InvoiceFetcher is definitely
by lowbloodsugar 11y ago
Conversely, 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.