Muutke küpsiste eelistusi

Object-Oriented Design Choices [Kõva köide]

1.00/5 (1 hinnangut Goodreads-ist)
  • Formaat: Hardback, 348 pages, kõrgus x laius: 234x156 mm, kaal: 453 g, 21 Tables, black and white; 14 Illustrations, black and white
  • Ilmumisaeg: 19-Jan-2021
  • Kirjastus: Chapman & Hall/CRC
  • ISBN-10: 0367820811
  • ISBN-13: 9780367820817
Teised raamatud teemal:
Object-Oriented Design ChoicesSuurem pilt
  • Formaat: Hardback, 348 pages, kõrgus x laius: 234x156 mm, kaal: 453 g, 21 Tables, black and white; 14 Illustrations, black and white
  • Ilmumisaeg: 19-Jan-2021
  • Kirjastus: Chapman & Hall/CRC
  • ISBN-10: 0367820811
  • ISBN-13: 9780367820817
Teised raamatud teemal:
Püsilink: https://www.kriso.ee/db/9780367820817.html
Märksõnad:
"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"--

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.

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.

Arvustused

"The introduction of object-oriented programming was a pivotal moment in software engineering, leading to a new way of creating systems by modelling their constituents independently and linking them through shared interfaces. Object orientation allows for the creation of more complex systems, better focus on a small subset of components at any given time, and a greater level of component independence; it even facilitates the creation of software product lines. Designing a system using object orientation requires the mastery of several interdependent concepts, such as abstraction, inheritance, composition, and polymorphism. Dingle (Seattle Univ.) provides a cohesive framework for learning object-oriented design from a practical point of view. Concepts are introduced hierarchically, starting from the idea of encapsulation and design as a contract and drilling down to specifics such as virtual function tables and abstract classes. This approach results in an incremental experience of learning object-oriented design that is rarely found in computer science courses, but that is essential for software engineers who wish to harness the power of object-oriented programming languages in practice. Although no book can fully replace hands-on bench experience, this compact guide can ensure that one's practical efforts will be optimally targeted.

--L. Benedicenti, University of New Brunswick

Review in April 2022 Issue of CHOICE

