My university teaches object oriented programming, but outside of the software engineering class (which is terrible) really teaches you to program in a simple structured way. Sure you use classes and objects, but the nonsense of “design patterns” is never really focused on.
I know Java is a very popular introductory language for CS in the United States, and it makes me quite sad. I can’t help but think that introducing students to OO as the first way of doing things is a mistake. Rather, I would prefer something like C, or Python, or Lisp, or Haskell (yes, Python has classes and objects, but they are not central like they are in Java). The only justification for teaching OO is simply that it is used in industry. Not that it is actually good for the creation of large stable software.
Part of me says “Yes! This is the way I program!”
Part of me says, “Errr, Be Honest John, you are actively looking for an exit strategy from this anti-pattern…”
You see, the problem with Sematic Compression is the update problem.
Suppose you need to change something…. too often you have uncompress everything, update and then recompress, often with a subtly diffferent schema / dictionary.
Yes, trivial updates are grreat, trivial updates are easy to do if your code is semantically compressed tight as a xz bundle, non-trivial ones, the ones that first force you to decompress….. Urrggh!
So what is the answer? I’m not sure, as I said I’m looking for the exit sign, the “This Way Out to a Better Paradigm” door.
A strong hint is relational algebra. The things CJ Data writes about. Denormalisation decompresses data first to make it easier to deduplicate the important stuff, the facts.
The key, (a small pun there), is to know what your data model is. What are your primary keys, what are your foreign keys, and keep the data model of your whole program, not merely your RDBMS, in as high a normal form as your brain can understand, so integrity is built in, part of the basic schema of the program.
Most Object Oriented Programming designs are very 1970’s Heirarchical Database in style, in fact the higher the semantic compression as described in the post here, the more duplication is pulled out and pulled out and pulled out into a digraph of abstractions.
The problem is that makes it stiff to change, when we suddenly find some core “essential thing” we thought we understood isn’t what we thought…. and we have to run around and inspect each use and understand what we need to change in each case.
In a static world of perfect understanding, Semantic Compression is the ideal… In a shifting world of imperfect understanding…. it’s fragile.
Regarding the update problem I think the author of the post makes a great case at avoiding premature (semantic) compression and operating compression only after the necessity arise from the domain; also, in the following post he deals with the challenges posed by adding new functionalities to the previously compressed code, when to further compress, when not to and how not to lose “granularity”.
I find the concept of continuous granularity useful in not to fall into the trap of over-compress, with the risk, down the road, that you have to “uncompress” to accomodate new changes. Synthesising (and simplifying, the post is more explicative): if by compressing you’re introducing some discontinuity in the usage of your API/code (things that were possible to express before but you won’t be able to express after) well then you’re compression is not quite right.
To paraphrase K. Beck: Make it work. Make it right. Make it beautiful. Make it fast.
For what concerns most OOP designs, as you pointed out much of the incidental complexity lie in the frozen and “hierarchical nature” of the designs where on one side you continue to introduce specializations and on the other side you continue to abstract until you end up having an AbstractFactoryServiceFactoryFactory.