Object-Oriented Design Choices
Adair Dingle
- 328 pages
- English
- ePUB (adapté aux mobiles)
- Disponible sur iOS et Android
Object-Oriented Design Choices
Adair Dingle
Ă propos de ce livre
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.
Foire aux questions
Informations
II
Strategic Type Coupling
CHAPTER 4
Composition
CHAPTER OBJECTIVES
- Define OOD relationships
- Illustrate composition and containment
- Examine association, ownership and cardinality
- Introduce Dependency Injection
4.1OBJECT-ORIENTED RELATIONSHIPS
4.2CONTAINMENT (HOLDS-A)
push()
, pop()
, clear()
, etc. function in the same manner regardless of the type of data processed. The type of data stored provides no functionality and has little or no effect on containers. The holds-a relationship reflects little or no type dependency.replace()
.// transient ownership of subobject(s)
// implies memory management
// => must provide destructor
// => support or suppress copying
class Customer // replaceable gift card
// handle only, no object yet
{ GiftCard* c = 0;
public:
// assumption constructor: ownership
// of transfer
assumed
Customer(GiftCard*& transfer)
{ c = transfer;
transfer = 0;
}
// no argument constructor:
// no gift card allocated
Customer() { c = 0; }
// again ownership transferred in
void replace(GiftCard*& backup)
// dispose existing card
{ if (c) delete c;
c = backup;
backup = 0;
}
Ë Customer() { if (c) delete c; }
};