Analisis dan Desain Perangkat Lunak : Data Abstrak, Data Encapsulation dan Information Hiding
Data Encapsulation
Example
Design an operating system for a large mainframe computer. Batch jobs submitted to the computer will be classified as high priority, medium priority, or low priority. There must be three queues for incoming batch jobs, one for each job type. When a job is submitted by a user, the job is added to the appropriate queue, and when the operating system decides that a job is ready to be run, it is removed from its queue and memory is allocated to it
Design 1
Low cohesion — operations on job queues are spread all over the product
Data Encapsulation — Design 1
Data Encapsulation — Design 2
m_encapsulation has informational cohesion
m_encapsulation is an implementation of data encapsulation. A data structure (job_queue) together with operations performed on that data structure
Advantages
- Development
- Maintenance
Data Encapsulation and Development
Data encapsulation is an example of abstraction. Job queue example:
- Data structure
- job_queue
- Three new functions
- initialize_job_queue
- add_job_to_queue
- delete_job_from_queue
Abstraction
Conceptualize problem at a higher level
- Job queues and operations on job queues
Not a lower level
- Records or arrays
Stepwise Refinement
- Design the product in terms of higher level concepts
- It is irrelevant how job queues are implemented
- Then design the lower level components
- Totally ignore what use will be made of them
- In the 1st step, assume the existence of the lower level
- Our concern is the behavior of the data structure
- job_queue
- In the 2nd step, ignore the existence of the higher level
- Our concern is the implementation of that behavior
- In a larger product, there will be many levels of abstraction
Data Encapsulation and Maintenance
- Identify the aspects of the product that are likely to change
- Design the product so as to minimize the effects of change
- Data structures are unlikely to change
- Implementation details may change
- Data encapsulation provides a way to cope with change
Implementation of JobQueueClass
Implementation of queueHandler
What happens if the queue is now implemented as a two-way linked list of JobRecordClass? A module that uses JobRecordClass need not be changed at all, merely recompiled.
Only implementation details of JobQueueClass have changed
Abstract Data Types
The problem with both implementations. There is only one queue, not three
We need:
Data type + operations performed on instantiations of that data type
Abstract Data Type Example
Information Hiding
Data abstraction
- The designer thinks at the level of an ADT
Procedural abstraction
- Define a procedure — extend the language
Both are instances of a more general design concept, information hiding
- Design the modules in a way that items likely to change are hidden
- Future change is localized
- Changes cannot affect other modules
C++ abstract data type implementation with information hiding
 |
| Effect of information hiding via private attributes |
Objects
First refinement
- The product is designed in terms of abstract data types
- Variables (“objects”) are instantiations of abstract data types
Second refinement
- Class: an abstract data type that supports inheritance
- Objects are instantiations of classes
Inheritance
Define HumanBeingClass to be a class
- An instance of HumanBeingClass has attributes, such as
- age, height, gender
- Assign values to the attributes when describing an object
Define ParentClass to be a subclass of HumanBeingClass
- An instance of ParentClass has all the attributes of an instance of HumanBeingClass, plus attributes of his/her own
- nameOfOldestChild, numberOfChildren
- An instance of ParentClass inherits all attributes of HumanBeingClass
The property of inheritance is an essential feature of all object-oriented languages. Such as Smalltalk, C++, Ada 95, Java. But not of classical languages. Such as C, COBOL or FORTRAN
UML notation
- Inheritance is represented by a large open triangle
Java Implementation
Aggregation
UML notation for aggregation — open diamond
Association
UML notation for association — line. Optional navigation triangle
Equivalence of Data and Action
Classical paradigm
- record_1.field_2
Object-oriented paradigm
- thisObject.attributeB
- thisObject.methodC ()
Inheritance, Polymorphism and Dynamic Binding
Classical paradigm
- We must explicitly invoke the appropriate version
Classical code to open a file
- The correct method is explicitly selected
Object-oriented code to open a file
- The correct method is invoked at run-time (dynamically)
Method open can be applied to objects of different classes “Polymorphic”
Method checkOrder (b : Base) can be applied to objects of any subclass of Base
Polymorphism and dynamic binding. Can have a negative impact on maintenance. The code is hard to understand if there are multiple possibilities for a specific method
Polymorphism and dynamic binding. A strength and a weakness of the object-oriented paradigm
The Object-Oriented Paradigm
Reasons for the success of the object-oriented paradigm
- The object-oriented paradigm gives overall equal attention to data and operations
- At any one time, data or operations may be favored
- A well-designed object (high cohesion, low coupling) models all the aspects of one physical entity
- Implementation details are hidden
The reason why the structured paradigm worked well at first
- The alternative was no paradigm at all
How do we know that the object-oriented paradigm is the best current alternative?
- We don’t
- However, most reports are favorable
- Experimental data (e.g., IBM [1994])
- Survey of programmers (e.g., Johnson [2000])
Weaknesses of the Object-Oriented Paradigm
- Development effort and size can be large
- One’s first object-oriented project can be larger than expected
- Even taking the learning curve into account
- Especially if there is a GUI
- However, some classes can frequently be reused in the next project
- Especially if there is a GUI
- Inheritance can cause problems
- The fragile base class problem
- To reduce the ripple effect, all classes need to be carefully designed up front
- Unless explicitly prevented, a subclass inherits all its parent’s attributes
- Objects lower in the tree can become large
- “Use inheritance where appropriate”
- Exclude unneeded inherited attributes
- As already explained, the use of polymorphism and dynamic binding can lead to problems
- It is easy to write bad code in any language
- It is especially easy to write bad object-oriented code
- Some day, the object-oriented paradigm will undoubtedly be replaced by something better
- Aspect-oriented programming is one possibility
- But there are many other possibilities
Key Definitions
Sumber
Object-Oriented and Classical Software Engineering, Eighth Edition, WCB/McGraw-Hill, 2011 by Stephen R. Schach
Slide ADPL : Modules and Objects
Posting Komentar