On the other hand, when dependencies are well managed, the code remains flexible, robust, and reusable. Indeed, I talk about several different design smells in the PPP book, all relating to dependency management. Poor dependency managment leads to code that is hard to change, fragile, and non-reusable. Whenever we bring up on our screens a nasty batch of tangled legacy code, we are experiencing the results of poor dependency management. Dependency Management is an issue that most of us have faced. The principles, however, focus very tightly on dependency management. Certainly many people get value out of these aspects of OO. This is not to say that OO is a poor tool for conceptualization of the problem space, or that it is not a good venue for creating models. These principles expose the dependency management aspects of OOD as opposed to the conceptualization and modeling aspects. You'll see them documented in my PPP book, and in many articles on the objectmentor website, including a well known summary. In March of 1995, in comp.object, I wrote an article that was the first glimmer of a set of principles for OOD that I have written about many times since. In this blog I want to talk about the principles of object oriented programming. In another blog I'll discuss the principles of structured programming. All too often today's programmers are unaware of the principles that are the foundation of the disciplines that their languages were derived around. Programs written in these languages may look structured and object oriented, but looks can be decieving. Most of our mainstream languages are class based and do not support functions or variables that are not within a class, therefore they appear to obey the most obvious trappings of object oriented programming. Our mainstream languages do not have goto, and therefore appear to obey the most famous proscription of structured programming. Indeed, it has become difficult to write a program that does not have the external appearance of both structured programming and object oriented programming. All of our mainstream modern languages are strongly influenced by these two disciplines. Structured Programming and Object Oriented Programming. Of all the revolutions that have occurred in our industry, two have been so successful that they have permeated our mentality to the extent that we take them for granted. Yet the question is important because, it seems to me, that most of us use those languages without knowing why, and without knowing how to get the the most benefit out of them. This is what the Dosa Maker Modules look like.The Principles of OOD What is object oriented design? What is it all about? What are it's benefits? What are it's costs? It may seem silly to ask these questions in a day and age when virtually every software developer is using an object oriented language of some kind. Rahul: "Stop talking nonsense! If we don’t duplicate, then who will pay for your salary? :)" Mohan: "In that case, why do we need a V2? Can’t we use the same code here?" So now it’s our responsibility to sunset their current project The Dosa Maker and come up with an innovative design for the brand new The Dosa Maker V2.0." Rahul: "As you already know, the US team is moving on to another project. Rahul: "Congratulation on your promotion Mohan!" Mohan: "Thanks, Rahul." Mohan was sitting in his room, waiting for his next task to be assigned after promotion. This principle helps us to maintain, test and scale the codebase easily because changes in requirements do not affect multiple areas of the codebase. In other words, a class should have only one reason to change and it should be focused on doing one thing well. The Single Responsibility Principle (SRP) is one of the SOLID principles in software engineering that states that every module or class should have only one responsibility and that responsibility should be entirely encapsulated within the class.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |