Skip to main content

Object Oriented Programming - Use the right objects

In the mid-90's, there was three major object oriented analysis and design methodologies among the leaders in the field:


  • The Booch method - In my opinion, the most technical and exacting of the methods had symbols for things like abstract classes, parameterized types, etc.
    The major problem I saw in using this method was there was less advice in the analysis phase in terms of deciding what should be an object.
  • The Object Modeling Technique (OMT) - This technique, promoted by  Rumbaugh et. al., had a primary goal of being a communication channel with customers.  It also had drawing techniques that seemed to provide a comfortable transition from entity-relationship-drawings (ERD).
    This gave advice on picking objects - the classical picking out the nouns from a requirements document.
  • The Jacobson method (OOSE) - This method had all of the standard OO techniques like the others, but also added use case influenced design and officially categorizing object types like entities, controllers and interfaces.
These three different methods were to become merged into the unified process that we all know and have a love/hate relationship with.

All of these methods, along with the design patterns books that followed, provided a plethora of ways to design OO systems.  Some that I designed I really liked, and some were horrible complications that should be taken out and shot.  And while I could look at a design and tell you which ones were good and were likely to stand the test of time or not I was stuck in the "I'll know it when I see it".

There have even been whole books devoted to telling you if you have a good design or not, it's difficult to tell as your designing if you are on a good path or not.

I was never able to articulate the difference between good OO analysis and bad OO analysis until I read Object Oriented Programming with C++ and OSF/Motif were I got a see an object oriented library that truly helped me design and develop real value.  This book, and the libraries, both commercial and open source based on it, had all of the critical characteristics of a well thought out OO library:
  1. The hid the complexity behind an API (and OSF/Motif X11/R4/R5 was very complex)
  2. It held the state it needed to deal with that complexity
  3. The abstractions it presented were software components, not real world objects.
One of my key leanings on what makes a good object oriented design: the objects should be software components.  If you design has objects with names like car, plane, and bike you will always be in the very messy world that we live in.  A better design will have objects with names like drawable, button, scrollbar.  These items have crisp definitions because they are inside the boundary of the computer system.

I will give you a specific example.  I once worked on an facilities management system that tracked equipment in central offices.  One of the key abstractions for locations we implemented was bay (or rack), shelf and card.  By trying to force fit these real-world object types into our inventory management GUI, I created an overly complicated mess of aggregations and visitor patterns.

Picking the right abstractions, regardless if you are using C++, Java, Golang or Rust, is critical for developing good software.


Comments

Post a Comment

Popular posts from this blog

Spring Boot native builds when internet downloads are blocked made simple

 No direct access to the internet If you work at a company that controls their software bill of materials, it's quite common to be blocked from directly downloading from: Maven Central Docker hub GitHub (the public parts) Getting the bits Maven Maven is first, because without it, you won't be able to compile your Spring Boot application, let alone move on to turning it into a native docker image. I will be showing changes need to work with artifactory, but you should be able to adapt it to other mirror solutions.  repositories {   maven {     name = "central"     url = "https://artifactory.example.com/central"     credentials {       username = "${project.ext.properties.artifactory_username}"       password = "${project.ext.properties.artifactory_apikey}"     }   } } With this configuration change, you should be able to download your plugins and dependencies, allowing you to compile and ...
Post a Comment
Read more

Kotlin Notebook when you're blocked from Maven Central

 TLDR; If you are blocked getting to maven central when first using Kotlin Notebooks because of company firewalls, you can use a tool like Fiddler Tool to redirect to a different network location. Kotlin Notebooks Kotlin Notebooks are a JDK based environment that brings the Python based Jupyter Notebooks  expressiveness to IntelliJ. From the blog post announcing the plugin, it looks like this: At home, the installation of jar files looked like this: I played around with it at home, but I couldn't use it at work.  Many companies, mine included, do not allow software components to be used when downloaded directly from the internet. In my companies case, we use a product called Artifactory, which allows you to mirror the content from Maven Central while still applying policies like CVE scanning, tracking, etc. The way it should work IntelliJ, as one of the leading IDE's, generally supports this quite well.  In fact, there is a whole setting page dedicated to dealing wi...
Post a Comment
Read more

Active vs. Passive Log4jShell remediation

 Log4jShell  All computer professionals should be aware of the Log4jShell ( CVE-2021-44228 ) and it follow on defects.  There is no shortage of opinions and lessons to be be learned: The difficulty of performing safe interpretation The problems when assumptions are not clearly documented.  I, for one, was completely shocked to find out that a logging system would actually attempt to do variable substitution in an actual message. The difficulty of finding and resolving issues with such a common library that is not provided by an OS package manager. IT'S A LOG4J CHRISTMAS One of my favorite podcasts, Security Now - episode 850 , discussed an analysis by Google regarding the depth of log4j dependencies.  From the show notes : One contributing reason is because Log4j is, more often than not, an indirect dependency. Java libraries are built by writing some code which uses functions from other Java libraries, which are built by writing some code which uses functions f...
Post a Comment
Read more