News for hackers. Stuff that matters.
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.

[1] http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

Re:The Failures of “Intro to TDD” by Aleman360 on Thursday June 18, 2015 @11:31AM (#9739195)
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()
just seems terrible.
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.
Re:The Failures of “Intro to TDD” by ta0967 on Thursday June 18, 2015 @12:52PM (#9739918)
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.
Re:The Failures of “Intro to TDD” by s73v3r on Thursday June 18, 2015 @01:29PM (#9740253)
In several languages coughJavacough you can't really have free functions.