Information Technology Reference
In-Depth Information
7.6.5 Encapsulation
Modularity is achieved mainly by the separation of interface from implementation.
This separation is known as encapsulation. With a correctly encapsulated object
the developer does not need to know how the internals of the class work, they need
to merely know the input parameters and the corresponding return type. Each of
these independent modules allows for greater simplicity of the system due to
property that you can remove any module and replace this module with another
that offers the same interfaces. This replacement and interface agreement does not,
however, result in guaranteed simplicity. This is due to the fact that the func-
tionality of the object can be obscured by poor naming conventions and insufficient
documentation. As the internals of the object are unknown it may be difficult to
determine its correct use when documentation is unavailable.
Encapsulation is a method of hiding implementation details from the consumers
of the object. Just because the internal implementation may not be available to
anyone using the object, this does not mean that you can write poor code internally
and not worry since the interface is the only portion that is observed. The effects of
your programming will be noticed and all interfaces rely on proper internal
composition of the class to create satisfactory results.
7.6.6 Refinement
As a project, the progress from concept to delivery can make many details change
or become clearer. This extends to not only the project understanding and
implementation as a whole, but to each component, class, object and subsystem. A
well designed and implemented architecture will permit refinement. Refinement is
a modification to the system resulting from any attitude, desire, or requirement
(functional or non-functional), as well as any intrinsic or extrinsic event that
concerns the project. Although it is impossible to prevent alterations to specifi-
cations after a project has begun, it is the part of good design practice to have the
understanding how these concepts will be handled.
Business models are necessary to convey business ideas from the client to the
design and implementation teams. These models should not be static, but dynamic
in nature to provide for the most fluid and natural process of implementing of
changes. Keeping track of requirements using use case diagrams and a list of
requirements is a simple and inexpensive way of maintaining system functionality
with the client's expectations (Schach
2008
). Since Object-Oriented Design is
iterative, these changes can be implemented in varying stages and they are not
always necessarily required to be rushed to the production floor.
