Object Oriented Design

Introduction

Programming languages have a tendency to emphasize a few fashion of building code. There are many patterns which have been and are presently used to increase applications, for example: Structured, Functional, Generic, and Object Oriented programming.

The goal of object oriented design are to aid program abstractions through encapsulating implementation details in class instances, offer composability thru class relationships, and aid extensibility thru inheritance and parameterization the usage of C++ templates or generics with C# and Java.

Characteristics of OOD

• Cohesion

Cohesion measures the degree of connectivity among the elements of a single class or object.
In object oriented design, cohesion refers all about how a single class is designed. Cohesion is the Object Oriented principle most closely associated with making sure that a class is designed with a single, well-focused purpose. The more focused a class is, the cohesiveness of that class is more.
 
                                      

• Coupling

Coupling indicates the relationship or interdependency between modules. Coupling refers to the degree of direct knowledge that one element has of another. In other words, how often do changes in class A force related changes in class B.

                                    

Encapsulation
                                      
                                                   Encapsulation

The number one feature of many solution side classes is to control some collection of state. Encapsulation guarantees that member state is constantly under the control of the managing class only. Classes aid encapsulation through imparting access controls.

• Private methods and member data are accessible to each member of the class however inaccessible to clients and derived class.
• Protected methods and member data also are accessible to derived classes, however now not to clients.
• Public methods offer an interface for clients and derived class. We don't make member data public.

The private member data of a class is totally under the control of its method and can't be modified by some other class or function. This guarantees that member data is, for efficiently designed classes, constantly in a valid state. Providing protected member data weakens encapsulation seeing that an incorrectly designed derived class can rework a correctly designed base's member data to an invalid state.

Class Relationships

Classes aid inheritance, composition, aggregation, and the usage of relationship

                                                                        Class Relationships

• Inheritance

When a derived class D inherits from a base B it inherits all the member functions and member data of the base class except, whilst using C++, for constructors, assignment operators, and destructors. The derived class may also add extra methods and member data.

• Composition

composition is a strong ownership relation. A composed part P turns into an crucial a part of the composer C. P is built on the identical time as C and shares its lifetime. C++ helps composition with each user-defined kind in addition to types defined through the language. Java and C# have two forms of types, value types and reference types. Composition of value type is supported through the ones languages, however composition of reference type isn't supported.

• Aggregation

Aggregation is a weak ownership relation. An aggregated element P can be instantiated through its aggregator A, however instantiation isn't assured to arise as that requires code in the aggregator to explicitly create an instance on the heap. The aggregating class A composes a handle to the element P, however the instance of P itself is living on the heap from the time of its instantiation. And so, the life of P is much less than the life of the A. C++ helps aggregation of user-defined types and types defined through the language, putting instances at the native heap. Java and C# aid aggregation for reference types and for value types if they're boxed, which wraps them with an instance of a reference type on the managed heap.

• Using 

Using relationships access thru references to instances of type R that aren't owned through the the using class U. C++, Java, and C# aid the using relationships in a identical way. References to R are passed to an instance of U thru a method argument.

General Principles

• The Open/Closed Principle(OCP)

"Open close principle states a module should be open for extension but closed for modification i.e. Classes should be written so that they can be extended without requiring the classes to be modified."

• Liskov Substitution Principle:

 

"Functions that use pointers or references statically typed to some base class must be able to use objects of classes derived from the base through those pointers or references without any knowledge specialized to the derived classes."

Substitution is a effective mechanism in OOP for constructing flexible software .

• Interface Segregation

When a class has many users it's tempting to add public methods within side the class to aid operations that can be required through only one or two client applications. If the class stays popular its public interface may also grow to be very huge with only some methods utilized by any one client. This causes problems when the class has to change:

Interface Segregation Principle "Clients should not be forced to depend upon interfaces they do not [fully] use." "If we have to change an interface we affect even those clients that do not use the features we change".

• Dependency Inversion:

                                 
                                              Dependency Inversion


It is not unusual for a software design to factor into a policy layer of classes that enforce the program's obligations, a decrease implementation layer that gives solution artifacts like data structures, formatters, analyzers, and the like. The implementation layer will in all likelihood bind to classes in utility libraries developed for the application domain. If bindings are to concrete classes in every layer the design turns into very brittle. A change within side the bottom layer may also motive changes to propagate as much as the very top layers.

Dependency Inversion Principle:"High level components should not depend upon low level components. Instead, both should depend on abstractions.  Abstractions should not depend on details. Details should depend upon the abstractions."

If we use interfaces, the textual content of the upper layer for all invocations right into a lower layer will rely on the interface of the lower layer, now no longer on its concrete classes. If we use object factories, the textual content of the upper layer for all instantiations of lower level concrete classes will rely on the interface of the object factory not on the declarations of the specific object being created. This makes the upper layers compilation independent of whatever that could show up within side the lower layer supplied the interfaces don't change.

Advantages for Object oriented design:

1. Focuses on data rather than the procedures as in Structured Analysis
2. The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system.
3. It allows effective management of software complexity by the virtue of modularity Disadvantages.

Challenges for Object oriented design:

1. Functionality is restricted within objects. This may pose a problem for systems which are intrinsically procedural or computational in nature.
2. It cannot identify which objects would generate an optimal system design.
3. The object-oriented models do not easily show the communications between the objects in the system.
4. All the interfaces between the objects cannot be represented in a single diagram.

Symptoms of bad design:

1. Rigidity: Design is hard to change. Simple change requires lot of code changes.
2. Fragility: Design is easy to break. code break in unexpected area.
3. Immobility: Immobility means unsuccessful to reuse software from different or same design.
4. Viscosity: Make easier changes (hack) than fixing issues in-line with the current design.