A about anything related to object-oriented design(programming) - Literature review Example

 Title: Literature Review- Principles of Object Oriented Design Abstract Every field of life is guided by a set of principles that provide it the required direction. Software designing is also such a field that requires some set of principles to identify the traits and properties of a good design. Principles of object oriented design highlight the factors that should be present in a specific design to attain flexibility, extendibility and mobility in the resulting software application. Five principles of class design have been discussed along with their pros and cons. 1. Introduction A methodology can be defined as a process in which some issues might be addressed regarding an existing system or the approach for building a new system might be discussed. Over the years, there have been many methodologies adapted for the analysis and design of systems. Some of them are Structured Systems Analysis and Design (SSAD), Rapid Application Development (RAD), Object-Oriented Analysis and Design (OOAD). However one of the approaches that are frequently used by developers is object oriented analysis and design. The respective idea was generated in the late 60s when programs and software started getting very complex. Object Mentor.com (2006) stated that the main purpose behind the inception of this concept was to model software on the basis of real-world object. The simplicity of the logic of the object oriented design attracted much attention from the developers and they started accepting it to a great extent. Principles tend to provide a structured format of implementing and understanding something. Object oriented design is also based on some principles that provide the essence of object oriented approach in the software and prove to be a guiding factor in the direction of attaining a good design. The design is the vital image of the software and thus needs to represent all aspects in an effective yet simple manner. Martin (2000) pointed out that a good design will not be rigid or fragile; rigidity will cause the software to become inflexible to changes and fragility will cause the software to break at some places in case of eventual changes in the requirements. Principles tend to keep the software safe from such inconsistencies and constraints. Another aspect that is addressed by the presence of principles is immobility. Immobility is the inability of the software to be reused with other software that results in re-writing. If designs are based on the guiding principles then software can be easily used with other programs and modules. These principles tend to address an important aspect of software programming i.e. dependency management. Dependency management denotes the level of flexibility that can be expected from a program or module. Poor dependency management will denote the fragility, inflexibility to change and incompatibility with other programs thereby reducing the possibility of reuse. Therefore it is very important for the dependency management to be given priority in the development processes. 2. Materials and Methods The literature review has been carried out on the basis of the following methods and materials: Secondary sources: Books, journal articles and white papers related to the area of object oriented design and analysis have been studied. Online and offline articles: Online and offline technological magazines have been studied for the respective research topic and the characteristics of a good design of software. Personal Observation: An extensive analysis was carried out on the basis of personal designing experiences regarding the object oriented approach. The research study began with the basic concept of object oriented design that led to the investigation of the basic principles that govern an object oriented design of software. The limitations and constraints that account for the poor quality of a design were also analyzed. Object oriented design has become an important part of modern software. The applications of object oriented design were investigated that are commonly witnessed in the computer industry. 3. Results Extensive research has been conducted to grasp the true essence of the principles of object oriented designs with the help of the above stated sources. The application of the principles should be done on need basis. Subramaniam (n.d.) also supported the notion and stated in his paper that if the application is not done as a result of some requirement then the design will prove to be complex and difficult to comprehend. The requirements must be judged that would point to the possibility of the application of the principle. Martin (2000) presented 11 principles of object oriented design, which are then classified into sub groups; Five principles of class design Three principles of package cohesion Three principles of package coupling 3.1 Five Principles of Class Design The principles of class design have been chosen as the focus of the current research study. They are also known as SOLID, referring to the initials of their names; Single Responsibility Principle (SRP) Open Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle (DIP) 3.1.1 Open Closed Principle (OCP) The most important principle of the object oriented design is the Open Closed Principle. Bertrand Meyer is the man responsible for the derivation of this principle. It was published in the first edition of his famous book ‘Object Oriented Software Construction’ by Meyer (1997). Meyer (1987) also developed the Eiffel language that is based on the principles of object oriented design. He explained that ‘a class should be open for extension purposes yet closed for modification’. The aim of this principle is to promote the development of such modules that they do not need to be changed at any point of time. The software entities must cater extensibility but not modification since that would threaten the existing functions possibly being used by other software entities. Tarr (2004) termed these two aspects of the principles as the conditions that should be met by the software if the respective principle is applied. The new requirements should be added in the form of new sub classes and methods may be overridden to perform new tasks. However, the old code should not be changed. The name of the principle denotes the true aspect of the principle; ‘open’ means that the software program should be open for extensibilities (either by overriding or inheritance) and ‘closed’ means that the older code is not allowed to be changed. The ‘closed’ condition stops the developer from introducing new bugs in the old code. The application of the principle can be done with the help of concrete classes and abstract classes. Preiss (2001) defined an abstract class as a class that may define the interface but will not provide implementation for all of its functions. It serves as a base class from which sub classes can be derived and member functions of the sub classes can override the base class functions. The subclasses that provide the functionality for the functions in the abstract classes are termed as concrete classes. One of the conditions of making an abstract class is to make a pure virtual function in the class. Pros and Cons It is not possible for all the modules to be designed according to the open closed principle but the aim should be to minimize the number of non-complying modules. As the number of non-complying modules decrease, the reusability and maintainability factors of the software increase. The design does not get too complex since the older code remains constant. The condition of not changing the older code proves to be difficult to implement and requires great expertise to be achieved. Amateur developers will need to take guidance in order to implement this principle. 3.1.2 Responsibility Principle (SRP) This principle promotes the separation of responsibilities in different classes i.e. every responsibility should be handled by a separate class. The reason for the separation is that responsibilities are the main focal point of changes; the later changes in the requirements can be incorporated easily in the design. On the contrary, if many responsibilities are being handled by one class then it will not be advisable to incorporate any further changes in it because the existing functionalities might be disturbed (OODesign.com, 2010). Martin (2000) defined the responsibility as the ‘reason to change’; this reference makes it easy to understand the principle that there should not be more than one reason for a class to change. If more than one responsibility is found in a class then they all tend to be coupled and difficult to be separated later. This principle has been discussed in the findings of DeMarco (1979) and Jones (1988); they both called it cohesion. Aivosto.com (2010) defined cohesion as the measure of the strength of the relations or focus of the responsibilities that are present in a single module. A cohesive class tends to perform functions for a single purpose. Pros and Cons The design will stay simple since each class will have only one responsibility. Later changes in requirements will not cause the previous classes to be effected. If this principle is not followed then design keeps on getting complex and creates problems for the resources that shall be responsible for the maintenance of the software. It is a simple principle, however, it is not too easy to implement. This principle proves to be ineffective in terms of reusability of the code. 3.1.3 Liskov Substitution Principle This principle promotes the substitution of the derived classes in place of the base classes. Liskov and Zilles (1974) devised this principle and stated that the sub-classes should be completely substitutable for their base classes. A more practical definition was quoted by Object Mentor.com (2006) and Subramaniam (n.d.); functions that accept pointers or references to the base classes should also be able to accept the pointers or references of the derived classes. The difference between the base class and derived class objects should be transparent to the user. Figure 1: LSP Schema (Object Mentor.com, 2006) According to figure 1; if a ‘User’ function takes an argument of ‘Base’ type then it should be considered a legal move to pass the derived object to it. LSP can be considered as an extension to the open closed principle since it is an important aspect of the modules that comply with the open closed principle. Pros and Cons LSP enables the reusability of functions since the same functions are able to accept different arguments i.e. base as well as derived classes objects. This principle is not hard to comprehend if the developer is familiar with the concept of polymorphism. However, this reusability is a resultant of inheritance that will bring about few issues; Raabe (2010) stated that the reused code functionalities cannot be changed at run time since inheritance relations are set at compile time. 3.1.4 Dependency Inversion Principle Subramaniam (n.d.) described the principle and stated that the high level modules should not depend on low level modules. Instead, both the levels should be dependent upon abstractions. Michelson (2002) defined abstraction as the instance when an object is explained in simpler details than its real form. It is adapted by programmers to handle the complexity level of software. Abstraction involves highlighting the important properties of an object while ignoring the irrelevant ones. This principle points out the dependency direction with respect to abstraction and promotes that the low level classes should be dependent on the high level classes. Object Mentor.com (2006) gave more importance to the high level modules instead of the low levels because he believed that the high modules of the application contain the identity of the application along with important data. Martin (2002) stated that another drawback of dependency on low level modules is that it gets very difficult to reuse the high level modules differently from the existing usage by the low level modules. Figure 2: Conventional form of dependency (Martin, 2002) Figure 3: Dependency on Abstraction (Martin, 2002) The important characteristics of a design, namely immobility, fragility and rigidity (explained in the previous sections) are directly related to the interdependency that might exist in a module or program. Software will be termed as rigid if changes are not easily facilitated by it; if there exists great deal of interdependency in the design then a single change will bring about a chain of changes. A module or program may break at some places if there exist interdependency between different functionalities. This would be enough to term the software as ‘fragile’. Object Mentor.com (2006) explained that a module or program will be considered ‘immobile’ if only some parts of the software are required but due to the interdependency of the module those parts cannot function without the presence of other parts. Pros and Cons OODesign.com (2010) described some drawbacks of this principle and stated that the respective code requires greater effort to implement as compared to the conventional dependency structure. However, the greater effort makes the software flexible and mobile. Cunningham & Cunningham, Inc. (2010) pointed out that the application of this principle is not possible for every class and every module therefore careful analysis needs to be done regarding the decision of its implementation. 3.1.5 Interface Segregation Principle It is often witnessed that clients possess the same interface files as the other clients. It reduces the efforts of the respective developers but the interdependency of such sort effects the clients in the future. The shared interface might go under a certain change due to a specific client’s demand. The area where the change is made might not be used by the other clients but it will become effective even at the other clients’ side. This change might not be welcomed at the other client’s side. This is known as ‘fat’ interfaces. According to Subramaniam (n.d.), the coupling of interfaces even increases the dependency level between the interfaces and thus directs the software towards a bad design. This principle tends to avoid such coupling of interfaces and promotes the separation of interfaces wherever possible. Object Mentor.com (2006) defined the principle and stated that clients should not be compelled to use the interfaces that have no value for them. In other words, the interfaces that are not used by them should not be possessed by them. OODesign.com (2010) stated that many small interfaces should be used in the place of a single fat interface. These small interfaces might be based on a set of required functions. There are several techniques that can implement this principle; one of the techniques is through multiple inheritances. The following figure is a sample of the design that can separate the interfaces: Figure 4: Separation of Interfaces through multiple inheritance (Object Mentor.com, 2006) Figure 4 has been adapted from the Adapter pattern; TimedDoor is inherited from Door as well as TimerClient. Objects of both the base classes have access to the derived class ‘TimerDoor’ but neither of them depends on it. This gives them the opportunity to use the same object via separate interfaces. Pros and Cons This principle will solve the issue of coupling and interdependency between the interfaces. It will also provide the clients with only desired interfaces. OODesign.com (2010) pointed out that this principle should be applied after careful consideration and experienced judgment because the consequences of excessive implementation will be numerous interfaces with single methods. Therefore the principle should be applied only in the places where extension might take place in the future. 4. Discussion After the extensive study of the principles of object oriented design, it can be stated that there are many techniques available to guide the developers about the attainment of a good design and architecture. The advent of object oriented design and analysis was witnessed in the late 60s and much research has been conducted since then. The principles of object oriented design were devised as early as the 1970s but they still hold valid for the current developments. They have formed the basis of design patterns and continue to provide flexibility, mobility and extendibility in software applications. Five principles of class design were studied and they have highlighted some factors that are required for a good design. The classes should be designed such that they do not need to be changed at frequent requirements from the client. This can be achieved only when the responsibilities are isolated. A class should only possess one responsibility; this will isolate the classes from changes that are not concerned with them. Isolation of classes from different responsibilities is also done to reduce the number of new bugs. Another design factor that has been discovered from the research findings is that modules should always have the capability of being extended for further enhancements. However, another aspect related to the extensibility of the project is that the new functionalities should not cause any changes in the existing classes therefore new functionalities should be introduced in the system in the form of sub classes. This approach also contributes to the reduction of new bugs in the system. Another principle (LSP) promoted an effective way of reusing the functions. It explained that derived classes should be complete substitutes of their base classes so that the derived class objects (or references) may be accepted in place of base class objects (or references). This principle promoted the concept of reusing the code as much as possible. Interdependency has been frequently witnessed in module and software applications. It was discovered after the research study that it can have adverse effects on the reliability and maintainability of the software. Interdependency tends to make the software fragile, immobile and rigid. Dependency Inversion Principle proposed a solution to refrain from the conventional dependencies. It enabled the high level modules to be free from the dependency on the low level modules. Another principle advocated the avoidance of interdependency and proposed the separation of interfaces of different clients. This principle explained that the coupling of interfaces increased interdependency therefore every client should have separate interfaces that might just be a group of required methods. References Aivosto.com, (2010), Cohesion metrics, Retrieved from: http://www.aivosto.com/project/help/pm-oo-cohesion.html Cunningham & Cunningham, Inc., (2010), Dependency Inversion Principle, Retrieved from: http://c2.com/cgi/wiki?DependencyInversionPrinciple DeMarco, T., (1979), Structured Analysis and System Specification, Press Computing Series Jones, M., P., (1988), The Practical Guide to Structured Systems Design, 2 ed., Yourdon Press Computing Series. Liskov, B., H., Zilles, S., N., (1974), Programming with Abstract Data Types, Cambridge Mass. Michelson, K., (2002), A Guided Tour through C#: Part 1, Retrieved from: http://www.informit.com/articles/article.aspx?p=26873&seqNum=3 Martin, R., C., (2002), Agile Software Development, Principles, Patterns, and Practices, Prentice Hall Martin, R. C., (2000), Design Principles and Design Patterns, Object Mentor.com, Retrieved from: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Meyer, B., (1997), Object-Oriented Software Construction, Prentice-Hall Resource. Meyer, B., (1987), Eifel Programming for Reusability and Extendibility, Interactive Software Engineering, Inc., Retrieved from: http://se.ethz.ch/~meyer/publications/acm/eiffel_sigplan.pdf OODesign.com, (2010), Single Responsibility Principle, Retrieved from: http://www.oodesign.com/single-responsibility-principle.html Object Mentor.com, (2006), What Is Object-Oriented Design? Retrieved from: http://www.objectmentor.com/omSolutions/oops_what.html Preiss, B. R., (2001), Data Structures and Algorithms with Object-Oriented Design Patterns in C++, Wiley & Sons Inc. Raabe, F., (2010), What are the disadvantages of using inheritance as a way of reusing code?, StackOverflow.com, Retrieved from: http://stackoverflow.com/questions/3294348/what- are-the-disadvantages-of-using-inheritance-as-a-way-of-reusing-code Subramaniam,V., (n.d.), Object-Oriented Design Principles, Retrieved from: http://www2.cs.uh.edu/~svenkat/SoftwareDesign/slides/ObjectOrientedDesignPrinciples. pdf Tarr, B., (2004), Some Object-Oriented Design Principles, Retrieved from: http://userpages.umbc.edu/~tarr/dp/lectures/OOPrinciples.pdf Read More