Home PHP Programming The faster you unlearn OOP, the better for you and your software

The faster you unlearn OOP, the better for you and your software

0

Maybe it’s just my experience, but Object-Oriented Programming seems like a default, most common paradigm of software engineering. The one typically thought to students, featured in online material and for some reason, spontaneously applied even by people who didn’t intend it.

I know how succumbing it is, and how great of an idea it seems on the surface. It took me years to break its spell, and understand clearly how horrible it is and why. Because of this perspective, I have a strong belief that it’s important that people understand what is wrong with OOP, and what they should do instead.

“Object-oriented programming is an exceptionally bad idea which could only have originated in California.” — Edsger W. Dijkstra

Many people discussed problems with OOP before, and I will provide a list of my favorite articles and videos at the end of this post. Before that, I’d like to give it my own take.

Back

1. Data is more important than code

At its core, every software is about manipulating data to achieve a certain goal. The goal determines how the data should be structured, and the structure of the data determines what code is necessary.

This part is very important, so I will repeat. goal -> data architecture -> code. One must never change the order here! When designing a piece of software, always start with figuring out what do you want to achieve, then at least roughly think about data architecture: data structures and infrastructure you need to efficiently achieve it. Only then write your code to work in such architecture. If with time the goal changes, alter the architecture, then change your code.

In my experience, the biggest problem with OOP is that encourages ignoring the data model architecture and applying a mindless pattern of storing everything in objects, promising some vague benefits. If it looks like a candidate for a class, it goes into a class. Do I have a Customer? It goes into class Customer. Do I have a rendering context? It goes into class RenderingContext.

Instead of building a good data architecture, the developer attention is moved toward inventing “good” classes, relations between them, taxonomies, inheritance hierarchies and so on. Not only is this a useless effort. It’s actually deeply harmful.

Back

NO COMMENTS

LEAVE A REPLY

Please enter your comment!
Please enter your name here