Refactoring to Functional–Why Class?

This is a multi-part series on Refactoring to Functional Programming

  1. Getting Started
  2. Basic Primitives
  3. Reducing and Flattening Lists
  4. Why Class?

In College

Teacher: We are surrounded by objects in the real world. These can be cars, houses, etc. That’s why it’s very easy to associate real world objects with classes in Object Oriented Programming.

2 weeks later

Jake: I’m having a bit of hard time with these objects. Can you give me some guidance?

Teacher: Sure. There’s actually a couple of more or less formal processes to help you, but to sum it up, look for nouns. And verbs are like methods that can be performed on the class. The behavior so to speak.

Jake: Well that seems reasonable. Thanks!

Jake graduates.

Jake’s on the job

Phil: Hey Jake. I’ve been looking at this class of yours. It’s a little bit too big.

Jake: Sorry. And what’s the issue with that?

Phil: Well, thing is. It’s got too many responsibilities. It does too much.

Jake: And?

Phil: Well think about it. If it does too much, it means that it touches many parts of the system. So the probability of having to touch the class when changing code is higher, which means more probability of breaking things. Plus, 1000 lines of code in a single class is harder to understand than 30 lines.

Jake: Yeah. Makes sense.

Phil: Break these up into smaller classes. That way each class does only one thing and one thing alone.

A year later

Mary: Jake, I’m just reviewing this class of yours, there’s not much behavior in it.

Jake: Yeah well I wasn’t sure if that behavior belonged in the Customer class or to the Accounts class, so I placed it in this other class called CustomerService.

Mary: OK. Fair enough. But the Customer class isn’t really a class anymore. It’s more a DTO.

Jake: DTO?

Mary: Yes, a Data Transfer Object. It’s like a class but without behavior.

Jake: So like a structure? A record?

Mary: Yes. Kind of. So just make sure your classes have behavior. Otherwise, they’re not really classes. They’re DTO’s.

Jake: OK.

2 years later

Mathew: Jake, looking at this class. It’s tightly coupled to a specific implementation.

Jake: Huh?

Mathew: Well, you’re creating an instance of Repository inside the Controller. How you going to test it?

Jake: Hmm. Fire up a demo database?

Mathew: No. What you need to do is first off, program to an interface not a class. That way you don’t depend on a specific implementation. Then, you need to use Dependency Injection to pass in a specific implementation, so that when you want to change the implementation you can.

Jake: Makes sense.

Mathew: And in production, you can use an IoC Container to wire up all instances of the different classes.

3 years later

Francis: Jake. You’re passing in too many dependencies into this class.

Jake: Yeah but the IoC Container handles that.

Francis: Yes. I know but just because it does, it doesn’t make it right. Your class is still tightly coupled to too many other classes (even though the implementations can vary). Try and keep it to 1 to 3 maximum.

Jake: OK. Makes sense. Thanks.

4 years later

Anna: Jake. This class, why did you name it Utils?

Jake: Well. I didn’t really know where to place that stuff cause I don’t know where it really belongs.

Anna: OK. It’s just that we already have a class for that. It’s called RandomStuff

Over a beer…

Jake: You know Pete, I’ve been thinking. They teach us that we need to think in terms of objects and identify these with nouns among other techniques. We then need to make sure that we name them correctly, that they’re small, that they only have a single responsibility and that they can’t have too many dependencies injected into them. And now they’re telling us that we should try and not maintain state because it’s bad for concurrency. I’m beginning to wonder, why the hell have classes at all?

Pete: Don’t be silly Jake. Where else are you going to put functions if you don’t have classes?

Pete: Another beer?

Until next time.

