Design Patterns

Question 1

Redesign Cause #1:
Creating an object by specifying a class explicitly.

Answer 1

Design Patterns: Abstract Factory, Factory Method, Prototype

Specifying a class name when you create an object commits you to a particular implementation instead of a particular interface. This commitment can complicate future changes. To avoid it, create objects indirectly.

Question 2

Redesign Cause #2:

Dependence on Specific Operations

Answer 2

Design Patterns: Chain of Responsibility, Command

When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and at run-time.

Question 3

Redesign Cause #3:

Dependence on Hardware and Software Platform

Answer 3

Design Patterns: Abstract Factory, Bridge

External operating system interfaces and application programming interfaces (APIs) are different on different hardware and software platforms. Software that depends on a particular platform will be harder to port to other platforms. It may even be difficult to keep it up to date on its native platform. It’s important therefore to design your system to limit its platform dependencies.

Question 4

Redesign Cause #4:

Dependence on Object Representations or Implementations

Answer 4

Design Patterns: Abstract Factory, Bridge, Memento, Proxy

Clients that know how an object is represented, stored, located, or implemented might need to be changed when the object changes. Hiding this information from clients keeps changes from cascading.

Question 5

Redesign Cause #5:

Algorithmic Dependencies

Answer 5

Design Patterns: Builder, Iterator, Strategy, Template Method, Visitor

Algorithms are often extended, optimized, and replaced during development and reuse. Objects that depend on an algorithm will have to change when the algorithm changes. Therefore algorithms that are likely to change should be isolated.

Question 6

Redesign Cause #6:

Tight Coupling

Answer 6

Design Patterns: Abstract Factory, Bridge, Chain of Responsibility, Command, Facade, Mediator, Observer

Classes that are tightly coupled are hard to reuse in isolation, since they depend on each other. Tight coupling leads to monolithic systems, where you can’t change or remove a class without understanding and changing many other classes. The system becomes a dense mass that’s hard to learn, port, and maintain. Loose coupling increases the probability that a class can be reused by itself and that a system can be learned, ported, modified, and extended more easily. Design patterns use techniques such as abstract coupling and layering to promote loosely coupled systems. Design patterns: Abstract Factory

Question 7

Redesign Cause #7:

Extending Functionality by Subclassing

Answer 7

Design Patterns: Bridge, Chain of Responsibility, Composite, Decorator, Observer, Strategy

Customizing an object by subclassing often isn’t easy. Every new class has a fixed implementation overhead (initialization, finalization, etc.). Defining a subclass also requires an in-depth understanding of the parent class. For example, overriding one operation might require overriding another. An overridden operation might be required to call an inherited operation. And subclassing can lead to an explosion of classes, because you might have to introduce many new subclasses for even a simple extension. Object composition in general and delegation in particular provide flexible alternatives to inheritance for combining behavior. New functionality can be added to an application by composing existing objects in new ways rather than by defining new subclasses of existing classes. On the other hand, heavy use of object composition can make designs harder to understand. Many design patterns produce designs in which you can introduce customized functionality just by defining one subclass and composing its instances with existing ones.

Question 8

Redesign Cause #8:

Inability to Alter Classes Conveniently

Answer 8

Design Patterns: Adapter, Decorator, Visitor

Sometimes you have to modify a class that can’t be modified conveniently. Perhaps you need the source code and don’t have it (as may be the case with a commercial class library). Or maybe any change would require modifying lots of existing subclasses. Design patterns offer ways to modify classes in such circumstances.