When I thought of writing about software design, I got struck in the beginning, got struck on the very first line. So many things are coming into mind which pushed me into some sort of confusion. I don’t know why but after some thought, I decided to name this article as “A comedy show”. Sincerely I’m telling I’m not sure what I’m going to write. I will just continue writing whatever comes to my mind. Read it at your own risk.
Shall I start?
May be I will start with kind of approaches people (designers) generally follow while designing the software.
First of that is Paper Design (Don’t try to search this in Google. You will not find anything). This way of design is very simple. Final goal of this design is straight forward. Goal is “Output of this design will not be used by any one”. It is just to prepare a document called software design document to prove the customer that you are strictly following software life cycle. Generally some previous design document will be copied and renamed. Where ever applicable project names will be changed. Previous class diagrams will be removed and new ones will be added. To arrive at these classes, no methodology will be followed. Surely after completion of coding, there will be no match with the actual classes with those in this document.
Second is Wholesale design. Combining requirements and design into one document. This kind of design does not involve any classes or components. It consists of requirements with screen designs. For the customer it is a requirements document but when you ask the project leader/architect about the design, he simply opens this document and will explain you about screens, inputs/outputs of each field on the screen.
Third one is Copy Paste design. I think this is the one which is most widely used. Another name given to this design is 3 tier architecture. Few people call this as MVC also (I’m not talking about Microsoft’s ASP.net MVC project types. I’m just saying in general.) I’m not trying to comment on the validity of this design. Approach may be correct but the way it is implemented is sickening.
Few designers, who think that they are following this design, simply add three layers to the solution/project. One layer holds user interfaces, other layer holds controller classes and other one holds data access classes. They just design user interface first. Add one controller for each interface. Add one data access class to the methods defined in the controller. That means if 10 user interfaces are there, 10 controllers and 10 data access classes will be there. To pass data between these layers, few model classes will be defined with get/set properties. That’s it. It completes the overall design of the software.
Sorry for the break.
Now I guess I’m clear on what to write in this post. I would like to comment on this style of design. Please continue.
In this approach, If any new comers are there in your team they may get an impression that software design is very simple. We just need to do screen designs. Then project design simply follows the screens. In single sentence, irrespective of the functionality, project design is common. I’m sure they may also wonder if project design is such a simple one, why architects are needed at all.
It seems in most of the cases, designers simply escape even though there are flaws in their design. Advantage they have is, unlike other phases of the project, it is tough to review and measure quality of the design.
Dear reader, If you are following 3 layered architecture in the same way, then I must say you are not doing any design. You are just simply doing sequential programming in three separate layers. You are doing object oriented design without objects.
I think design is all about identifying all the objects in the problem domain and establishing/defining clear cut relationship among them.
Sounds like bookish definition?
No don’t think it that way.
Just cross check with objects you are defining in your projects.
Do they have any task to do?
If I ask this question, I know you are getting into your mind methods/functions. I’m not talking about how you code your objects. Like in real world, every object you are defining should have some responsibilities to perform. If you simply define objects with some get/set properties and using them only to pass data between layers, we need to call them as dead objects. Objects with no life.
If objects in your project are not doing anything, then who is doing ? Either your user interface or controller class. That means you are assigning responsibilities of one object to something else. If you are not getting overall picture of your project after design then reason for that could be this only. Either you did not identify your objects properly or you are not sure of the responsibilities your objects should perform.
Knowingly or unknowingly assigning one object responsibilities to some other object (UI or Controller class objects in this case) may result in lot of orphan code(I mean to say code which supposed to be in one place but forced to be taken care by some other part of the code). One/two symptoms of this design I can say is,
Other critical thing is, establishing clear relationship between objects. In the copy paste design, objects are simply floating. All are open. Any object can talk to any other object. We should be meticulous in allowing communication between objects. Those relationships should be clearly defined. I do not like to give any generic example but just assume, “Your drawer is holding books which consist of pages”. If you find three objects in this scenario viz drawer objet, book object and page object, there should not be any relation between drawer object and page object. Drawer has to deal with only book object. It is headache of the book object to take care of the page(s) object.
My conclusion in this post is,
I think it is too big area to discuss in single post. Whenever I get excited to write on this topic I will surely post one again.
By the way, do you have some basic understating on what kind of relationship objects can have (association, aggregation, composition etc…) ? May be I should give you little theory on them first. I will try to post something on them as well.
Bye for now.
Shall I start?
May be I will start with kind of approaches people (designers) generally follow while designing the software.
First of that is Paper Design (Don’t try to search this in Google. You will not find anything). This way of design is very simple. Final goal of this design is straight forward. Goal is “Output of this design will not be used by any one”. It is just to prepare a document called software design document to prove the customer that you are strictly following software life cycle. Generally some previous design document will be copied and renamed. Where ever applicable project names will be changed. Previous class diagrams will be removed and new ones will be added. To arrive at these classes, no methodology will be followed. Surely after completion of coding, there will be no match with the actual classes with those in this document.
Second is Wholesale design. Combining requirements and design into one document. This kind of design does not involve any classes or components. It consists of requirements with screen designs. For the customer it is a requirements document but when you ask the project leader/architect about the design, he simply opens this document and will explain you about screens, inputs/outputs of each field on the screen.
Third one is Copy Paste design. I think this is the one which is most widely used. Another name given to this design is 3 tier architecture. Few people call this as MVC also (I’m not talking about Microsoft’s ASP.net MVC project types. I’m just saying in general.) I’m not trying to comment on the validity of this design. Approach may be correct but the way it is implemented is sickening.
Few designers, who think that they are following this design, simply add three layers to the solution/project. One layer holds user interfaces, other layer holds controller classes and other one holds data access classes. They just design user interface first. Add one controller for each interface. Add one data access class to the methods defined in the controller. That means if 10 user interfaces are there, 10 controllers and 10 data access classes will be there. To pass data between these layers, few model classes will be defined with get/set properties. That’s it. It completes the overall design of the software.
Sorry for the break.
Now I guess I’m clear on what to write in this post. I would like to comment on this style of design. Please continue.
In this approach, If any new comers are there in your team they may get an impression that software design is very simple. We just need to do screen designs. Then project design simply follows the screens. In single sentence, irrespective of the functionality, project design is common. I’m sure they may also wonder if project design is such a simple one, why architects are needed at all.
It seems in most of the cases, designers simply escape even though there are flaws in their design. Advantage they have is, unlike other phases of the project, it is tough to review and measure quality of the design.
Dear reader, If you are following 3 layered architecture in the same way, then I must say you are not doing any design. You are just simply doing sequential programming in three separate layers. You are doing object oriented design without objects.
I think design is all about identifying all the objects in the problem domain and establishing/defining clear cut relationship among them.
Sounds like bookish definition?
No don’t think it that way.
Just cross check with objects you are defining in your projects.
Do they have any task to do?
If I ask this question, I know you are getting into your mind methods/functions. I’m not talking about how you code your objects. Like in real world, every object you are defining should have some responsibilities to perform. If you simply define objects with some get/set properties and using them only to pass data between layers, we need to call them as dead objects. Objects with no life.
If objects in your project are not doing anything, then who is doing ? Either your user interface or controller class. That means you are assigning responsibilities of one object to something else. If you are not getting overall picture of your project after design then reason for that could be this only. Either you did not identify your objects properly or you are not sure of the responsibilities your objects should perform.
Knowingly or unknowingly assigning one object responsibilities to some other object (UI or Controller class objects in this case) may result in lot of orphan code(I mean to say code which supposed to be in one place but forced to be taken care by some other part of the code). One/two symptoms of this design I can say is,
- If you not able to see the overall picture of the project after design
- If you are struggling to understand the impact of the software changes in your project
- Not sure if you change the code in one place, which part of the code it is going to affect
Other critical thing is, establishing clear relationship between objects. In the copy paste design, objects are simply floating. All are open. Any object can talk to any other object. We should be meticulous in allowing communication between objects. Those relationships should be clearly defined. I do not like to give any generic example but just assume, “Your drawer is holding books which consist of pages”. If you find three objects in this scenario viz drawer objet, book object and page object, there should not be any relation between drawer object and page object. Drawer has to deal with only book object. It is headache of the book object to take care of the page(s) object.
My conclusion in this post is,
- Identify all the objects in your problem.
- Be sure of the responsibilities your objects should perform.
- Establish clear relationships between your objects.
I think it is too big area to discuss in single post. Whenever I get excited to write on this topic I will surely post one again.
By the way, do you have some basic understating on what kind of relationship objects can have (association, aggregation, composition etc…) ? May be I should give you little theory on them first. I will try to post something on them as well.
Bye for now.
No comments:
Post a Comment