7. Review on Object Oriented
Programming
• Encapsulation
• Inheritance and Polymorphism
• Abstraction
• Interface Vs. Abstract Class
8. Encapsulation
• Keeping things private or masked inside
the domain of an object, package,
namespace, class, or interface and
allowing only expected access to pieces of
functionality.
• Controlling access to fields, properties and
methods
9. Inheritance
• Instead of maintaining the same logic in
two objects, they can share and even
override or change this functionality by
using a base or parent class.
• The parent should only contain
functionality common to all its children.
10. Abstraction
• Abstraction is the ability to abstract into a
base class some common functionality or
design that is common to several
implementations or instanced classes.
• It is the possibility to represent the needed
information in program without presenting
the details.
• Abstraction and inheritance are both
aspects of polymorphism.
11. Interface Vs. Abstract class
Interface Abstract class
• Not a class • "What" functionality a particular
• It is simply a protocol in OO kind of object should have, and
languages that exists between also "How" a particular
classes and objects to provide an functionality is implemented.
agreed upon linkage. • Defines abstraction between
• "What" functionality a classes, and also to define
particular kind of object should concrete definition of functions
have, and, it doesn't care about which are common across the
exactly "How” this functionality concrete implementation classes.
should be implemented. • Increases re-usability and code
manageability and allows to build
better systems.
12. A good OOD must be:
• Re-USABLE
• Changed with minimal effort
• Extended without changing existing code.
13. Solid Principles
• S = Single Responsibility Principle
• O = Opened Closed Principle
• L= Liscov Substitution Principle
• I = Interface Segregation Principle
• D = Dependency Inversion Principle
15. Single Responsibility
Principle
• There should never be more than one
reason for a class to change
• A class should have one and only one
responsibility.
21. LisKov Substitution
Principle
• Functions that use pointers or references
to base classes must be able to use
objects of derived classes without knowing
it
• .“Subtypes must be substitutable for their
base types.”
23. Interface Segregation
Principle
• "Clients should not be forced to depend
upon interfaces that they do not use.“
• Fat Interfaces are not recommended
25. Dependency Inversion
Principle
• "High level modules should not depend
upon low level modules. Rather, both
should depend upon abstractions."
• Pluggable nature of parts
27. Other OO Principles
• Encapsulate what varies
• Favor Composition over inheritance
• Program to Interfaces, not
implementations
• Strive for loosely coupled designs
between objects that interact
Interface iVehiclee.g. city building contractsAbstract class Toyota Camry Corolla
If a class has more then one responsibility, then the responsibilities become coupled.Changes to one responsibility may impair or inhibit the class’ ability to meet the others.This kind of coupling leads to fragile designs that break in unexpected ways when changed.
When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad”design. The program becomes fragile, rigid, unpredictable and unreusable.The primary mechanisms behind the Open-Closed principle are abstraction and polymorphism.
Fat interfaces are less reusable and increase coupling between classes