A better way than OO!... and TDD?

January 08 · 9 mins read

old-resume-technical-expertise-oo.png

That image is part of my résumé when I applied for my first and second jobs.

Object-Oriented Programming was one of my technical expertise!

I can’t help but laugh at myself when, years later, I heard Uncle Bob Martin talk about programmers claiming to know about OOP when they do not truly know OOP.

Oh we’re doing OO!

What’s OO?

… this … and … that …

Oh yeah, I’ve been doing that for years.

:laughing:

Well, I did not not know any better during that time. I thought OOP was just knowing what a class is, knowing what an object is, what an interface is, what inheritance is, what polymorphism is…

But I passed the interviews, of course…

I remember this question during my interview for my second job:

Interviewer: Do you know of the other way of doing polymorphism than using an interface?

Me: Uhmmmm… Using a child class and a superclass??

Interviewer: You mean inheritance?

Me: Yes… inheritance

:laughing:

Well, I think my answer is not completely wrong but… I’m not sure… I think the correct answer should have been “by using an abstract class”, or something like that.

Perhaps my interviewers just forgave my arrogant claim about OOP because they knew that I was just a beginner.

Okay… enough of my story…

I just used my story on OOP as an introduction to this post because it is very much related to what this post is all about.

This post is about Mark Seemann’s[1] talk titled “Functional Architecture — The pits of success (NDC Sydney 2016)”. I find this talk very interesting because he has claims in this talk which will give lots of hope to programmers.

… This is what I feel to be a software architect or a lead developer on a team is you have to be constantly vigilant because if you just look away for a moment, if you are sick for a couple of days, or you go on a vacation, or you have to go to many meetings, what’s going to happen is that everything rolls downhill again…

… Then about 5 or 6 years ago, I started learning about functional programming…

I realized that a lot of these things that are difficult in object-oriented design actually turns out to be quite easy to do with functional programming. It almost happens by itself.

Whoa!

Clean Architecture and OO

He talked about the difficulty of learning decoupled architectures when used with object-orientation:

… You don’t want your business logic to be too dependent on all of those technical concerns (such as the UI, the database, and sending emails) because they may change… So you want to protect the valuable parts of you software from all the incidental details…

My experience with this though is that it’s really difficult just to explain to a team of software developers who have never heard about this before why you would want to do this.

Because it goes into a lot of things about the principles of object oriented design like the SOLID principles for example; and you need to think about Dependency Injection… In order to understand those things you have to read thick books about them…

I think I can relate to this because it took me about four or five years before realizing the importance of the SOLID principles and many things similar to them. I heard about these things from the beginning of my career, even during college I think, but I did not give that much attention to them. I was so focused on the shiny things in programming — the frameworks and libraries — which are popping from everywhere every millisecond of the day. :laughing:

Better than OO!

If we need that many pages (500 or 700 pages, refering to the books “Agile Principles, Patterns, and Practices” and “Dependency Injection in .NET”) to explain a concept maybe we should start to think about if there is a better way. — Is this really the best we can do?

Oooooooo… There is a better way!

Does functional programming help?

It does!

… Then he talks about how functional programming might be a better way than object-orientation.

This is very intersting!

I first became interested with functional programming through Uncle Bob Martin. But my interest about learning it decreased after reading this statement from him also, in his post titled “Living on the Plateau”:

If we aren’t going to see 1024 core processors in the near future, what need have we of functional programming languages? Oh, don’t get me wrong. I think functional programming is a good idea. Every programmer should learn it. But the crisis that we anticipated – the crisis that drove the current infatuation with functional languages –– seems not to be occurring. And that may well mean that functional languages never achieve the ascendency that we had anticipated for them. It may just be that Java/C#, and Ruby/Python, and Swift/Dart/Go are, and will be, sufficient.

… But after viewing Mark Seemann’s talk… I have to learn functional programming…

Better than TDD?!

Mark Seemann also talked about testing and why it is easier in functional programming than in object-orientation:

Testable OOP requires a lot of effort and a lot of diligence and a lot of constant monitoring of what’s going on…

Then this!…

If I had a team of developers who are already good at doing functional programming, I could basically just say to them, if I were the lead developer or software architect, “just write as many pure functions as you can”

… then I’ll go on a holiday and then I’ll go back and we will start testing it.

Whoaaa! What?!… Go back and start testing?!

He said that pure functions are always testable!

Does that mean that TDD will not be needed in this kind of setting?

Does that mean that writing tests after-the-fact will not be very difficult in functional programming?

I hope…


P.S.

In his talk titled “What is OO really?”, Uncle Bob Martin said this about OO at the end of the talk:

Some people like to think that OO lets us model the real world.

OO does not let us model the real world. Software does that. Software has always done that. OO doesn’t give us any special benefit to that.

Some people say it’s a better way to think.

No it’s not a better way to think.

It is, however, a very powerful way to manage dependencies.


[1] Mark Seeman… He was the one who made me understand the SOLID principles of object-oriented design… from his Pluralsight course “Encapsulation & SOLID”… that was during the time when I was still stealing courses from Pluralsight:grin:

Buy Me A Coffee