A Gap In Object Oriented Methodology
There have been long debates on whether object oriented is the future of programming. Repeating it over here doesn’t make it any clearer. As you can tell from my blog, I am an OO bigot because it can significantly improve productivity. If you are not convinced about OO benefit, you can look around those top programming languages mostly support OO these days.
By reviewing the whole software lifecycle, however, you will find a gap between requirements and OO programming today. While describing application requirements, a business user almost always describe them in a number of steps (procedural). It’s not realistic to expect requirements described in an OO way. While developing, programmers write and see classes and objects.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
How to bridge the gap between the procedural requirements and object oriented programming? It basically boils down how to abstract the classes and how to glue together to fulfill procedural needs.
This process is called OOD – object oriented design. Both input and output are very clear: requirements as input, and object model as output. The trick is how to do the conversion. Unfortunately this cannot be automated, and demands high level of skills and experiences.
The object model of an software application is the most important part of development. Its quality varies significantly because of designers. A good object model leads to clean and less code, yet flexible enough for fulfilling all the requirements; a bad object model leads to dirty and extra code. This process is where a good software architect can make a big difference for the project.
As a manual process, it’s hard to summarize concrete steps for the design; otherwise we can automate the process one way or the other. In general, you first spot the nouns for entities in the description. These are potential targets to be mapped to classes in the object model. For example, “account” and “order” are easy targets. As you can see, these are passive types. You also need to identify active types – those can take actions. It may be not as easy as for the entity types because it’s mostly not explicit or simply omitted in requirement descriptions.
The object model does not stop at identifying the classes. You should consider optimizing it. One task is to see if you can build an inheritance hierarchy so that you can remove possible duplicated implementations. If you develop applications, you probably don’t find it very useful. But if you are developing APIs, you mostly have to leverage the inheritance. If you build framework, you then want to separate interfaces from the implementation classes.
After the types/classes are identified and made clear their responsibilities, the rest is mostly easy: you codify these responsibilities in terms of methods.The design of method signature requires a lot of consideration if you want a good interface. But by then the scope is trimmed down significantly and easier to handle.
Having an object model dost not mean your software design is done. There are many other aspects you need to consider, for example, data persistence, deployment topology, etc. But they are out of the scope of this post and I would leave them to later discussions.
Design process is hard and mostly cannot be done for once. All too often, you have to modify your design along the way. In other words, it is an iterative process. Because of this, I believe that a software architect must know programming well, and get involved in coding. I am not saying the architect spend all or most of her time on coding, but must touch the code on daily basis and see the impact of the design on real implementation.