See, they say, now my class has state. Sometimes, to make them feel even better about this abomination, they'll hide behind a fancy name such as Service Object.
Bullshit. This is even worse than the first example. The code is more complex and, even worse, it creates the wrong impression for future maintainers. The fact we have a constructor that takes parameters might lead them to believe that they're dealing with an actual class, and to make assumptions that its objects might be long-lived. A Naked Method Is a Function A method that has no meaningful persistent state between calls is not a method. It's a function. It has no business sitting inside a class. Put it in a namespace: a module or a package or whatever your language du jour uses. Some folks will complain that they need the service-object pattern because it lets them turn a function into a value: they create an instance of the class, then pass that instance to some other piece of code that then calls create(). By having multiple different classes, each with a create function, their code is now polymorphic. This is an abuse of classes, because it fails to communicate intent. It you really want to do this, just use closures and/or pass lambdas or function references around. (If your language doesn't support closures, lambdas, or function references, perhaps it's time to enter the 21st century.) In the next newsletter we'll dig deeper into the misuse of classes. (Hint: Laravel and Rails: we're looking at you….) | 
