Object Interfaces versus Concrete Code
Although lots of people design object oriented systems, few notice the
reason why them sometimes don’t work as planed. While such systems
were created to reduce complexity, several object oriented design become
extremely complicated. Especially when we start to add design patterns
to solve even simple problems.
Frequently, OO systems are the right solution for the wrong problem. The major problem we face when writing a system is not writing components
themselves. In fact, writing a single component can be done as easily in
an object oriented language as in a procedural language, for example.
The big problem we have is writing interfaces. Interfaces generate the large scale complexity in a system, which is what we want to avoid.
The problem though,is that most programmers think it is ok to use the interface building paradigm when writing code for a single component. And while this is possible, it is not the most efficient or maintainable solution.
What is an OO system?
OO incorporate the notions of interfaces but adds some syntax sugar
to implement dynamic dispatch. This simplifies the creation of interfaces,
the same way COM provides this feature for binary interfaces in C.
Notice that interfaces are a nice feature, but they are not all that we need to
write. So, while it is interesting to write systems with a good interface design, thinking that all you write is an interface is very simplistic.
In my experience, there is a lot of code that benefits from being written in different styles, such as functional or declarative. These components don’t needs to be written using classic object oriented components, and will never be part of the outside interface of a system.
In this type of code, it is just to have free functions that access data stored in data structures or lists, for example.
What About Polymorphism
The other feature, polymorphism, is not really new to OO, because it has been done for decades in other languages, such as C. Just define a pointer to a function and call it instead of of a statically defined function — This is how
DLLs or shared objects work, by the way. There is no real need for a new language just to define what will be called when a function pointer is invoked.
In my opinion, one of the main reasons why people like OO for commercial software is the way it constrains developers.
To create software with OO languages, one has to use classes for dynamic dispatch and interface hiding. But while it is ok to pretend for a while that these are the only important features you need, it quickly gets unconfortable.
Very soon OO people have to go through hoops just to simulate things they cannot do in their framework. Have you ever read about singleton — and why you need a special class to represent something that is not an object?
Have you studied flyweight objects to rediscover that sometimes you need values that are not objects? Have you struggled through the performance issues that exist only because of over reliance on OO?
Well, all of these things could be avoided by understanding that OO is nice as a way of representing interfaces to systems, but is a very poor metaphor to work on the internal implementation — unless you are prepared to go through hoops just to make something simple work.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
