Strict Standards: Redefining already defined constructor for class WP_Http in /var/www/serverdude.dk/public_html/wp-includes/http.php on line 61OOP is dead and alive « ServerdudeDeprecated: preg_replace() [function.preg-replace]: The /e modifier is deprecated, use preg_replace_callback instead in /var/www/serverdude.dk/public_html/wp-includes/kses.php on line 1002

Deprecated: preg_replace() [function.preg-replace]: The /e modifier is deprecated, use preg_replace_callback instead in /var/www/serverdude.dk/public_html/wp-includes/kses.php on line 1003

OOP is dead and alive

Discussing Programming topics with non-programmers

The other day I was in good company with a business owner, who is also aÂ programmer, and a business controller, who isn’t a programmer. We wereÂ discussing the issues of one of my favorite topics: Software Quality.

Naturally the software must do what it is intended to do, but the hiddenÂ issue, which to me is almost as important: Functionality must be placed inÂ the right areas.

The analogy became looking for $10 in a persons wallet.

To the programmer getting this task, the basic work: Find person, findÂ persons wallet, check if wallet contains $10. Has to be done regardless ofÂ where the functionality is applied. To the CPU the steps will be loaded inÂ sequence anyway thus the “correct” position of the code is another matter.

Now, in real life, if I ask someone if they have $10 in their wallet,Â they are able to check their own wallet and inform me. On the other hand,Â I could just take their wallet and check myself. Naturally this would be aÂ violation of privacy - and I’d have to know where they keep their wallets.

In the same sense, a controller could implement the functionalityÂ required leading to promiscuous objects being violated. Or the objectsÂ themselves could have the functionality implemented. The first leads toÂ violation of Law of Demeter,Â tight coupling, and too much knowledge,Â which in turn leads to higher risk of introducing bugs, higher maintenanceÂ cost, intricate dependencies, and a big ball of mud.

The example is a bit far fetched, but it served the purpose of why it isÂ important to have clean code in more than one sense.

The first snippet the Controller will have to know of Person and Wallet.Â In the latter Controller needs to know of Person, and Person needs to knowÂ of Wallet. Even though there are the same amount of dependencies, the contextÂ for the Controller is much higher in the first snippet.

OOP is dead

A while ago Pinterest suggested I read ObjectÂ Oriented Programming is Dead which is a bit dated, nevertheless itÂ is still relevant. I just think that there are more reasons why OOP isÂ dead - and yet still alive.

First off, we killed OOP by trying to fit a relational database as theÂ persistence layer - this leads toÂ data transfer objects, which areÂ mostly grouped global variables or Java beans, which has nothing to doÂ with encapsulation.

Second, we killed OOP by placing logic in the wrong classes, classes inÂ the wrong hierarchy, and generally forgetting what OOP is about.

Third blow, we apparently insist on imperative styled programming for anÂ OOP, which leads to the issues described above.

Fourth stab, we seem to be grounded in the snapshot state of databases.Â That is, an object in a database has a single state, without any priorÂ history. This is similar to register loading, and overwriting, and isÂ prevalent in the Update keyword. You actually have to twist, turn, andÂ contort the default behavior of an RDBMS to get a history/audit trail forÂ the values.

The final death blow was delivered by Martin Odersky - who also kindlyÂ revived OOP in junction with FP - in his presentation ObjectÂ and functions, conflict without a cause. Well he has done so onÂ other occasions touting the Scala horn.

Rich Hickey - the Clojure guy - seems to at least backup the FP and OOPÂ notion - primarily of stateless objects, and Datomic seems like aÂ brilliant choice for a persistence layer.

OOP is alive

The Object Oriented notion is extremely important as it is what shouldÂ drive SOA services. They should be defined by their interfaces andÂ encapsulate data and implementations. As Steve YeggeÂ mentioned Amazon is quite good at, and Google not quite as good.

I believe SOA is the right level of re-usability of software, and we will have to get much better at it as more and more mash-ups are wanted. That means we have to accept interoperability at a different level, keep disciplined and not query database tables which we know of, but really belongs to another service.

We also have to embrace the functional style - I’m talking REST for webÂ developers - in which objects are immutable/stateless, and transformationsÂ can be predictably run whether in parallel or sequence, synchronous orÂ asynchronous to the client.

This entry was posted
on torsdag, maj 23rd, 2013 at 21:04 and is filed under programming.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.