The Canonicalized Data Fallacy

A pattern I see repeated in my work as a developer is the idea that we can create what I call, “canonical data objects”. The idea is developers aim to create “domain objects” that stand as the definitive representation of domain concepts across all aspects of the application. These objects typically manifest as anemic data-oriented classes that define all the assumed data about a particular domain concept, but have little in the way of modeling the correct behavior as described by a domain expert. As new use cases are implemented, developers add more data properties

There are many problems with this approach, which I’ll discuss below.

Advertisement

Why Software Objects Are Not Like Real World Objects and Also… Why They Are

Much of the introductory educational material on OOP talks about modeling the real world and modeling software objects based on real world counterparts. In practice, this doesn’t seem to work out for developers. Developers frequently bend their code to handle the needs of the software, and often have to build things that don’t even exist in the real world. We often build layered/modular/distributed systems that have multiple software models of the same real world concept, each modeling different aspects of something to serve a different need or different layer of an application. When the needs and complexity of real software creeps into development, the lofty idea of modeling the real world tends to break down and one or both of two things happen: (1) developers declare OOP a failure or (2) developers abandon trying to model anything.

One problem is introductory OOP education. It usually:

• Focuses more on the mechanics of languages, i.e., classes, methods, inheritance, etc.
• Makes the mistake of making concepts like classes and objects more important than messages
• Uses objects primarily as data holders
• Promotes the idea that getters and setters are a means of encapsulation
• Relies on examples of inheritance and real-world hierarchies that don’t actually have any meaning in software

There is a thread of philosophy surrounding OOP that’s often absent. You may be the kind of person that thinks, “don’t give me that philosophy crap, it’s just programming”. I totally get your point of view and in a way you’re right, but that doesn’t mean there isn’t also a philosophy around object-orientation. I struggled with writing this post because every time I would reread it to edit it, I was increasingly convinced that everything I’m writing is a bunch of bullshit that doesn’t matter. Even if that’s ultimately true, I had to write about it if only to get it out of my head.

Stay Tuned…

It’s five and a half years since my last post. Why it’s been so long since my last post is a story for another time, but I plan to post more regularly in the future.

The world changed a lot in the last half decade. I don’t have to tell you. You were there. You saw it. It was weird.

Back on Track

Now getting back to the main topic of this blog… In the time since my last post, I’ve had many OOP-related topics brewing and it’s time to find out if my ideas are full bore bullshit.

I plan to write a series of short posts giving an overview of the various concepts and ideas I have and eventually expand on the concepts in future posts. So stay tuned…

Something Isn’t Something Else

                                         888    888      d8b                   
                                         888    888      Y8P                   
                                         888    888                            
.d8888b   .d88b.  88888b.d88b.   .d88b.  888888 88888b.  888 88888b.   .d88b.  
88K      d88""88b 888 "888 "88b d8P  Y8b 888    888 "88b 888 888 "88b d88P"88b 
"Y8888b. 888  888 888  888  888 88888888 888    888  888 888 888  888 888  888 
     X88 Y88..88P 888  888  888 Y8b.     Y88b.  888  888 888 888  888 Y88b 888 
 88888P'  "Y88P"  888  888  888  "Y8888   "Y888 888  888 888 888  888  "Y88888 
                                                                           888 
                                                                      Y8b d88P 
                                                                       "Y88P"  
d8b                  d8b 888                                                   
Y8P                  88P 888                                                   
                     8P  888                                                   
888 .d8888b  88888b. "   888888                                                
888 88K      888 "88b    888                                                   
888 "Y8888b. 888  888    888                                                   
888      X88 888  888    Y88b.                                                 
888  88888P' 888  888     "Y888                                                
                                                                               
                                                                               
                                                                               
                                         888    888      d8b                   
                                         888    888      Y8P                   
                                         888    888                            
.d8888b   .d88b.  88888b.d88b.   .d88b.  888888 88888b.  888 88888b.   .d88b.  
88K      d88""88b 888 "888 "88b d8P  Y8b 888    888 "88b 888 888 "88b d88P"88b 
"Y8888b. 888  888 888  888  888 88888888 888    888  888 888 888  888 888  888 
     X88 Y88..88P 888  888  888 Y8b.     Y88b.  888  888 888 888  888 Y88b 888 
 88888P'  "Y88P"  888  888  888  "Y8888   "Y888 888  888 888 888  888  "Y88888 
                                                                           888 
                                                                      Y8b d88P 
                                                                       "Y88P"  
         888                                                                   
         888                                                                   
         888                                                                   
 .d88b.  888 .d8888b   .d88b.                                                  
d8P  Y8b 888 88K      d8P  Y8b                                                 
88888888 888 "Y8888b. 88888888                                                 
Y8b.     888      X88 Y8b.                                                     
 "Y8888  888  88888P'  "Y8888                                                  
                                                                               
                                                                               
                                                                               

Smalltalk: Lost and Found

After Almost 40 years, It’s Still Taking Us to School

Smalltalk is the first and still canonical object-oriented programming language. Alan Kay and other members of the Learning Research Group at Xerox PARC (Palo Alto Research Center) developed Smalltalk in the 1970s. Smalltalk use decreased over the decades, but it’s gaining attention as developers struggling with increasingly complex code look to abandon procedural metaphors for simpler higher level metaphors. We can still learn from Smalltalk even if we don’t use it. (Though we should consider using it.)

