2. Topics :
● Software Architecture
● What is OOP?
● Class and Object
● Class Design
● Data Abstraction and Encapsulation
● Association, Aggregation and Composition
● Abstract Class and Interface
● Inheritance
● Polymorphism
● Method Overloading, Operator Overloading
and Overriding
● Use Cases
● Class, Package, Sequence Diagram
● Two Tier Architecture and Three Tier
Architecture
● MVC Architecture
● Data Access Layer and Business Access
Layer
● Conclusion
3. Software Architecture
● Partitioning the problem and the system to be built into discrete pieces
● Techniques used to create interfaces between these pieces
● Techniques used to manage overall structure and flow
● Techniques used to interface the system to its environment
5. OOP
● Previously Modular(software design technique that emphasizes separating the functionality of a
program into independent), Top- Down(an overview of the system is formulated, specifying but not
detailing any first-level subsystems), Bottom - Up(piecing together of systems to give rise to more
complex systems), Structured Programming(making extensive and strict use of subroutines, block
structures, for and while loops—in contrast to using jumps such as the goto statement which could
lead to "spaghetti code" which is difficult both to follow and to maintain)
● OOP removed some pitfalls and incorporated best of structured programming from these
● OOPs treat data as a critical element and does not allow it to freely flow around the system
● Follows bottom up approach in program design
6. Class and Object
● Class is the blueprint, or plan, or template, that describes the details of a thing
● In pure OOP terms an object is an instance of a class
● Objects are the basic runtime entities in an object - oriented system
● Class may be thought of as a data-type and an Object as a variable of that
data-type
● A class is simply a representation of a type of object
● Class is composed of three things: a name, attributes, and operations
7. Class Design
There are different techniques to design classes:
● SRP - The Single Responsibility Principle - A class should have one, and only one, reason to
change. As an example, consider a module that compiles and prints a report. Imagine such a
module can be changed for two reasons. First, the content of the report could change. Second, the
format of the report could change. These two things change for very different causes; one
substantive, and one cosmetic. The single responsibility principle says that these two aspects of
the problem are really two separate responsibilities, and should therefore be in separate classes or
modules. It would be a bad design to couple two things that change for different reasons at
different times.
ISP - The Interface Segregation Principle- Make fine grained interfaces that are client specific.
8. Continue..
● OCP - The Open Closed Principle - Should be able to extend any classes' behaviors, without
modifying the classes. Open: It should be possible to add fields to the data structures it contains, or
new elements to the set of functions it performs. Close: said to be closed if it is available for use by
other modules. A class is closed, since it may be compiled, stored in a library, baselined, and used
by client classes. But it is also open, since any new class may use it as parent, adding new features.
When a descendant class is defined, there is no need to change the original or to disturb its clients
9. Continue..
● LSP - The Liskov Substitution Principle- Derived classes must be substitutable for their base
classes. Substitutability is a principle in object-oriented programming that states that, in a computer
program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., an
object of the type T may be substituted with its subtype object of the type S) without altering any of
the desirable properties of that program. A typical example that violates LSP is a Square class that
derives from a Rectangle class, assuming getter and setter methods exist for both width and height.
The Square class always assumes that the width is equal with the height. If a Square object is used
in a context where a Rectangle is expected, unexpected behavior may occur because the
dimensions of a Square cannot (or rather should not) be modified independently.
10. Continue..
● DIP - The Dependency Inversion Principle- Depend on abstractions, not on concretions. The
principle states:
A. High-level modules should not depend on low-level modules. Both should depend on
abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.
The principle inverts the way some people may think about object-oriented design, dictating that
both high- and low-level objects must depend on the same abstraction.
11. Continue ..
Well-defined class must be a meaningful grouping of a set of functions and should support the
reusability, while increasing expandability or maintainability, of the overall system.
In software world the concept of dividing and conquering is always recommended, if you start analyzing a
full system at the start, you will find it harder to manage. So the better approach is to identify the module
of the system first and then dig deep into each module separately to seek out classes.
In order to manage big scale software system, you need to have proper management policies, these are
grouped into few concepts, discussed next...
12. Data Abstraction and Encapsulation
Encapsulation: Wrapping up of data and methods into a single unit(class).
Abstraction: Representing essential features without including the background
details or explanation. Emphasis on the idea, qualities and properties rather than
the particulars (a suppression of detail).
A class is kind of a container or capsule or a cell, which encapsulate a set of
methods, attribute and properties to provide its intended functionalities to other
classes.
13. Association, Aggregation and Composition
In order to modularize/ define the functionality of a one class, that class can uses
functions or properties exposed by another class in many different ways.
According to Object Oriented Programming there are several techniques classes
can use to link with each other. Those techniques are named association,
aggregation, and composition.
● Association is a relationship between two classes. It allows one object
instance to cause another to perform an action on its behalf.
14. Continue..
Example of Composition is Car and it's part e.g. engines, wheels etc. Individual
parts of the car can not function when a car is destroyed. While in the case of
Aggregation, including object can exists without being part of the main object e.g.
a Player which is part of a Team, can exist without a team and can become part of
other teams as well.
Another example of Aggregation is Student in School class, when School closed,
Student still exist and then can join another School or so.
In UML notation, a composition is denoted by a filled diamond, while aggregation is denoted by an empty
diamond, which shows their obvious difference in terms of strength of the relationship.
18. Continue..
● The composition is stronger than Aggregation.
● Association is the more general term that define the relationship between two
classes, whereas the aggregation and composition are relatively special.
● In Short, a relationship between two objects is referred as an association, and
an association is known as composition when one object owns other while an
association is known as aggregation when one object uses another object.
19. Continue..
In UML notation, a composition is denoted by a filled diamond, while aggregation is denoted by an empty
diamond, which shows their obvious difference in terms of strength of the relationship.
20. Abstract Class and Interface
Abstract classes, which declared with the abstract keyword, cannot be instantiated. It can only be used as
a superclass for other classes that extend the abstract class. Abstract class is the concept and
implementation gets completed when it is being extended by a subclass. Abstract class can be used
when implementing framework.
Interface separates the implementation and defines the structure, and this concept is very useful in cases
where you need the implementation to be interchangeable. Apart from that an interface is very useful
when the implementation changes frequently. Interfaces just specify the method declaration (implicitly
public and abstract)
21. Continue..
A class can inherit only from one abstract class (may implement many interfaces) and and must override
all its methods/properties that are declared to be abstract.
● Abstract Classes are a good fit if you want to provide implementation details to your children but
don't want to allow an instance of your class to be directly instantiated.
● If you want to simply define a contract for Objects to follow, then use an Interface.
22. Inheritance
● Inheritance is the process by which objects of one class acquire the
properties of objects of another class. Inheritance provides the idea of
reusability
● Inheritance is closely related with specialization
23. Polymorphism
Polymorphisms is a generic term that means 'many shapes'. More precisely
Polymorphisms means the ability to request that the same operations be
performed by a wide range of different types of things.
In OOP the polymorphisms is achieved by using many different techniques named
method overloading, operator overloading, and method overriding,
24. Method Overloading
Ability to define several methods all with the same name :
public class MyClass
{
public void m1(int num)
{
}
public bool m2(string message)
{
}
}
25. Operator Overloading
Java doesn't support user-defined operator overloading. The only aspect of Java
which comes close to "custom" operator overloading is the handling of + for
strings, which either results in compile-time concatenation of constants or
execution-time concatenation using StringBuilder/StringBuffer. You can't define
your own operators which act in the same way though.
You can look C++, or Groovy(best to look for) for the same.
26. Method Overriding
Method overriding is a language feature that allows a subclass to override a
specific implementation of a method that is already provided by one of its
superclasses.
A subclass can give its own definition of methods but need to have the same
signature as the method in its superclass.
This means that when overriding a method the subclass’ method has to have the
same name and parameter list as the superclass' overridden method.
27. Use Case
In software and systems engineering, a use case is a list of actions or event steps, typically defining the
interactions between a role (known in the Unified Modeling Language as an actor) and a system, to
achieve a goal. The actor can be a human or other external system.
28. Class, Package, Sequence Diagram
● Class diagrams are widely used to describe the types of objects in a system
and their relationships. Class diagrams model class structure and contents.
Class diagrams describe three different perspectives when designing a
system, conceptual, specification, and implementation.
● Package diagrams are used to reflect the organization of packages and their
elements.
● A sequence diagrams model the flow of logic within a system in a visual
manner, it enable both to document and validate your logic, and are used for
both analysis and design purposes.
29. Two Tier Architecture
The two-tier architecture refers to client/server architectures as well. According to
the two-tier architecture the user interfaces runs on the client and the database is
stored on the server. The actual application logic can run on either the client or the
server.
30. Three Tier Architecture
Three-tier is a client-server architecture in which the user interface, functional process logic, data storage and data access
are developed and maintained as independent modules, some time on separate platforms.
32. Data Access Layer
Does basic interactions with the database or any other storage device. These
functionalities are often referred to as CRUD (Create, Retrieve, Update, and
Delete). The data access layer need to be generic, simple, quick and efficient as
much as possible. It should not include complex application/ business logics.
33. Business Logic Layer
The bridge in between the presentation layer and the data access layer with having nothing much, except
taking from one and passing to the other. In some other cases, it is not even been well thought out, they
just take the leftovers from the presentation layer and the data access layer then put them in another
layer which automatically is called the business logic layer. However there are no god said things that
cannot be changed in software world. You can change as per the requirement.
For example, if you want to combine data from couple of table to build a UI (User Interface) control (Web
Control), implement that function in the Business Logic Layer with a business object that uses couple of
data object to support with your complex business requirement.
34. Conclusion
The design or the architecture of a software system is the foundation. It hold the
system together, hence designing a system properly is the key to the success.
When you talk about designing a software system, the correct handling of OOP
concept is very important.
