Concepts of Object-Oriented Design

                                       The Central Role of Objects

Object-orientation, makes objects the centerpiece of software design.

The design of earlier systems was centered around processes, which were susceptible to change, and when this change came about, very little of the old system was ‘re-usable’.

The notion of an object is centered around

1. a piece of data and 
2. the operations (or methods) that could be used to modify it.

This makes possible the creation of an abstraction that is very stable since it is not dependent on the changing requirements of the application.
The execution of each process relies heavily on the objects to store the data and provide the necessary operations; with some additional work, the entire system is ‘assembled’ from the objects.

                                                 The Notion of a Class

Classes allow a software designer

• to look at objects as different types of entities.
• Viewing objects this way allows us to use the mechanisms of classification to categorise these types, define hierarchies and 
• engage with the ideas of specialization and generalization of objects.

                                 Abstract Specification of Functionality

In the course of the design process, the software engineer specifies the properties of objects (and by implication the classes) that are needed by a system.

• This specification is abstract in that it does not place any restrictions on how the functionality is achieved.
• This specification, called an interface or an abstract class, is like a contract for the implementer which also facilitates formal verification of the entire system.

                               A Language to Define the System

The Unified Modelling Language (UML) has been chosen by consensus as the standard tool for describing the end products of the design activities. The documents generated in this language can be universally understood and are thus analogous to the ‘blueprints’ used in other engineering disciplines.



                                                    Standard Solutions

The existence of an object structure facilitates the documenting of standard solutions, called design patterns. Standard solutions and corresponding patterns are found at all stages of software development, but

design patterns are perhaps the most common form of reuse of solutions.

                      An Analysis Process to Model a System

Object-orientation provides us with a systematic way to translate a functional specification to a conceptual design. This design describes the system in terms of conceptual classes from which the subsequent steps of the development process generate the implementation classes that constitute the finished software.

1. functional specification -->
2. conceptual design -->
3. conceptual classes -->
4. implementation classes

            The Notions of Extendability and Adaptability

Software has a flexibility that is not typically found in hardware, and this allows us to modify existing entities in small ways to create new ones.

1. Inheritance, which creates a new descendant class that modifies the features of an existing (ancestor) class, and 
2. composition, which uses objects belonging to existing classes as elements to constitute a new class,

are mechanisms that enable such modifications with classes and objects.

As the object-oriented methodology developed, the science of software design progressed too, and several desirable software properties were identified. Not central enough to be called object-oriented concepts, these ideas are nonetheless closely linked to them and are perhaps better understood because of these developments.

                                   Modular Design and Encapsulation

Modularity refers to the idea of putting together a large system by developing a
number of distinct components independently and then integrating these to provide the required functionality.

