In the modern program languages like .Net, object-oriented-programming concepts are baked into the language, but that does not mean we programmer immediately become a OOP programmer when we started to write code in .Net. 20 years ago, I have seen a programmer wrote his entire C++ program in one class while using C++ compiler. I have seen people using COBOL85 compiler writing the code that can be compiled by COBOL74 compiler..
In a project I was involved, there is an item in NFRS says :
The system shall use object-oriented development principles such as encapsulation, inheritance, and polymorphism to support a UML-oriented design process.
and the response to that was:
The software product meets the requirement. The framework of the product is based on Microsoft’s .NET framework and uses VB.NET as the programming language which is a fully object-oriented programming (OOP) language. Various modules within the system use the OOP principle of encapsulation, inheritance and polymorphism.
while one of the architects told me not to mention OOP to much as we are doing SOA.
I thought more elaboration or assurance on how to meet the requirement could serve the requirement better.
The point I like to make here is: OOP programming languages facilitate programmers writing program observing OOP principles, but it does not prevent programmer from writing non-OOP program. Once the decision is made on programming language, the person who writes the program is the determining factor on how these OOP principles are observed.
During my vacation, my wife and I attended a piano recital which my 6 years old daughter is one of the performers range from having learned piano for 5 years to young pianist like my daughter who only have touched piano for less than a year. During the performance, the same set of pianos were used, different pieces of music were performed, in some case, the same piece of music was performed by different performers on the same piano. You guessed right. Even people like me can tell the difference. sometime the difference is so huge! Like people said "the difference is between the chair and the keyboard". In my daughter’s piano recital case, it is between the bench and the keyboard.
In the old days, designers document their design in writing, the programmers convert that into code, that’s why "programmer" was also referred as "coder". In modern programming world, from the time you started touch your code in IDE till you check in your code and complete your task or bug fixing, you are engaging in design all the time. Programming work is a highly intelligence work. That’s why we are referred as "knowledge worker" now a days. It has nothing to do with "copy and paste" or "cookie cutting". we no longer been addressed as "coder" anymore! we are the developers!
Yes, we are the software developers developing software, like home builders building homes. A of software product is made of packages, a package is made of components, a component is made of classes and interfaces, a class is made of members like properties, methods and other elements. The developing activities is building these software elements so that collectively, the software is capable of implement certain business process. The processing of programming is a process of building software elements so that the business requirements can be fulfilled by using the elements we build (as comparing to doing something to fulfill the business requirement). When you write a method, when you write a class, you are building these elements for the software. You are not the ONLY consumer of the software elements you are building. They can be consumed by other methods, other classes, or other components. Most importantly, these consumers could be very well possible are going to be written by your fellow developers now or in the future. In another word: you are building class library for the software. if the class library we are building is incomplete, or not consumer friendly or misleading or could be abused for unintended purpose, we are in danger of producing this bad smell.
This is what the author said about this smell " Reuse is often touted as the purpose of objects. we think reuse is overrated ( WE JUST USE!). "The term of "reuse" suggests something is built for its own primary purpose, then can be reused for other purpose as bonus. In OOP programming, once a software element is build, it is made available for the rest of the system. when you write a software element, do not only care for your own purpose, think for others.(sometimes, when I suggest to make some changes to a method or a property, I got some response saying " no, we cannot do that, it will impact many places!". well, if the method or the property is named right, if they are all used rightfully. you want your changes impacting all these places! That is the idea of OOP! If your changes negatively impacting some places, there are only 2 reasons 1) the method was named wrong so that suggested wrong use, 2) it was wrong to reference the method at that places.) Fail in doing so will result in "Incomplete Library" or "Incomprehensive Class Library"
However, the preventive measures to the smell is quite simple: Think more before writing, When you find something was not named properly, refactor it! The guidelines on preventing this smell are the following:
1.Naming your software element (class, method, property, event) accurately and with proper abstraction level.
2.Consider all possible consuming scenarios
3.Define proper accessibility ( public, private, internal, protected)
The key technic in programming practices is review the code you wrote outside the context of the feature or defect you are working on. If they still make sense outside of your context, you are building software elements, otherwise, you are doing things for yourself which may cause more trouble in the long run the software development life cycle..
The result of this smell are duplicated logic written in multiple places, convoluted functionalities provided repeatedly with similar names in different place or in the same place. From software development business point of view, like all other bad smells, it is one of the contributing factors to high development cost, huge code base size, high defect rate, high defect reopen rate, and high cost of fixing them. These symptoms collectively lead to over budget, behind schedule, aged and unstable software product. It is not unusual that they cause the project get killed before the software product goes to production. I myself have witnessed a few in my decades of software development career. so do not repeat the mistakes others have made. learn from their mistakes and produce high quality software with lowest possible cost!
Programming work should be an enjoyable work, make it so!
As always, comments, feedbacks, suggestions are most welcome on either the content of this article or topics of future weekly articles…
you can communicate with my in public or in private, anyway you feel comfortable…
Programming work should be an enjoyable work, make it so!
No comments:
Post a Comment