When examining Smalltalk we find today’s “object-oriented” tools missed a few essential concepts when they adopted object-orientation. Sacrificing these concepts means developers lost some powerful programming metaphors.

OOP promises organization, simplicity, flexibility, and reusability, yet we often experience disorganized, tangled, inflexible, and duplicate code. Today’s popular multi-paradigm languages make it easier to write procedural code rather than object-oriented code.

Pure object-oriented programming allows building systems with less shared state, less unwanted coupling, and even less code. It reduces time developers need to understand and change code. Readable, decoupled, and testable code means moving fast without breaking things. Ultimately it saves time, and time is money. I like money. You like money too? We should hang out.

Revisiting Nouns and Verbs

There Is No Spoon

Something learned early when studying OOP is to name classes as nouns or noun-phrases and name methods as verbs. It seems like too simple an idea to make better object-oriented designs, but it makes a big difference. In fact, there is reasonable evidence that adherence to this idea could make a design, and ignorance of it could break one. The evidence comes from my own experiences refactoring code as well as what I’ve recently learned while studying Smalltalk.

Naming has such an effect because better names reduce the context an object has, i.e., what an object is aware of versus what it needs awareness of to do its job. Removing unnecessary information raises the level of abstraction providing more opportunity for reuse and minimizes the chance that the message needs changing when requirements change.

A message name constrains the possible interpretations to some extent, which is good. This indicates what the program is doing when the object sends the message and hints to implementing objects the context in which they are operating. However, we should only constrain the meaning of a message as much as necessary and not so much to exclude other valid uses.

To summarize what I’ll be talking about: If an object sends a message that mentions any noun other than those that indicate the parameters it’s passing then there is likely added context and a case for renaming.

Notice I said “likely”. There’s no need to deal in absolutes (as only the Sith do). As I’ve learned more about programming, and life, I’ve learned that nothing is absolute. Everything is relative. You can find exceptions to every rule. Black and white are just acute versions gray.

Messages should only include nouns within their context because messages are ignorant of the things that respond to them and the inner parts of the things that respond to them.

If you remember the movie “The Matrix”*, there is the famous scene when Neo visits The Oracle and meets a boy who bends spoons with his mind. When Neo attempts this, the boy gives him a helpful tip:

Do not try and bend the spoon, that’s impossible. Instead, only try to realize the truth…there is no spoon. Then you will see it is not the spoon that bends, it is only yourself. -Spoon Boy, The Matrix movie

Draft: Putting the Kibosh on Getters and Setters

Perspective

I recently picked up a new book on object-oriented programming called “Object-Oriented Design Heuristics” by Arthur J. Riel. In the book, Riel explains programming’s natural evolution from procedures and data structures to object-oriented. He talks about how programmers adapted their development style to reduce the effects of changes to data structures.

In procedural programming, programmers develop software by decomposing a system into procedures (or functions) that act on a set of shared data structures. One of the problems associated with this type of programming is what Riel calls the “unidirectional relationship between data and behavior”. This unidirectional relationship means you can tell which data a procedure depends on by looking at the procedure (its parameters, local variables, and global variable access), but you can’t tell which procedures use a data structure by looking at the data structure. Take the following pseudocode for example:

Shower Idea: Keyboards and Object-Oriented Design

You know that hypnotic thinking that happens in the shower? I do that outside of the shower. I’m not just staring at the wall. That’s the story of why I’m calling this a shower idea (even though I didn’t think of this in the shower).

I’ll probably post more of these shower ideas in the future. I usually forget to write them down, but I’m going to stop doing that. These ideas aren’t groundbreaking. They’re just interesting food for thought.

Dazed and Confuzzled

Alright, Alright, Alright

For a long time I’ve been on a mission to find the lost parts of object-oriented programming. There is clear evidence that somewhere between its inception and modern programming OOP has lost its definition. Dr. David West says in his book, Object Thinking, “An argument can be made that the contemporary mainstream understanding of objects is but a pale shadow of the original idea. Further, it can be argued that the mainstream understanding of objects is, in practice, antithetical to the original intent.”^[1] There is an original form of OOP that promises many benefits, with the foremost benefits being system composability and flexibility. The form of OOP that many use today, and the form being taught today is a diluted version. We typically defer to a structured style that places control procedures in direct command of other procedures and use objects as data structures.

Adventures in Programming with Java: The Beginning

Update: Life has a way of getting between us and our best intentions. The person who I was working with is recently overwhelmed by obligations at work and home. Unfortunately, we are unable to proceed with our learning project at present. Maybe in the future we will try again. I’ll leave this post up because I still think it has some good information in it.

Someone I know recently got the programming itch. It began with a foray into an Excel spreadsheet application using Visual Basic for Applications.  The urge to build other things soon took grasp, and this person is now interested in diving deeper.

I don’t think I’m in any position to teach someone programming as I have too many of my own questions on the subject. It’s been said, however, that teaching something is a good way to solidify what you know and change your perspective of your own knowledge. Teaching forces you to simplify what you know. Having a simple mental model of something complex is a perspective that is difficult to attain once you’re past childhood. Teaching others is an opportunity to devise a simple model for someone else, and if we retain that simplified model ourselves, it enriches what we know about the complex nature of… whatever complex thing we’re talking about.