I am posting this as a response to all comments to a previous post called “Flaws of Object Oriented Modeling”.
That post created a live discussion that also continued to forums on other websites. It seems that we got so used to OOP and OOD that it sounds like it is the only way to go, making it difficult to ask questions about it. The live discussion just shows that there are many schools of programming even though OOP was considered the last big thing (with C++, Java, C#, etc.)
Here are a few arguments that I am addressing. (Obviously if you agree with the article I am just going to nod).
“One of the best possible solutions to manage complexity is to divide it”
- I agree. The problem is that OOD is not only dividing, it is also hiding.
“Better question: is execution flow relevant?”
“Maybe it is not necessary to control or care about the whole execution flow”
“When you send a message to an object and you don't get the desired result then maybe you are delegating into the wrong object”
- This just to show you that inheritance is strictly enforced but some other things that have greater importance to the product are not. Something huge is missing.
“With the understanding that object-oriented modeling, or rather modeling in general”
- OOD is just one way of modeling. The argument is that stand alone it is a really bad way of modeling.
Just to explain where I come from, I can do OOP. Here is an example:
http://www.asyncop.com/MTnPDirEnum.aspx?treeviewPath=%5bo%5d+Open-Source%5cWinUSB+Component
I can also do procedural programming:
http://www.asyncop.com/MTnPDirEnum.aspx?treeviewPath=%5bo%5d+Open-Source%5cProject+Publisher%5cProjectPublisher.cs
These were C#. Here is some C++:
http://www.asyncop.com/MTnPDirEnum.aspx?treeviewPath=%5bo%5d+Open-Source%5cWinModules
I am not saying that OOD is bad. I am saying that it is not enough. Actually it is far from enough. There are so many things missing there.
It is clear to me that people want answers and not just problems. We are going to cover this in a series of videos. Estimated approximately 3 to 4 hours in total, a nice portion is dedicated to design. We shot these videos at Intel’s Studios in Oregon right after the IDF 2011 event. Use the RSS Feed to be notified when the first segment is edited and released.
A few words about this here: /en-us/videos/black-belt-developer-asaf-shelly-at-idf-2011/ Timestamp 06:20. You can also see Clay Breshears there (for whomever was wondering who he was).
Let me start by saying that it is absolutely necessary to control the execution flow and here is the reason:
An application starts with an SRS document which defines the Requirements, or “the things that the application needs to do”. Moving on we have OOD which defines the objects that we use. Can you see the point? Something is missing. How do you go from “Action Required” to “Software Components”?
The answer is that you have an architect in between and that architect is doing something informal which is almost an art. Can you count the projects that failed because the architecture was perfect OOD but could not meet up with changing requirements? Can you prove to the product owner that the code is meeting the SRS list without any definition of flow? Test Driven Design methodology claiming that you can create a product only by detecting faults failed so badly that I am starting to think that Darwin's Evolution is only proof that there is a god… (Can’t wait to read your comments about that :)
A very important thing to say: Software modeling is not OOD. The argument is not whether to use OOD or not to model your system. The argument is that OOD is a part of system modeling but was sold to us as The way to do software design.
Here are some problems I find with OOD and OOP:
I am not saying that OOP is bad. It is nice. Just as we had procedural programming and then procedures became methods in an object, we need to have objects as part of something more important.
If Water is an object and Sugar is an object, what is Mix? I can also mix Milk and Coffee and it is the same Mix. Water and Milk implement the same Interface. Sugar and Coffee implement the same Interface.
When we look at this example we see when OOD is no longer describing the world, rather it is bending the world. When I started with OOD I was sold that this methodology describes the world the way we think in everyday life. I now know that this is clearly not the case. OOD is only better than Procedural Programming.. in many but not all ways.
Let’s talk about Flows and Layers, Phases and States, Requirements and User Experience, Objects and Graphics. Today, using OOD, we address only some of these issues and sometimes use UML to loosely define what’s missing.
Asaf
That post created a live discussion that also continued to forums on other websites. It seems that we got so used to OOP and OOD that it sounds like it is the only way to go, making it difficult to ask questions about it. The live discussion just shows that there are many schools of programming even though OOP was considered the last big thing (with C++, Java, C#, etc.)
Here are a few arguments that I am addressing. (Obviously if you agree with the article I am just going to nod).
“One of the best possible solutions to manage complexity is to divide it”
- I agree. The problem is that OOD is not only dividing, it is also hiding.
“Better question: is execution flow relevant?”
“Maybe it is not necessary to control or care about the whole execution flow”
“When you send a message to an object and you don't get the desired result then maybe you are delegating into the wrong object”
- This just to show you that inheritance is strictly enforced but some other things that have greater importance to the product are not. Something huge is missing.
“With the understanding that object-oriented modeling, or rather modeling in general”
- OOD is just one way of modeling. The argument is that stand alone it is a really bad way of modeling.
Just to explain where I come from, I can do OOP. Here is an example:
http://www.asyncop.com/MTnPDirEnum.aspx?treeviewPath=%5bo%5d+Open-Source%5cWinUSB+Component
I can also do procedural programming:
http://www.asyncop.com/MTnPDirEnum.aspx?treeviewPath=%5bo%5d+Open-Source%5cProject+Publisher%5cProjectPublisher.cs
These were C#. Here is some C++:
http://www.asyncop.com/MTnPDirEnum.aspx?treeviewPath=%5bo%5d+Open-Source%5cWinModules
I am not saying that OOD is bad. I am saying that it is not enough. Actually it is far from enough. There are so many things missing there.
It is clear to me that people want answers and not just problems. We are going to cover this in a series of videos. Estimated approximately 3 to 4 hours in total, a nice portion is dedicated to design. We shot these videos at Intel’s Studios in Oregon right after the IDF 2011 event. Use the RSS Feed to be notified when the first segment is edited and released.
A few words about this here: /en-us/videos/black-belt-developer-asaf-shelly-at-idf-2011/ Timestamp 06:20. You can also see Clay Breshears there (for whomever was wondering who he was).
Let me start by saying that it is absolutely necessary to control the execution flow and here is the reason:
An application starts with an SRS document which defines the Requirements, or “the things that the application needs to do”. Moving on we have OOD which defines the objects that we use. Can you see the point? Something is missing. How do you go from “Action Required” to “Software Components”?
The answer is that you have an architect in between and that architect is doing something informal which is almost an art. Can you count the projects that failed because the architecture was perfect OOD but could not meet up with changing requirements? Can you prove to the product owner that the code is meeting the SRS list without any definition of flow? Test Driven Design methodology claiming that you can create a product only by detecting faults failed so badly that I am starting to think that Darwin's Evolution is only proof that there is a god… (Can’t wait to read your comments about that :)
A very important thing to say: Software modeling is not OOD. The argument is not whether to use OOD or not to model your system. The argument is that OOD is a part of system modeling but was sold to us as The way to do software design.
Here are some problems I find with OOD and OOP:
- People think that by using OOD they have a good definition of their systems, but they don’t respond to the SRS list of requirements which is the point of existence for the application.
- OOD defines “what the application is” with no regards to “what the application does”. This leads to situations in which changing requirements only reflect on code. In other words only the programmer really knows what’s going on in the code and how requirements are met.
- OOP will enforce usage of objects to create a good software block diagram but allows other bad things such as calls ping-ponging from one object to another making bug tracking an impossible mission and thus we get the after effect Test Driven Design.
- OOP usually comes with strange rules that produce an even nicer software block diagram but completely kill performance and requirement traceability such as “keep methods up to three lines of code”.
- In OOP and OOD, a method and an object do not know the operations that they take part of. This is VERY bad because you cannot cancel an operation of you have no definition of what is an operation. OOP today uses the Stack and the Thread to define the operations. This produces an unbelievably bad User Experience. “Application Not Responding” only is a direct result of OOP.
I am not saying that OOP is bad. It is nice. Just as we had procedural programming and then procedures became methods in an object, we need to have objects as part of something more important.
If Water is an object and Sugar is an object, what is Mix? I can also mix Milk and Coffee and it is the same Mix. Water and Milk implement the same Interface. Sugar and Coffee implement the same Interface.
When we look at this example we see when OOD is no longer describing the world, rather it is bending the world. When I started with OOD I was sold that this methodology describes the world the way we think in everyday life. I now know that this is clearly not the case. OOD is only better than Procedural Programming.. in many but not all ways.
Let’s talk about Flows and Layers, Phases and States, Requirements and User Experience, Objects and Graphics. Today, using OOD, we address only some of these issues and sometimes use UML to loosely define what’s missing.
Asaf
Symbol-Bild:
