Wednesday, March 16, 2011

OOP and OOA - the new age

How come programmers have advanced so far in the evolution that the architects that lead the overall design have been left so far behind? How come that they teach and preach the same stuff their grandpa would (if he'd be still alive)?

It might seem like a strong opinion to you. Tough one if it does. You might be one of the architects that I mentioned above.

So what's the deal?

Let's examine two of the many OOP techniques at our disposal: Inheritance and Composition.

Inheritance (quoted after Wikipedia):

"In object-oriented programming (OOP), inheritance is a way to compartmentalize and reuse code by creating collections of attributes and behaviors called objects which can be based on previously created objects. In classical inheritance where objects are defined by classes, classes can inherit other classes. [...]
The inheritance concept was invented in 1967 for Simula."

Composition (again - from wikipedia):

"In computer science, object composition (not to be confused with function composition) is a way to combine simple objects or data types into more complex ones. Compositions are a critical building block of many basic data structures, including the tagged union, the linked list, and the binary tree, as well as the object used in object-oriented programming.
Composited (composed) objects are often referred to as having a "has a" relationship."

So it's dead simple, right? Son is his father's child but a car has wheels and eingine, right?

So please anyone tell me why the F so many enterprise-grade systems are created in a monolithic way? For haven's sake the 80's are gone, it's the year 2011!.

And don't you go about telling me that the technology isn't there yet! Oh it's there. In fact it's been there for a couple of years now. Starting with the first servlet containers!

So you'll say that creating a system that shares common security configuration (and thus uses some sort of single-sign-on feature) is not easy? Wake up, dude! It's been ready for ages!

So maybe it's the build time that's causing you to lean towards a monolithic design? Goddamn it! Is it really faster to build and deploy a 200MB War file than to build just one single part of it and dynamically restart the context?

Ok - I get it. You still need to cover your part of the deal, right?. If everything would be so dead simple you'd not be needed at all and that'd mean that you'd be without work. So who the hell would control what parts would need to emerge for the whole system to work??? Well, we (programmers) would't have to finally do your job.

All and all my point is: keep it simple and small.

PS. I hope you did get the irony :D

No comments: