The other day I was in good company with a business owner, who is also a\u00c2\u00a0programmer, and a business controller, who isn’t a programmer. We were\u00c2\u00a0discussing the issues of one of my favorite topics: Software Quality.<\/p>\n
Naturally the software must do what it is intended to do, but the hidden\u00c2\u00a0issue, which to me is almost as important: Functionality must be placed in\u00c2\u00a0the right areas.<\/p>\n
The analogy became looking for $10 in a persons wallet.<\/p>\n
To the programmer getting this task, the basic work: Find person, find\u00c2\u00a0persons wallet, check if wallet contains $10. Has to be done regardless of\u00c2\u00a0where the functionality is applied. To the CPU the steps will be loaded in\u00c2\u00a0sequence anyway thus the “correct” position of the code is another matter.<\/p>\n
Now, in real life, if I ask someone if they have $10 in their wallet,\u00c2\u00a0they are able to check their own wallet and inform me. On the other hand,\u00c2\u00a0I could just take their wallet and check myself. Naturally this would be a\u00c2\u00a0violation of privacy – and I’d have to know where they keep their wallets.<\/p>\n
In the same sense, a controller could implement the functionality\u00c2\u00a0required leading to promiscuous objects being violated. Or the objects\u00c2\u00a0themselves could have the functionality implemented. The first leads to\u00c2\u00a0violation of Law of Demeter,\u00c2\u00a0tight coupling, and too much knowledge,\u00c2\u00a0which in turn leads to higher risk of introducing bugs, higher maintenance\u00c2\u00a0cost, intricate dependencies, and a big ball of mud.<\/p>\n
Controller {\r\n\u00c2\u00a0 person.getWallet().hasAmount(amount)\r\n}<\/pre>\nversus<\/p>\n
Controller {\r\n\u00c2\u00a0 person.hasAmount(amount)\r\n}\r\nPerson {\r\n hasAmount(Integer amount){\r\n return myWallet.hasAmount(amount)\r\n }\r\n}<\/pre>\nThe example is a bit far fetched, but it served the purpose of why it is\u00c2\u00a0important to have clean code in more than one sense.<\/p>\n
The first snippet the Controller will have to know of Person and Wallet.\u00c2\u00a0In the latter Controller needs to know of Person, and Person needs to know\u00c2\u00a0of Wallet. Even though there are the same amount of dependencies, the context\u00c2\u00a0for the Controller is much higher in the first snippet.<\/p>\n
OOP is dead<\/h2>\n
A while ago Pinterest suggested I read Object\u00c2\u00a0Oriented Programming is Dead<\/a> which is a bit dated, nevertheless it\u00c2\u00a0is still relevant. I just think that there are more reasons why OOP is\u00c2\u00a0dead – and yet still alive.<\/p>\nFirst off, we killed OOP by trying to fit a relational database as the\u00c2\u00a0persistence layer – this leads to\u00c2\u00a0data transfer objects, which are\u00c2\u00a0mostly grouped global variables or Java beans, which has nothing to do\u00c2\u00a0with encapsulation.<\/p>\n
Second, we killed OOP by placing logic in the wrong classes, classes in\u00c2\u00a0the wrong hierarchy, and generally forgetting what OOP is about.<\/p>\n
Third blow, we apparently insist on imperative styled programming for an\u00c2\u00a0OOP, which leads to the issues described above.<\/p>\n
Fourth stab, we seem to be grounded in the snapshot state of databases.\u00c2\u00a0That is, an object in a database has a single state, without any prior\u00c2\u00a0history. This is similar to register loading, and overwriting, and is\u00c2\u00a0prevalent in the Update keyword. You actually have to twist, turn, and\u00c2\u00a0contort the default behavior of an RDBMS to get a history\/audit trail for\u00c2\u00a0the values.<\/p>\n
The final death blow was delivered by Martin Odersky – who also kindly\u00c2\u00a0revived OOP in junction with FP – in his presentation Object\u00c2\u00a0and functions, conflict without a cause<\/a>. Well he has done so on\u00c2\u00a0other occasions touting the Scala horn.<\/p>\nRich Hickey – the Clojure guy – seems to at least backup the FP and OOP\u00c2\u00a0notion – primarily of stateless objects, and Datomic seems like a\u00c2\u00a0brilliant choice for a persistence layer.<\/p>\n
OOP is alive<\/h2>\n