Object Oriented Best Practices - Summary
0 likes307 views
The document outlines essential best practices for object-oriented programming, emphasizing the importance of consistent class interfaces, encapsulation, and avoiding implementation exposure. It advises on the use of abstract classes, interfaces, and design patterns to promote code reusability and maintainability while warning against the pitfalls of deep inheritance and extensive use of reflection. Additionally, it recommends practices for avoiding code duplication, organizing namespaces, and ensuring that classes are coherent and loosely coupled.
Object Oriented Best Practices - Summary
- 1. Essential OO Best Practices 1. Provide a consistent and intuitive class interface. !Clients of the class should only need to know how to use a class and should not be forced to know how it provides the functionality. To achieve this, a class should provide a consistent interface that there is no ambiguity in using the class interface; it should also be intuitive to understand to avoid mistakes by the clients. !2. Provide common properties of classes in a base class. !The common properties of various classes should be identified and should be provided in a common base class (which can be an abstract class, concrete class, or interface). Providing methods in the base class interface is the basis of runtime polymorphism; it also avoids code duplication and unnecessary downcasts. !3. Do not expose implementation details in the public interface of the class. !The public interface is meant for external users. If the class interface exposes only implementation details of the class, it violates the rules of class abstraction; also any changes to internal details of the class can affect the interface of the class, which is highly undesirable. !4. Consider providing helper classes while designing large classes. !Consider separating the logical parts of the implementation detail or functionality from larger class and provide them as smaller helper classes. Also, when a small helper class is meaningful only in a limited context, and is used by a single class, prefer making that class as an inner/nested class of the class that uses it. !5. Keep the data members private. !Every object has an identity, state and behaviour. For objects, name and type provides identity, data members provide state and methods provide behaviour. Data members (that is, the state of the object) are considered as an implementation detail; so it is better to keep them private and expose only methods (that is, behaviour) as methods are preferable to be part of the public interface of a class. !6. Provide lowest possible access to methods. !Providing minimal access to the members of a class promotes encapsulation by hiding implementation details. By providing lowest possible access to the class members, the class is more cohesive and more decoupled from other classes; the internal implementation can also be more easily changed if the limited access is provided to the members. !7. Strive for loose coupling between classes. !Classes should either be independent of other classes or should use only the public interface of other classes. Strive for such loose coupling between classes because such classes are easy to understand, use, maintain and modify. !8. Beware of order of initialization problems. !Many subtle problems can happen because of order of initialization issues. Avoid code that depends on particular order of implementation as provided by the compiler or the implementation. !9. Write unit tests for classes. !An application that is built using various classes can be expected to work fine only if it is ensured that the classes work fine in isolation. Write unit tests to ensure robust implementation of individual classes. !10. Avoid low-level code. ©2006-‐2014. All rights reserved. Ganesh Samarthyam. Based on "60 Tips on Object Oriented Programming", Tata McGraw-‐Hill, 2006.
- 2. !Using low-level code is convenient for many situations, such as making use of legacy code, accessing platform specific features, efficiency etc. However, low-level code compromises portability, hampers software maintenance and reuse, and makes the application unsafe and un-secure. So, avoid writing or using low-level code. !11. Avoid calling virtual functions of the same class from constructors. !Constructors do not support runtime polymorphism fully as the derived objects are not constructed yet when base class constructor executes. So, avoid calling virtual functions from base-class constructors, which might result in subtle bugs in the code. !12. Consider providing factory methods. !Factory methods have many advantages over constructors. Depending on the situation, consider providing factory methods instead of constructors or in addition to existing constructors. !13. Make constructor private if there are only static members in the class. !When there are only static members in the class, there is no need to instantiate it; enforce this by making the default constructor of that class private. !14. Avoid creating unnecessary temporary objects. !Programming in object oriented way tends to introduce lots of temporary objects. To a large extent, programmers can consciously avoid creating such temporary objects. The techniques that can be used to avoid such temporary object creation are mostly language specific as languages differ on the ways and situations in which temporary objects are created. !15. Prefer creating immutable objects. !Immutable objects help us in avoiding bugs because of modifying the state, when it shouldn’t be done. Immutable objects have many advantages over the usual mutable objects, so it is recommended to use immutable objects whenever possible. !16. Consider creating and using null objects. !Providing sanity checks to avoid null pointer access or special casing the code to check for null condition can be avoided for container/utility classes by creating and using null objects. !17. Provide special objects with read only access in the class itself. !Consider providing specific special objects that are often required by the application readily in the class itself as read-only static fields. There is no need to create new objects of such special objects provided in the class and those objects can be used all over in the application safely. !18. Overload functions only if it is intuitive and unambiguous to the users. !Function overloading should improve the readability of the code and make the programming convenient. If the users find the overloading ambiguous or unintuitive, then it is not recommended to overload the functions. !19. Overload functions only if the functions do semantically the same thing. The methods that are semantically same should have syntactically same name, so use overloading; methods that differ semantically should have syntactically different names, so provide descriptive names. !20. Overload operators only if it is natural and improves the readability of code. !Operator overloading is meant for convenience in using user defined types like primitive types and it is also meant for improving the readability of the code. Overload operators only if the meaning of the operator is evident, un- ©2006-‐2014. All rights reserved. Ganesh Samarthyam. Based on "60 Tips on Object Oriented Programming", Tata McGraw-‐Hill, 2006.
- 3. ambiguous, natural, and intuitive for a given user-defined type; otherwise it will adversely affect the readability of the code. !21. Overload symmetrical operators or family of operators together. !When overloading an operator, if there are any related operators, overload those operators also. !22. Do not use inheritance when structure and behaviour are same for related classes. !Often beginners make the mistake of using inheritance relationship to model relationship of classes that differ in some value, when the class structure and behaviour remain the same. The correct solution is to keep that value as a data member in a class. !23. Prefer object composition over inheritance. !In many cases, inheritance and composition can provide equivalent functionality. Class inheritance is white-box reuse whereas object composition is black-box reuse. Since object composition is a better reuse model than class inheritance, favour composition over inheritance. !24. Avoid inheriting from multiple classes. !Understanding, supporting and using multiple inheritance to solve design problems can be complicated. The situations in which multiple inheritance is required are less-common and it is possible to arrive at equivalent solutions with single class inheritance itself. It is better to avoid using multiple inheritance. !25. Prohibit inheriting from a standalone class if the class is not meant for inheritance. !It is a good practice to make stand-alone utility classes as non-inheritable if the classes are not designed with inheritance in mind. !26. Consider making concrete leaf classes non-inheritable. !Base classes (or root classes) are designed having inheritance in mind for providing a common interface to the inheritance hierarchy whereas concrete (or leaf classes) are written for providing implementation and hence not for inheritance or for providing an interface. It is a well-known practice to consider making base classes abstract, but it is also equally important to consider making leaf classes as non-inheritable. !27. Write code referring to generic interfaces of classes. !Keep generality in mind and write the code for interfaces, rather than specific implementations; in this way, the code becomes extensible. In specific, when there is an abstract class or an interface available in a class hierarchy, prefer writing code in terms of referring to that interface instead of using any of the concrete classes directly in the code. !28. Beware of versioning problems in evolving base classes. !Evolving base classes can introduce versioning problems: Later versions of a base class might end up inadvertently overriding a method in the derived class in the client, which will result in breaking the client code. Beware of possible versioning problems in evolving base classes and avoid introducing virtual methods in later versions of base classes. !29. Avoid deep inheritance hierarchies. !It might be sometimes convenient to develop deep inheritance hierarchies. However, it is very difficult to understand, use, maintain and test classes in such hierarchies, so creating such deep inheritance hierarchies should be avoided. !30. Consider making common base classes as abstract classes. ! ©2006-‐2014. All rights reserved. Ganesh Samarthyam. Based on "60 Tips on Object Oriented Programming", Tata McGraw-‐Hill, 2006.
- 4. The abstract classes and interfaces help us to think about design in conceptual terms rather than worrying about implementation details. Instead of thoughtlessly mapping the application requirements into concrete classes to get the work done, it is better to spend time in finding the common properties in the concrete classes and map them into a abstract base class design and create reusable, extensible and flexible software. !31. Use abstract classes for modelling abstract properties and sub-classing. !Sub-classing refers to reusing interface and the implementation of a class; use abstract classes for modelling sub- classing. For related classes, provide the common functionality in an abstract base class and provide different implementations in separate concrete classes inheriting from it. !32. Provide default implementation class(es) with abstract classes or interfaces. !Abstractions have their own place in object oriented analysis and design. But without concrete classes, abstract classes or interfaces are not of much use. If you’re providing abstract classes or interfaces, ensure that you are providing at least one default implementation to make use of the abstract class or interface. !33. Use interfaces for sub-typing and multiple inheritance. !Sub-typing refers to reusing only the interface of a class; use interfaces for modelling sub-typing. Use pure interface classes to bind unrelated classes for some common functionality. Also prefer interfaces for supporting multiple inheritance. !34. Consider providing adaptor classes for interfaces. !Concrete classes that implement interfaces should provide the implementation of 'all' the methods, which is inconvenient in many situations. Provide adaptor classes for such interfaces providing the default implementation for the methods; this is for convenience as those adaptor classes will be easier to use. !35. Keep in mind that interfaces are difficult to evolve. !Pure class interfaces are difficult to evolve: Once clients have started using a pure interface class by implementing it, it is not possible to add or delete method declarations or make any modifications to the old method signatures; any such changes will break the client code. So strive for designing interfaces with an emphasis on establishing stability in the contract it provides. !36. Use virtual functions instead of chained if-else or switch statements. !Programmers from structured programming background tend to use extensive use of control structures. Whenever you find cascading if-else statements or switch statements checking for types or attributes of different types to take actions, consider using inheritance by replacing the if-else or switch code with virtual method calls. !37. Follow Liskov’s Substitution Principle (LSP). !Follow Liskov’s Substitution Principle (LSP), which is one of the cardinal rules to follow in object oriented programming. !38. Avoid using reflection extensively. !Reflection is a powerful feature, but using reflection exposes internal details of the classes. So, using reflection should be strictly avoided for solving high-level programming problems; it should be used only when knowing internal details of the classes at runtime is required. !39. Prefer using higher-level language features instead of reflection. !For most of the higher-level design problems, it is possible to provide acceptable solutions without using reflection. So, prefer using virtual functions or some other language features to achieve the same functionality instead of using reflection. ©2006-‐2014. All rights reserved. Ganesh Samarthyam. Based on "60 Tips on Object Oriented Programming", Tata McGraw-‐Hill, 2006.
- 5. !40. Avoid using RTTI extensively. !Other than safe uses such as performing downcasts and event-driven programming, RTTI should not be used for solving higher-level programming problems. Extensive use of RTTI when not necessary indicates that the design is bad and the implementation is brittle and un-maintainable. !41. Prefer using virtual functions instead of RTTI. !Extensive use of RTTI can potentially make maintaining the code difficult. Whenever you find cascading if-else statements for matching particular types to take actions, consider redesigning it by using virtual functions instead. !42. Use namespaces for avoiding name-clashes and organizing the software. !The techniques and approaches used for programming in large are considerably different from programming in small. One of the major objectives in programming in large is to support modular software and avoid name-clashes and versioning problems. By using namespaces effectively, programmers can create logical modules (set of related class) facilitating software distribution and maintenance. !43. Hierarchically partition the namespace. !One of the major benefits that object orientation provides is the ability to write reusable classes that can be used for wide range of projects instead of just providing code that will solve the specific needs. One of the widely used ways to organize such reusable software is in the form of class libraries that are organized (or partitioned) in a hierarchical format. Namespaces can be effectively used to provide a hierarchical organization of the software. !44. Selectively introduce only the specific namespace members you need to the code. !In general, it is a good programming practice to selectively introduce the names from a namespace to the code. This will avoid name-clashes that happen because of introducing all the members of namespace to the code. This will also avoid breaking the programs because of independent additions in the original namespace/package. !45. Selectively expose the types to the clients. !Namespaces play an important role in organizing software. One of the important ways in which namespaces help in organizing the software is to provide control to the programmers on the classes that are exposed to the clients. A programmer should use namespaces for providing public access, limited access or hiding the names in the application to the clients. !46. Avoid hiding of names in different scopes. !Hiding of names in different scopes is unintuitive to the readers of the code and using name hiding extensively can affect the readability of the program. Though hiding of names is a convenient feature, it is recommended to avoid name hiding as it can result in subtle defects and unexpected problems. !47. Strive for eliminating all forms of code duplication. !Code duplication is unnecessary and it can create major maintenance problems. There is no reason for any form of duplication of code and alternative approaches and solutions should be used for eliminating code duplication. !48. Use design patterns whenever appropriate. !Many of the problems in large-scale programming happen because of tight coupling between various software components. Design patterns reduce dependencies between the components; so, use them appropriately to create more flexible and reusable software. !49. Provide frameworks for effective reuse of architectural design. ! ©2006-‐2014. All rights reserved. Ganesh Samarthyam. Based on "60 Tips on Object Oriented Programming", Tata McGraw-‐Hill, 2006.
- 6. Frameworks can be very useful in providing solutions in specific application domains. Since frameworks support higher level architectural design reuse, it is preferable to provide frameworks or consider reusing existing frameworks. !50. Provide class libraries for any set of related reusable classes. !Instead of providing specific solution to the given problem, consciously identify reusable components and provide it as a class library. ! ©2006-‐2014. All rights reserved. Ganesh Samarthyam. Based on "60 Tips on Object Oriented Programming", Tata McGraw-‐Hill, 2006.