Preface xi
Acknowledgements xv
Detailed Book Outline xvii
Section I Stable Type Design
Chapter 1 Contractual Design and the Class Construct
3(26)
1.1 Encapsulation
3(1)
1.2 Explicit Design and Constraints
4(12)
1.2.1 Class (Type) Functionality
5(4)
1.2.2 Constructors
9(3)
1.2.3 Accessors and Mutators
12(2)
1.2.4 Utility and Public Methods
14(1)
1.2.5 Destructors
15(1)
1.3 Design as a Contract
16(5)
1.3.1 Error Handling
17(1)
1.3.2 Published Assumptions
18(2)
1.3.3 Invariants
20(1)
1.4 Programming By Contract Example
21(4)
1.5 Contractual Expectations
25(1)
1.6 Oo Design Principles
26(1)
1.7 Summary
26(1)
1.8 Design Exercise
27(1)
Conceptual Questions
28(1)
Chapter 2 Ownership -- Abstracted but Tracked
29(30)
2.1 The Abstraction of Memory
29(2)
2.2 Heap Memory
31(3)
2.3 Ownership of Heap Objects
34(10)
2.3.1 Array Allocation
37(1)
2.3.2 Design Intervention
38(2)
2.3.3 Persistent Data
40(4)
2.4 Class Design
44(2)
2.5 Memory Reclamation
46(6)
2.5.1 C++ Explicit Deallocation
47(1)
2.5.2 Garbage Collection
47(3)
2.5.3 Reference Counting
50(2)
2.6 Design: Storage Versus Computation
52(3)
2.7 Oo Design Principles
55(1)
2.7.1 Responsibility Driven Design Principle
56(1)
2.8 Summary
56(1)
2.9 Design Exercise
57(1)
Conceptual Questions
58(1)
Chapter 3 Data Integrity
59(30)
3.1 Data Corruption
59(3)
3.2 Copying
62(7)
3.2.1 Shallow versus Deep Copying
62(1)
3.2.2 C++ Copying of Internal Heap Memory
63(6)
3.3 Unseen Aliasing
69(4)
3.3.1 C# Cloning to Avoid Aliasing
71(2)
3.4 Move Semantics
73(3)
3.5 Handle: C++ Smart Pointers
76(6)
3.5.1 Unique_Ptr
78(2)
3.5.2 Shared_Ptr
80(1)
3.5.3 Weak_Ptr
81(1)
3.5.4 Usage
81(1)
3.6 Oo Design Principle
82(1)
3.7 Summary
82(2)
3.8 Design Exercises
84(1)
Conceptual Questions
85(4)
Section II Strategic Type Coupling
Chapter 4 Composition
89(30)
4.1 Object-Oriented Relationships
89(1)
4.2 Containment (HOLDS-A)
90(2)
4.3 Composition (HAS-A)
92(9)
4.3.1 Modification
94(1)
4.3.2 Replacement
95(3)
4.3.3 Postponed Instantiation
98(1)
4.3.4 Echoing an Interface
99(2)
4.4 Interfaces for Design Consistency
101(2)
4.5 Wrappers and Delegates
103(3)
4.6 Dependency Injection
106(8)
4.6.1 Constructor Injection
107(2)
4.6.2 Property Injection
109(2)
4.6.3 Method Injection
111(1)
4.6.4 Dependency Injection Costs and Benefits
112(2)
4.7 Design Principles
114(1)
4.8 Summary
115(1)
4.9 Design Exercise
116(1)
Conceptual Questions
117(2)
Chapter 5 Inheritance
119(34)
5.1 Automate Type Checking
119(5)
5.2 Polymorphism
124(6)
5.2.1 Overloading
125(1)
5.2.2 Generics
126(1)
5.2.3 Subtype Polymorphism
127(1)
5.2.4 Function Inlining
128(1)
5.2.5 Costs and Benefits of Polymorphism
129(1)
5.3 Dynamic Binding
130(9)
5.3.1 Whoami() Type Identification
134(1)
5.3.2 Keywords for Dynamic Binding
134(5)
5.4 Heterogeneous Collections
139(3)
5.5 Virtual Function Table
142(1)
5.6 Abstract Classes
143(4)
5.7 Inheritance Designs
147(2)
5.8 Oo Design Principles
149(1)
5.9 Summary
149(1)
5.10 Design Exercises
149(2)
Conceptual Questions
151(2)
Chapter 6 Inheritance versus Composition
153(28)
6.1 Constrained Inheritance
153(7)
6.1.1 When Only Composition Is Viable
153(2)
6.1.2 When Inheritance Leaks Memory: C++ Destructors
155(3)
6.1.3 Inconsistent Access: C++ Accessibility and Binding
158(2)
6.2 Code Reuse
160(4)
6.3 Class Design: Has-A or IS-A?
164(2)
6.4 Inheritance With and Without Composition
166(6)
6.5 Software Maintainability
172(2)
6.6 Oo Design Principle
174(1)
6.7 Summary
174(1)
6.8 Design Exercises
175(2)
Conceptual Questions
177(4)
Section III Effective Type Reuse
Chapter 7 Design Longevity
181(30)
7.1 Software Evolution
181(1)
7.2 Disassembler Example
182(6)
7.2.1 Virtual Function Table
187(1)
7.3 Type Extraction
188(5)
7.4 Problematic Type Extension
193(3)
7.5 Multiple Inheritance and Its Simulation
196(6)
7.5.1 Design Difficulties
198(1)
7.5.2 Single Inheritance with Composition
199(1)
7.5.3 Simulation without Inheritance
200(2)
7.6 Class Hierarchies Cross-Products
202(4)
7.7 Oo Design Principle
206(1)
7.8 Summary
206(1)
7.9 Design Exercises
207(2)
Conceptual Questions
209(2)
Chapter 8 Operator Overloading
211(20)
8.1 Operators Represent Functions
211(2)
8.2 Overloading Addition in C++
213(7)
8.3 Client Expectations
220(1)
8.4 Operator Overloading in C#
220(3)
8.5 Operators Overloaded Only in C++
223(5)
8.5.1 Indexing Support
223(1)
8.5.2 I/O via the Stream Operators
224(2)
8.5.3 Type Conversion
226(1)
8.5.4 Transparent Access
227(1)
8.6 Oo Design Principle
228(1)
8.7 Summary
228(1)
8.8 Design Exercise
229(1)
Conceptual Questions
230(1)
APPENDIX A THE POINTER CONSTRUCT
231(16)
A.1 Pointer Definition
231(2)
A.2 Dereferencing Pointers
233(2)
A.3 Inappropriate Use of Pointers
235(1)
A.4 Transient Versus Persistent Memory
236(2)
A.5 References
238(3)
A.6 The this Pointer
241(2)
A.7 Arrays
243(2)
A.8 Summary
245(2)
APPENDIX B DESIGN EXERCISES
247(28)
B.1 Contractual Class Design
247(3)
B.2 Ownership: C++ Class Memory Management
250(4)
B.3 Copying
254(7)
B.4 Composition
261(7)
B.5 Inheritance
268(7)
APPENDIX C COMPARATIVE DESIGN EXERCISES
275(26)
C.1 Composition Versus Inheritance
275(12)
C.2 Design Longevity
287(11)
C.3 Operator Overloading
298(3)
Glossary 301(18)
Bibliography 319(2)
Index 321
Adair Dingle, PhD, is a professor of computer science at Seattle University, Washington, USA whose previous text, Software Essentials: Design and Construction, received the 2015 Alpha Sigma Nu Book Award. Teaching and research interests focus on algorithms and software design including efficient memory management, patterns, refactoring and tools for software development and education.