1. This approach, when used properly, usually makes the individual modules relatively simple and thus the system easier to understand than one that is designed as a monolithic structure. In other words, such a design must be modular. 
2. The system’s functionality must be provided by a number of well-designed, cooperating modules. 
3. Each module must obviously provide certain functionality that is clearly specified by an (module's) interface. The interface also defines how other components may interact or communicate with the module. 
4. We would like that a module clearly specify what it does, but not expose its implementation(internal workings). This separation of concerns gives rise to the notion of encapsulation, which means that the module hides details of its implementation from external agents. 

The abstract data type (ADT), the generalization of primitive data types such as integers and characters, is an example of applying encapsulation.

The programmer specifies the collection of operations on the data type and the data structures that are needed for data storage.

Users of the ADT perform the operations without concerning themselves with the implementation details.

                                             Cohesion and Coupling

Each module provides certain functionality;

cohesion of a module tells us how well the entities within a module work together to provide this functionality.

Cohesion is a measure of how focused the responsibilities of a module are. If the responsibilities of a module are unrelated or varied and use different sets of data, cohesion is reduced.

Highly cohesive modules tend to be more reliable, reusable, and understandable than less cohesive ones.

To increase cohesion, we would like that all the constituents
contribute to some well-defined responsibility of the module. This may be quite a challenging task.

In contrast, the worst approach would be to arbitrarily assign responsibilities to modules, resulting in a module whose constituents have no obvious relationship.

Coupling refers to how dependent modules are on each other. 

The very fact that we split a program into multiple modules introduces some coupling into the system.

Coupling could result because of several factors:

1. a module may refer to variables defined in another module or 
2. a module may call methods of another module and use the return values.

The amount of coupling between modules can vary.

In general, if modules do not depend on each others implementation, i.e., modules depend only on the published interfaces of other modules and not on their internals, we say that the coupling is low.

In such cases, changes in one module will not necessitate changes in other modules as long as the interfaces themselves do not change. 

Low coupling allows us to modify a module without worrying about the ramifications of the changes on the rest of the system. 

By contrast, high coupling means that changes in one module would necessitate changes in other modules, which may have a domino effect and also make it harder to understand the code.

                                      Modifiability and Testability

A software component, unlike its hardware counterpart, can be easily modified in small ways. This modification can be done to change both functionality and design.

1. The ability to change the functionality of a component allows for systems to be more adaptable; the advances in object-orientation have set higher standards for adaptability. 
2. Improving the design through incremental change is accomplished by refactoring, again a concept that owes its origin to the development of the object-oriented approach. 

There is some risk associated with activities of both kinds; and in both cases, the organization of the system in terms of objects and classes has helped develop systematic procedures that mitigate the risk.


Testability of a concept, in general, refers to both: 

falsifiability, i.e., the ease with which we can find counterexamples, 

and

the practical feasibility of reproducing such counterexamples. 

In the context of software systems, it can simply be stated as

the ease with which we can find bugs in a software and the extent to which the structure of the system facilitates the detection of bugs. 

Several concepts in software testing (e.g., the idea of unit testing) owe their prominence to concepts that came out of the development of the object-oriented paradigm.



                  Benefits and Drawbacks of the Paradigm

From a practical standpoint, it is useful to examine how object-oriented methodology has modified the landscape of software development. As with any development, we do have pros and cons.
The advantages listed below are largely consequences of the ideas already presented here.

1. Objects often reflect entities in application systems. This makes it easier for a designer to come up with classes in the design. In a process-oriented design, it is much harder to find such a connection that can simplify the initial design.
2. Object-orientation helps increase productivity through reuse of existing software. Inheritance makes it relatively easy to extend and modify functionality provided by a class. Language designers often supply extensive libraries that users can extend.
3. It is easier to accommodate changes. One of the difficulties with application
   development is changing requirements. With some care taken during design, it is possible to isolate the varying parts of a system into classes.
4. The ability to isolate changes, encapsulate data, and employ modularity reduces the risks involved in system development. 

 The above advantages do not come without a price tag. 

1. Perhaps the number one casualty of the paradigm is efficiency. The object-oriented development process introduces many layers of software, and this certainly increases overheads. 
2. In addition, object creation and destruction is expensive. Modern applications tend to feature a large number of objects that interact with each other in complex ways and at the same time support a visual user interface. This is true whether it is a banking application with numerous account objects or a video game that has often a large number of objects. 
3. Objects tend to have complex associations, which can result in non-locality, leading to poor memory access times. 
4. Programmers and designers schooled in other paradigms, usually in the imperative paradigm, find it difficult to learn and use object-oriented principles. In coming up with classes, inexperienced designers may rely too heavily on the entities in the application system, ending up with systems that are ill-suited for reuse. Programmers also need acclimatisation; some people estimate that it takes as much as a year for a programmer to start feeling comfortable with these concepts. 
5. Some researchers are of the opinion that the programming environments also have not kept up with research in language capabilities. They feel that many of the editors and testing and debugging facilities are still fundamentally geared to the imperative paradigm and do not directly support many of the advances such as design patterns.