Page 176 - DCAP308_OBJECT_ORIENTED_ANALYSIS_AND_DESIGN

Object Oriented Analysis and Design

Notes inherent part of one class. When a class is meaningful in the real world, then the operations
on it are usually clear. During implementation, internal classes are introduced.
How do you decide what class owns an operation?

When only one object is involved in the operation, tell the object to perform the operation.
When more than one object is involved, the designer must decide which object plays the
lead role in the operation. For that, ask the following questions:
Is one object acted on while the other object performs the action? It is best to associate
the operation with the target of the operation, rather than the initiator.

Is one object modified by the operation, while other objects are only queried for the
information they contain? The object that is changed is the target.

Looking at the classes and associations that are involved in the operation, which
class is the most centrally-located in this subnetwork of the object model? If the
classes and associations form a star about a single central class, it is the target of the
operation.
If the objects were not software, but the real world objects represented internally,
what real world objects would you push, move, activate or manipulate to initiate
operation?

Notes Assigning an operation within a generalization hierarchy can be difficult. Since
the definitions of the subclasses within the hierarchy are often fluid and can be adjusted
during design as convenient. It is common to move an operation up and down in the
hierarchy during design, as its scope is adjusted.

14.1.3 Refactoring

Refactoring is the process of changing a software system in such a way that it does not alter the
external behavior of the code yet improves its internal structure. It is a disciplined way to clean
up code that minimizes the chances of introducing bugs. In essence, when you refactor, you are
improving the design of the code after it has been written. “Improving the design after it has
been written.” That’s an odd turn of phrase. In our current understanding of software development
we believe that we design and then we code. A good design comes first, and the coding comes
second. Over time the code will be modified, and the integrity of the system, its structure
according to that design, gradually fades. The code slowly sinks from engineering to hacking.
Refactoring is the opposite of this practice. With refactoring you can take a bad design, chaos
even, and rework it into well-designed code. Each step is simple, even simplistic. You move a
field from one class to another, pull some code out of a method to make into its own method,
and push some code up or down a hierarchy. Yet the cumulative effect of these small changes can
radically improve the design. It is the exact reverse of the normal notion of software decay. With
refactoring you find the balance of work changes. You find that design, rather than occurring all
up front, occurs continuously during development. You learn from building the system how to
improve the design. The resulting interaction leads to a program with a design that stays good
as development continues.

Task Analyze the advantages of refactoring.

170 LOVELY PROFESSIONAL UNIVERSITY