Life After Business Objects: Confessions of an OOP Veteran • Vagif Abilov • GOTO 2021

Sorry, but gazillion of mmmms and aaaaas make it really hard to watch

Hm very inaccurate talk, with no clear message and somehow a little "simple minded" tries to find reasons why OO paradigms are bad.

As always:
There are no good / bad paradigms -- it depends.

Its like having a toolset for solving problems -- simply choose, what fits best -- and don't tell others that you have the best "screw driver", which can handle all problems best :-) :-).


IMHO: The Code makes the difference -- "Code that looks like it was written by someone who cares", so simply being someone who takes car -- no matter which paradigms are used.

The thing is, there's really not anything that bad about the "bad" implementation of Point as shown here. The "what if's" all have simple answers. For example, we claim "but it's not thread safe!". And the obvious question is "ok... does it need to be?". The answer seems to be "what if it's published in a library and then gets used in a multi threaded application?". But... is it being published in a library? Why are you getting your inexperienced developers to write your libraries?

Had my first job interview about Point in C++ early version. The first thing I tried to explain, was that the methods depend on how you want to use it.
I think the problem is that one tries to make a point that does everything, instead of focusing on what you want to use it for. Now it only recently called domain oriented.
Never seen animals in a realistic application. It is a anti-pattern in our education. Never had problems with Null stuff, it is C++ that makes it a problem.
What you need to do is to look at the architecture and use the methods as interfaces. And nothing else is necessary. The idea of OO is to make your programming modular in a certain entity-based architecture. The smalltalk system is a extreme example of that. The actor model is a different architecture, or micro-services. Function pipes is also an architecture. Etc.
Different languages make certain architectures simpler. The problem is that programmers do not understand architecture and this causes them to mix things together.

Order and OrderManager is really BAD procedural, 20 century C-style programming... In my last dev-team, we have effectively banned the suffix "Manager" , "Helper", etc. as this is an indication of bad design. If you need to write it - you have done something wrong.

I don't understand the whole "avoid null/optional". Yeah, OK, registered vs unregistered user makes sense, but are you also gonna have user with middle name vs without, user with Facebook login vs without, user with an image vs without?

Optional data is natural and common

Years later people who encouraged OOP are still trying to fix it. Keep trying one day OOP will work. Is FP is the answer? Who knows.

tl;dr: for a self proclaimed 20 years of experience OOP developer, he has missed a few, heh, classes. He is correct in the statement that OOP is harder than FP due to defaults and amount of choice; but everything else is really lacks insight

---

This is actually quite painful to hear. While Vagif correctly identifies issues like 'sensible defaults' or 'limiting choice', he is deliberately creating an argument based on false presumption - C# and Java having those issues (or at least could have, as Java has both records and value objects with Lombok limiting such mistakes) does not mean that FP is by default correct. You cannot compare implementation to a generalization.

At later point, he is trying to take a jab at parallelization, where he seemingly ignores the fact that the boundaries of the thread safety aligns with the business API (I won't even comment on the Point example which is completely against the idea of objects) - which is THE SAME as with the immutable data!

Another point is his example regarding different actions allowed for different contexts - any sane OOP has already a tool to solve this - it's called 'interface segregation principle'. We use composition over inheritance for decades now.

Yet another example is that data and logic don't mix. What he does now want to acknowledge, is that OOP by default does not deal with 'data', but with 'data representation', of which the details are hidden. This is a powerful tool that allows us - as an example - treat any list in the same way, but how the data is represented internally - as linked list, doubly linked or array - is left for the expert to decide.

Another atrocious thing - using a class for Order that is missing the point. If you don't want to allow certain actions, you segregate interfaces and use a state machine - FFS GOF book is almost three decades old at this point! Especially this 'validate' method... You don't allow the object to be created in an invalid state. You do not need a public 'validate' method. Which gets funnier, as he quotes "make illegal state unrepresentable", yet he is happily using examples of code that are puprosefully allowing for an incorrect state.

At this point I've absolutely lost interest.

TLDW; Another OOP = bad, FP = good nonsense. Hint: Whoever calls OOP = mutable state and FP = immutable state, do not understand what exactly are these two paradigms at all.

Edit: I actually dont see a problem for you to be a FP evangelist. Everyone can have his/her favorite tools and approaches, and we are all entitled to our opinions. However, plz do not claim yourself as OOP veteran, you do not even understand what is OOP, period.

Thank you for the presentation! It is a joy to listen to Vagif and how he reveals issues and their solving with FP.

One nice trick I've been using with traditional OOP teams is to use records and extension functions in C#. It makes the code look like OOP, but has the separation of data and behaviour. It's a nice compromise.

half live of devs 3 years? Longer than I expected

As an Angular developer I think switching to OOP completely was a mistake when they released a TypeScript version. Especially for services and pipes which are naturally just functions.