Object-Oriented Design Choices

A classic software engineering adage is "anyone can build a doghouse". The idea is that doghouses are not usually equipped with indoor plumbing, central heat and ventilation, and are not mortgaged, multistory or subject to building codes, etc. The list goes on. In contrast, a skyscraper must meet building codes, is likely multistory and multi-use, and, traditionally has underground parking, etc. The analogy for software development is that small-scale endeavors may be undertaken with far less overhead, and are subject to far less scrutiny than large-scale or complex systems. Design becomes more important as scale, complexity, and/or performance expectations increase. Why then read this book? The short answer is to study software design from a structured but hands-on perspective and to understand different designs to manage types, program memory, dynamic behavior, extensibility, etc. Software complexity, refactoring expectations, and the prominence of legacy systems motivate an interest in software design. We evaluate and compare designs in this text using and contrasting C# and C++ implementations. Software tools, standard libraries, testing methodologies, and modern IDEs have decreased the complexity of producing software. Hardware and environmental dependencies have been abstracted away. Data storage and retrieval have been streamlined. Utilities provide functions for sorting, selection, and comparison. Standard algorithms have been encoded. Yet, one design does not fit all. Many problems may be solved in more than one way. How does one choose the most appropriate design? This text emphasizes design choices. Many CS texts are 'learn to' books that focus on a specific programming language or tool. When perspective xii ◾ Preface is so limited, high-level concepts are often slighted. Students may gain exposure to an idea via a 'cookbook' implementation and fail to recognize foundational paradigms. Students and/or practitioners can apply principles more readily when design is explicitly defined, illustrated, and evaluated. This book analyzes competing design solutions, contrasting cost, and benefits as well and internal versus external perspectives. Expectations of code reuse trigger consideration of long-term versus short-term use. Design, not just syntax, must be stressed. ## WHO SHOULD READ THIS BOOK? This text originated from material developed and updated for an advanced undergraduate course on software design. Students then are a natural audience. Entry-level or immediate developers, especially those responsible for maintaining or refactoring a legacy system written in an Object-Oriented Programming Language (OOPL), may benefit from this explicit exposition of object-oriented design as well as the evaluation of design variants. Some software development experience is assumed, as is knowledge of basic data structures. Expertise with any particular language, platform, or IDE is not required. Auxiliary definitions and references are noted in the text. Appendix A reinforces indirection and details relevant to C++ and C#. Appendices B and C present and analyze substantive design examples. An extensive glossary is included, defining over 150 common terms associated with software design. Many students, colleagues, scholars, and professional associates contributed to the form and content of this book. Student feedback led directly to foundational design examples, reworked and extended for clarity and reuse as well as contrasting implementations. I especially appreciate student enthusiasm for contractual design and curiosity about sustainable designs. Software design is not new. Experts have endeavored for years to promote deliberate and effective design. Their writings and insights have enriched software development for many years -to note a few: Michael Feathers, Barbara Liskov, Scott Meyers, Bjarne Stroustrup. The Seattle University CS department has supported educational endeavors alongside an emphasis on professional development. Software design has thus been highlighted. I wish to thank many colleagues both in and outside US-to note a few: Renny Philipose, Susan Reeder, Roshanak Roshandel, Madalene Spezialetti, Ben Tribelhorn, and Yingwu Zhu. Special thanks to Lisa Milkowski, who read and edited several chapters. And, as always, sincere appreciation to Michael Forrest Smith for extraordinary wisdom blended with humor and optimism. This book has been prepared with the timely and professional assistance of the editorial staff of CRC Press/Taylor and Francis Group. Thanks to Talitha Duncan-Todd for patiently guiding me and for efficiently managing all details. Repeated thanks to editor Randi Cohen for supporting and overseeing this project as well as tracking and reinforcing educational currency. Most importantly, thanks to Tom Hildebrandt, a brilliant developer who can design or redesign anything. His early work on move semantics and his disassembler design are just two examples of his contributions to the professional software community. xviii ◾ Detailed Book Outline Section II: Strategic Type Coupling This section explores different ways in which to structure interdependent types, providing design examples, analyses, and guidelines. Chapter 4: Composition examines the has-a relationship, analyzing deferred instantiation, echoed interfaces, and wrapped delegates as sample designs that afford significant internal control. Dependency Injection is defined and evaluated as a technique that externalizes dependencies to promote flexibility and to enable testing. Chapter 5: Inheritance reviews the is-a relationship as a popular OOD choice, noting its overuse alongside analyses of costs and benefits. Language support of polymorphism, its costs, and utility via heterogeneous collections are noted. Chapter 6: Inheritance versus Composition contrasts composition and inheritance as design preferences, exploring costs and reuse potential. The validity of different inheritance designs, the viability of composition, and the efficacy of using composition alongside inheritance are evaluated. ## Section III: Effective Type Reuse This section provides a detailed evaluation of OOD variants with a particular emphasis on type reuse. Chapter 7: Design Longevity considers design sustainability. Discussion includes short-and long-term assessment of abstract types, polymorphic delegates, and interface extensions. Simulated inheritance provides a foundation for many design variants. Multiple inheritances and its simulation are covered. An abbreviated production code example is analyzed. Chapter 8: Operator Overloading proposes a type of design that mimics primitives via overloaded operators, permitting use in generic algorithms and containers. Again, designs are evaluated for language differences and consistency. ## Appendix A: The Pointer Construct This appendix covers the 'pointer' type, a language construct provided in C and C++, but not in C# or Java. Proper use as well as inappropriate handling is illustrated through pertinent examples. With its thorough coverage of indirection, Appendix A assists the C# or Java programmer who is learning C++. Detailed Book Outline ◾ xix and contractual designs are presented for class design, proper class memory management, copying, composition, and inheritance. Cover Half Title Title Page Copyright Page Contents Preface Acknowledgements Detailed Book Outline Section I: Stable Type Design Chapter 1. Contractual Design and the Class Construct 1.1. Encapsulation 1.2. Explicit Design and Constraints 1.2.1. Class (Type) Functionality 1.2.2. Constructors 1.2.3. Accessors and Mutators 1.2.4. Utility and Public Methods 1.2.5. Destructors 1.3. Design as a Contract 1.3.1. Error Handling 1.3.2. Published Assumptions 1.3.3. Invariants 1.4. Programming by Contract Example 1.5. Contractual Expectations 1.6. OO Design Principles 1.7. Summary 1.8. Design Exercise Conceptual Questions Chapter 2. Ownership – Abstracted but Tracked 2.1. The Abstraction of Memory 2.2. Heap Memory 2.3. Ownership of Heap Objects 2.3.1. Array Allocation 2.3.2. Design Intervention 2.3.3. Persistent Data 2.4. Class Design 2.5. Memory Reclamation 2.5.1. C++ Explicit Deallocation 2.5.2. Garbage Collection 2.5.3. Reference Counting 2.6. Design: Storage Versus Computation 2.7. OO Design Principles 2.7.1. Responsibility Driven Design Principle 2.8. Summary 2.9. Design Exercise Conceptual Questions Chapter 3. Data Integrity 3.1. Data Corruption 3.2. Copying 3.2.1. Shallow Versus Deep Copying 3.2.2. C++ Copying of Internal Heap Memory 3.3. Unseen Aliasing 3.3.1. C# Cloning to Avoid Aliasing 3.4. Move Semantics 3.5. Handle: C++ Smart Pointers 3.5.1. Unique_ptr 3.5.2. Shared_ptr 3.5.3. Weak_ptr 3.5.4. Usage 3.6. OO Design Principle 3.7. Summary 3.8. Design Exercises Conceptual Questions Section II : Strategic Type Coupling Chapter 4. Composition 4.1. Object-Oriented Relationships 4.2. Containment (Holds-A) 4.3. Composition (Has-A) 4.3.1. Modification 4.3.2. Replacement 4.3.3. Postponed Instantiation 4.3.4. Echoing an Interface 4.4. Interfaces for Design Consistency 4.5. Wrappers and Delegates 4.6. Dependency Injection 4.6.1. Constructor Injection 4.6.2. Property Injection 4.6.3. Method Injection 4.6.4. Dependency Injection Costs and Benefits 4.7. Design Principles 4.8. Summary 4.9. Design Exercise Conceptual Questions Chapter 5. Inheritance 5.1. Automate Type Checking 5.2. Polymorphism 5.2.1. Overloading 5.2.2. Generics 5.2.3. Subtype Polymorphism 5.2.4. Function Inlining 5.2.5. Costs and Benefits of Polymorphism 5.3. Dynamic Binding 5.3.1. Whoami( ) Type Identification 5.3.2. Keywords for Dynamic Binding 5.4. Heterogeneous Collections 5.5. Virtual Function Table 5.6. Abstract Classes 5.7. Inheritance Designs 5.8. OO Design Principles 5.9. Summary 5.10. Design Exercises Conceptual Questions Chapter 6. Inheritance Versus Composition 6.1. Constrained Inheritance 6.1.1. When Only Composition Is Viable 6.1.2. When Inheritance Leaks Memory: C++ Destructors 6.1.3. Inconsistent Access: C++ Accessibility and Binding 6.2. Code Reuse 6.3. Class Design: Has-A or Is-A? 6.4. Inheritance with and Without Composition 6.5. Software Maintainability 6.6. OO Design Principle 6.7. Summary 6.8. Design Exercises Conceptual Questions Section III : Effective Type Reuse Chapter 7. Design Longevity 7.1. Software Evolution 7.2. Disassembler Example 7.2.1. Virtual Function Table 7.3. Type Extraction 7.4. Problematic Type Extension 7.5. Multiple Inheritance and Its Simulation 7.5.1. Design Difficulties 7.5.2. Single Inheritance with Composition 7.5.3. Simulation Without Inheritance 7.6. Class Hierarchies Cross-Products 7.7. OO Design Principle 7.8. Summary 7.9. Design Exercises Conceptual Questions Chapter 8. Operator Overloading 8.1. Operators Represent Functions 8.2. Overloading Addition in C++ 8.3. Client Expectations 8.4. Operator Overloading in C# 8.5. Operators Overloaded Only in C++ 8.5.1. Indexing Support 8.5.2. I/O Via the Stream Operators 8.5.3. Type Conversion 8.5.4. Transparent Access 8.6. OO Design Principle 8.7. Summary 8.8. Design Exercise Conceptual Questions Appendix A: The Pointer Construct A.1. Pointer Definition A.2. Dereferencing Pointers A.3. Inappropriate Use of Pointers A.4. Transient Versus Persistent Memory A.5. References A.6. The This Pointer A.7. Arrays A.8. Summary Appendix B: Design Exercises B.1. Contractual Class Design B.2. Ownership: C++ Class Memory Management B.3. Copying B.4. Composition B.5. Inheritance Appendix C: Comparative Design Exercises C.1. Composition Versus Inheritance C.2. Design Longevity C.3. Operator Overloading Glossary Bibliography Index Do modern programming languages, IDEs, and libraries make coding easy? Maybe, but coding is not design. Large-scale or expensive apps clearly require evaluation of design choices. Still, software design directly impacts code reuse and longevity even for small-scale apps with limited overhead. This text evaluates and contrasts common object-oriented designs.A given problem may have many solutions. A developer may employ different design techniques – composition, inheritance, dependency injection, delegation, etc. – to solve a particular problem. A skilled developer can determine the costs and benefits of different design responses, even amid competing concerns. A responsible developer documents design choices as a contract with the client, delineating external and internal responsibilities. To promote effective software design, this book examines contractual, object-oriented designs for immediate and sustained use as well as code reuse. The intent of identifying design variants is to recognize and manage conflicting goals such as short versus long-term utility, stability versus flexibility, and storage versus computation. Many examples are given to evaluate and contrast different solutions and to compare C# and C++ effects. No one has a crystal ball; however, deliberate design promotes software longevity. With the prominence of legacy OO code, a clear understanding of different object-oriented designs is essential.Design questions abound. Is code reuse better with inheritance or composition? Should composition rely on complete encapsulation? Design choices impact flexibility, efficiency, stability, longevity, and reuse, yet compilers do not enforce design and syntax does not necessarily illustrate design. Through deliberate design, or redesign when refactoring, developers construct sustainable, efficient code. "Do modern programming languages, IDEs and libraries make coding easy? Maybe, but coding is not design. Large-scale or expensive apps clearly require evaluation of design choices. Still, software design directly impacts code reuse and longevity even for small-scale apps with limited overhead. This text evaluates and contrast common object-oriented designs. A given problem may have many solutions. A developer may employ different design techniques -- composition, inheritance, dependency injection, delegation, etc. -- to solve a particular problem. A skilled developer can determine the costs and benefits of different design responses, even amid competing concerns. A responsible developer documents design choices as a contract with the client, delineating external and internal responsibilities. To promote effective software design, this book examines contractual, object-oriented designs for immediate and sustained use as well as code reuse. The intent of identifying design variants is to recognize and manage conflicting goals such as: short versus long-term utility, stability versus flexibility, storage versus computation. Many examples are given to evaluate and contrast different solutions, and to compare C# and C++ effects. No one has a crystal ball. However, deliberate design promotes software longevity. With the prominence of legacy OO code, a clear understanding of different object-oriented designs is essential"-- Provided by publisher