30 thoughts on “Refactoring to Functional–Why Class?

  1. Pingback: Why Class? | Enjoying The Moment

  2. Pingback: A brilliant attack on object oriented programming | Smash Company

  3. Shakespeare

    Classes are for nouns! Unless you’re implementing a Command pattern, in which case they’re obviously verbs. And except for implementations of decorators, in which case they’re adjectives. Or if you decorate your commands, then they’re adverbs. OK, I guess classes can be pretty much any kind of speech you want as long as it makes the program work right.

    But, method names are always verbs! Oh, except for predicates, and…

  4. millionsat18xyz

    I think if you start out with a clear understanding of things like the C language, Unix history, linux kernel source code, you will start to see that this is just not possible to gain the level of performance that these projects achieve through abstracting several levels away from the instruction that you’re trying to execute on the chip. So, it sounds good to have objects and all this, but really what you’re doing is creating an unnecessary abstraction layer that will degrade application performance.

  5. nobody

    Limit classes to 30 lines? Srsly? You get more than 30 lines of boilerplate in Java before your class will do anything. Also, if all you’ve got is 30 lines in that class file, I’m kicking your butt for not documenting your code.

    If your DTO doesn’t have a class, where do you put the data validation? And if it isn’t a class, WTH is it? A hashmap? F that.

    Whoever taught you this stuff about OO was dumb.

    1. Jeff Dickey

      Once again showing that Java has become the COBOL-cum-RPG of the legacy-software world.

      If you write in a reasonably expressive language, you’ll find yourself writing fewer comments, and those only for notes to the next guy to touch the code (possibly yourself). “Yes, this isn’t the usual way to do this, but it’s here because…” or “Here’s our only interaction with the JiggeryPokeryInterface that changes every three weeks because the system it’s built around is as stable as nitroglycerin in a paint shaker on “insane” overnight. Look here first when things break.”

      I find that my Ruby source files are ~90% code. My PHP had a historical average of ~70% and my Java ~40%. “A program is a conversation between two programmers; you shouldn’t need Cliff’s Notes to reinterpret everything.” This from a guy who taught a programming class (C) where one exercise picked randomly through the course involved stripping out each student’s code from their source file and passing the remains to another student to reconstruct. Full credit went to lexically-identical reconstruction (variable names, function names, etc.); 90% to functional identity (same input produces same output in same time), and downward from there.

      I wouldn’t teach a course in Ruby, or even PHP, that way anymore. Java…?

  6. Saikiran Yerram

    THIS!. Its like deja-vu for me when I was working on a Spring based project and it was a freaking nightmare. I had to unlearn all of that bullshit when I moved to Python/Javascript.

    Having said, I still prefer simple classes without the whole OOP application to it.

  7. Marlon

    This is why development has turned into a name-dropping, no-one-is-actually-ever-right battle for ego, and I am considering going back to study something else, like terraforming mars instead; or perhaps a janitorial position where a broom is a broom, not a toothbrush when the moon is half full.

  8. Samantha

    Dear Hadi,

    Jake’s problem is not with OO, nor is it with classes, or anything of the sort.

    Jake’s problem is a psychological one. He cannot bring himself to tell others, “No, you are wrong.”, even when they obviously are wrong.

    He doesn’t have to say it that bluntly. Nor does he have to be harsh about it, meaning he does not have to say, “Mathew, your advice is stupid and you can cram it up your rectum!”

    What he needs to say is something like, “Mathew, I respect your opinion, but inversion of control is not what we need here. Inversion of control is a stepping stone to bigger disasters, and we cannot afford that in our software system at this time. I will not implement inversion of control.”

    When the others come to him with their best-practice-(that’s-actually-a-very-bad-practice)-of-the-day, he needs to shut them down in a polite way, too.

    Never give in to these best-practices freaks. Never give them an inch. The outcome will always be one of two things: 1) a complete disaster, or 2) the situation Jake is in where he is pushed around endlessly.

    Software development is only partially about the software. There is a massive psychological component to it, and Jake apparently can’t handle this aspect of the trade.

    Jake needs to “man up”, so to speak. As the common saying goes, he needs to “grow some balls”. He needs to put people in their place when they deserve it. If he doesn’t do this, then he will become their play toy, like is apparently the case now.


    1. Shaun

      Samantha, I’m having a hard time determining if your being serious or sarcastic.

      “IoC is a stepping stone to bigger disasters? Best practices are really the bad practice? Never give an inch to the best practice freaks?”

      You’re a 40+ year old internal software business developer aren’t you? 50+ controls on one form kind of gal?

  9. Pingback: Dew Drop – November 25, 2013 (#1671) | Morning Dew

  10. Eric

    Samantha, I can only conclude that you’ve never worked in or around software development. If you’re in an environment like the one described and you’re writing code, it’s almost certain that you have absolutely no say in any decision-making process. Telling someone in that position to “man up” or “grow some balls,” if they don’t understand their situation better than you do, is helping them along the way to either being sidelined at work or fired for insubordination. REFUSE to do the job the way you’ve been told to? In no traditional corporate environment — which is exactly the environment that perpetuates crap like this — would that ever fly.

    That said, my thanks to the author. Great read, and it reminds me why I’m so much happier working on small projects than I ever was working in painfully enterprise-flavor-of-the-week cesspools.

  11. wtpayne

    Thinking about how application state evolves over time is difficult, and is responsible for all sorts of pernicious bugs. If you can avoid statefulness, you should … but sometimes you just can’t. In these cases, Classes give us a way to limit and control how state can change, making it easier to reason about.

    In other words, placing state in a private variable, and limiting the possible state transitions with a restricted set of public methods (public setters don’t count) can dramatically limit the combinatorial explosion that makes reasoning about state evolution so difficult. To the extent that this explosion is limited, classes help us to think and reason about how the state of our application evolves over time, reducing the occurrence and severity of bugs in our system.

    The discussion of using classes as an OO domain modelling language is a separate question, and is (as the above article insinuates) is bedevilled with domain-model impedance mismatches resulting in unsatisfactory levels of induced-accidental-complexity.

  12. Sue Donim

    6 Years Later:

    Susan: Jake, this class is all wrong…

    Later on the local, evening news, Jake was arrested for multiple counts of first-degree murder at his office.

  13. Pingback: William Dean

  14. Pingback: Dependency Injection | Typus Salvum

  15. Anon

    That’s why a team should never be bigger than 2 or 3 humans. The only good design method is the method that you control the most and that make you code fast and good. Fuck everyone that try to impose their style. Just fuck them.The time they explained their shitty thoughts the work was done and millions of billions dollars made. End.

  16. Subhash

    Shouldn’t Jack be satisfying that he is gaining more knowledge, you realize things when you need them. Inversion of control for a test program is overkill but for a big project it’s cool idea.

  17. PW

    This is why I hate programming now and would very much like a new career. I’ve been trying to hit the constantly moving target for 12 years and now the only thing I want to inject is a keyboard up a programming god’s a$$.

    1. Jeff Dickey

      If you’re going to change, do it now. I’d been procrastinating over whether or not I should quit and go into Something Else until I realised I’d been doing this professionally for 20 years and I’d be unlikely to come far enough up the curve fast enough to suit me, in whatever alternate career I decided on (which would likely have been law).

      That realisation came to me in March, 1999, a few years before you got in.


  18. Pingback: My links of the week – December 1, 2013 | R4

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s