Re:The Failures of “Intro to TDD”
by Aleman360 on Thursday June 18, 2015 @10:51AM
(#9738859)
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.
[ Parent
| on HN ]
Re:The Failures of “Intro to TDD”
by lowbloodsugar on Thursday June 18, 2015 @11:30AM
(#9739187)
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.
I 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()
Re:The Failures of “Intro to TDD”
by lowbloodsugar on Thursday June 18, 2015 @08:58PM
(#9742508)
Because 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.
you're not alone. http://steve-yegge.blogspot.cz/2006/03/execution-in-kingdom-...
Re:The Failures of “Intro to TDD”
by marcosdumay on Thursday June 18, 2015 @12:04PM
(#9739468)
On Java and Java-like languages, objects are also a good option for providing namespaces.