Upload
sameer-panigrahi
View
226
Download
0
Embed Size (px)
Citation preview
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 1/29
Software
and
Part 1: OO Principles in Practice
Mathias Beck
S P RCHITECTURE CURRICULUM
Architecture
Design
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 2/29
© SAP 2007 / Page 2
Close Up:
Closure/Feedback
Event (0.5 days)
Negotiation Skills (1 day)
Product Standard Workshop (1 day)
Design Patterns in Practice (0.5 d.)
OO Principles
in Practice (0.5 days)
Advanced Presentation Skills (2 days)
Scalable Client-Server Programming (1 day)
Basic Principles for Architecture at SAP (2 days)
Architecture Definition (1 days)
Design-Led Innovation Workshop (1 day)
Technical Architecture Modeling (TAM) (2 days)
Kick Off: Responsibilities and Tasks of an SAP Architect (1 day)
© SAP 2008 / Page 2
Architecture Curriculum Overview
On-the-Job Activities /Self-LearningCoaching
Instructor-Led Training (ILT): 13,5 days
Contribute to local architecture guideline
Consult and train developers in certain technology & patterns
Participate in design reviews, be responsible for SDDs
Present architecture topic to broader audience
eSOA Architecture lecture e-learnings
Create architecture concept document or SDD
Participate in Architecture Forum
Participate in PIL meetings(reviews) &become expert for 1 product standard
Read PIL pages (process & product standards)
Prepared Customer Interaction
Design-Led Innovation e-learnings
Architecture Modeling (Blueprint)
TAM e-learning
■ Shadowing/monitoring/guidance
■ take coachee into meetings
■ additional appraiser
■ monitor and support document
creation and modeling
■ provide participant with LOB
specific e-learnings and readings
■ include coached in
architecture concept
discussions
■ encourage partici-
pant to contribute
to architecture
networks and wikis
■ Identify together with
participant technology
of interest and drive
ramp-up of knowledge
Ensure participant
takes part in
Architecture &Design Reviews
Introducingproduct portfolio of
development area,
current and target
architecture
Introducing the
organizational
Setup of the LOB
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 3/29
© SAP 2009 / Page 3
1. Intro: Object-Oriented Programming
1.1. Object-Oriented Programming vs. Procedural Programming
1.2. OO Programming requires OO Thinking
1.3. Coherent Object Definition
2. Component Overview
2.1. Object Definition Types
2.2. Object Elements
2.3. Object Relations
2.4. Special Focus Topics3. Software Design Patterns
3.1. The Singleton Pattern
3.2. The Factory Pattern
3.3. The Decorator Pattern
Agenda
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 4/29
© SAP 2009 / Page 4
Object Oriented Programming
vs. Procedural Programming
Procedural Programming was established in the 1970‟s. The necessity for
procedural programming followed the demand for more complex software built on
extremely limited hardware resources.
The major principle of Procedural Programming is the subdivision of an application, a
program, or a routine into granular modules, sub-routines or algorithms.
A software built with procedural programming techniques formed a tree of functionsand, at the very bottom, logical sub steps that could completed one step within the
program flow so that the overall program can proceed. Such sub steps, if well defined
and accessible could be reused in different scenarios.
Procedural Programming separates algorithm/function from memory. Usually, two
memory types, a local memory setup within the function and a global memory lastingduring the entire transaction are being used.
Procedural Programming focuses on modularization and structuring of functionality.
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 5/29
© SAP 2009 / Page 5
Object Oriented Programming
vs. Procedural Programming
Object Oriented Programming originated in the late 1970‟s, but it flourished only at
the end 1980 with the wide spread use of C++ and a progress in hardware resources.
The Object Orientation Paradigm doesn‟t primarily focus on a program or application,
but in building fine granular components (i.e. objects) that interact together in order to
finally accomplish the overall task. The objects are not defined by a task in a chain,
but rather by a responsibility. Thereby the goal is to separate the concerns within the
overall solution. As in real life, each object is a representative of a responsibility. Noother object should carry the same task.
Objects have a state, displayed via a set of attributes and a behavior defined and
(partially) exposed via methods. During the life time they can change their state.
These state changes are the result of outbound requests or responses to state
changes of other objects.
Object-oriented Programming focuses on abstraction and separation of concerns.
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 6/29
Object Oriented Programming
vs. Procedural Programming
© SAP 2009 / Page 6
Overview over Object Oriented Programming Languages:
non-OO OOABAP OO
ABAP
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 7/29© SAP 2009 / Page 7
Object Oriented Programming
vs. Procedural Programming
Software Objects primarily represent an abstraction of real life objects. This, among
others, was one of the major motivations of Object Orientation – the resemblance
with the reality. However, in modern OO-based software solutions, the vast number
of objects counters the effect again.
Object Orientation comes with a set of constructs supporting well-defined objects and
standardized principles of collaboration among them.
As in real life, the responsibilities and the behavior of the objects will evolve in time or
differ once a more specialized view on such an object is in need. OO supports such
evolution during the software lifecycle with various constructs and patterns.
Finally, with the concept of interfaces, the foundation for service oriented software
design was laid, as the definition of the required behavior is separated from theactual implementer of the behavior.
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 8/29
Object Oriented Programming requires
Object Oriented Thinking
© SAP 2009 / Page 8
Like in a project organization, the goal is to identify people“ that take care of certain
tasks in the entire process. These people“ are differentiated by roles and
responsibilities and certain rules of collaboration.
As in an ideal steady team, every team member is an expert in his/her field. Nobodydoes overlapping work. However, some team member do similar or even equal
tasks. These should always be done in the same quality. The requester should be
able to request the task in the same way, and get an equal (or comparable) result.
In order to ensure a good overall result, the team members need to talk with each
other and update (on request) about their status.
Object Oriented Programming requires a high level of abstraction skills
!
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 9/29
Object Oriented Programming requires
Object Oriented Thinking
© SAP 2009 / Page 9
Although the advantages and the potential of object orientation are well perceived by
the developer community, object orientation comes with certain boundaries:
The demand on the software developer with respect to abstractive thinking is very high
The development process is often carried out in an “indirect” manner, i.e. not the solution itself
gets built, but little components that, at a later stage will then be assembled. Thus,
accountable development results come late.
Since OO strongly emphasizes on reuse and model driven development, over-engineeringeffects can easily occur.
To grant a better overview and to support the software development process, the
standardized notation of software blue-prints/software models is indispensible.
Over the years the Unified Modeling Language methodology has established itself as the
world-wide standard to model software solutions, especially comprising the object oriented
principles. SAPs Technical Architecture Modeling methodology includes UML notation,
especially for the area of displaying the inertias of the software systems.
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 10/29© SAP 2009 / Page 10
Coherent Object Definition
The most crucial part of Object Oriented development is the object definition.
Objects resembling real life objects are usually the first choice (and in most cases a
good choice to support the comprehensibility of the solution). Such objects mainly
represent Entities.
has
CarOwner Driver
Door Wheel Engine
Car
Seat
has
has
has
owns operates
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 11/29
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 12/29
Coherent Object Definition
Driving object modeling and definition further, even sub components of real life
objects or sub responsibilities of a process result in additional objects.
Depending on their state and special features, objects can behave differently. To
determine absolut common behavior vs. object specific flavors“ is the decision
criteria for selecting the corresponding modelling pattern.
© SAP 2009 / Page 12
VehicleOwner
Wheel
Engine
Seat
Ride
is a is a
Door
Handle
Frame
Window
Key
KeySystem
KeyLock
hashas
Driver
uses
OpenDoor
operates
accesses
uses
Car Truck
Vehicle
owns operates
has
has
has
has
uses
has
has
has
has
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 13/29© SAP 2009 / Page 13
Component Overview:
Object Definition Types
Class
• A class is the basic form of representing an object
• Classes have a static part that is directly active and accessible at program load
• Classes have an instance part that is only active as soon as an instance of the class is created.Each instance has it„s own memory space. Thus, during the run time each instance is in it„sindividual state and can differ in behavior.
• The construct of the Class is defined in the class definition, the algorithms and functions to makethe class fulfill its responsibility are defined in the class implementation.
Abstract Class• An abstract Class is a class that is purposely only partially implemented. A certain part of the classdefinition is not equipped with an implementation but declared as abstract.
• No instance of an abstract class can be created during run time – a specialization (i.e. a classinheriting from the abstract class) must be programmed and only this class can be instanciated
• Abstract Classes are used to define a commonality in behavior. This behavior is then alreadyimplemented and can be reused by the inheriting classes.
Interface
• An interface is a description of the public“ behavior of a class. However, interfaces have noimplementation and can never be instantiated.
• For the definition to come to life it requires a class implementing such interface.
• The purpose of interfaces is to decouple classes from their constructive structure and focus on anagreed set of methods that can be performed on the implementing object. The implementingobject„s identity, however, is irrelevant for the accessing object.
a_class
an_abstract_class
an_interface
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 14/29© SAP 2009 / Page 14
Component Overview:
Object Elements
Scope
Elements can either existstatically or per instance.
Static elements exist only
once, but right away. The
access is not depending on
an instance.
Instance elements exist per
Instance and differ in state
and behavior depending onthe overall state of the
instance
VisibilityElements can be public,
protected or private.
Public elements areaccessible from within and
outside the class
Protected elements are only
accessible within the class
and inheriting subclasses
Private elements are only
accessible within the class
StateAttributes define the state of
the object.They can be of
contrete type or references to
other objects.
Events propagate a state
change within and beyond the
object boundaries
BehaviorThe behavior is defined by
Methods. They have a well
defined signature and can
be called within or (dependingon the Visibility) outside the
object boundary
Methods acting as an Event
Handler cannot be called
directly, but acts upon the
occurence of the respective
event.
A class composes basically of State and Behavior elements
which vary in Scope and Visibility:
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 15/29
Component Overview:
Object Relations
• Association illustrates that Object1 needs to access Object2 (in certainconstellations) in order to completely fulfill its responsibilities.Association
• Aggregation illustrates that part of Object1„s state is defined by referencing toObject2. Thus, Object1 cannot exist without Object2.
Aggregation
• Composition illustrates an aggregation in which Object2 alone cannot exist butdepends on the existence of Object1. Object 2 is usually a class within Object1.Composition
• Inheritance illustrates that Object1 is taking over the definition andimplementation of Object2. Object1 can add additionally elements, and/or, ifpermitted by Object2, alter the behavior of methods or alter the object state.Inheritance
• Realization illustrates that Object1 provides an implementation for all themethods defined in Interface1.
Realization
• Instanciation illustrates that Object1 takes responsibility of creating instancesof Object2.
Instanciation
© SAP 2009 / Page 15
Object1 Object2
Object1 Object2
Object1 Object2
Object1 Object2
Object1 Object2
Interface1
Object1
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 16/29
Component Overview:
Object Relations (applied)
© SAP 2009 / Page 16
VehicleOwner
Wheel
Engine
Seat
Ride
<<control>>
Door
Handle1
Frame1
Window
0..*
Key KeyLock
Driver
uses
OpenDoor
<<control>>
operates
accesses
uses
Car Truck
Vehicle
1..*
*
1
1..*
uses
operates
KeySystem
1..* 1
0..1
Person
1..*
*
1
1..*
1
1
0..*
0..1
1..* 1
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 17/29© SAP 2009 / Page 17
Component Overview:
Special Focus: Interface vs. Abstract Class
Interface & abstract class are constructs with a lot of similarities:
both contain a definition without actual implementation
both cannot exist at run time, but can be used as a unified access to classes
both force the implementer of certain behavior to oblige to certain agreed
methods and signatures.
In order to choose the right construct, is imperative to understand the
differences:
Since interfaces do not come with any implementation no predefined
behavior can be forced on the implementer. However, also no common
behavior can be placed commonly at the interface.
A class can implement several interfaces, but (in most OO languages) only
inherit from one class
Aside from the set of methods defined by the interface, the class can take all
possible shapes and change during it‟s life cycle.
An interface defines a common set of methods and their signatures.
An abstract classes pre-defines behavior. This can easily be a limitation.
myClass
Interface1
Interface2
Interface3
The more similar the objects the harder to make the right choice!
abstractClass_1
myClass
abstractClass_2
Standard Rule: Program against interfaces, not implementations!
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 18/29
Component Overview:
Special Focus: Curse of Inheritance
© SAP 2009 / Page 18
Animal
Bird
Chicken DuckEagle Goose Peacock
Mammal
Cat Bat
Insect
Ant Catepillar Bee
Where to place that behavior?
How to avoid duplicate definition?
How to avoid duplicate implementation?
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 19/29
Component Overview:
Special Focus: Curse of Inheritance
© SAP 2009 / Page 19
... but most insects and
even some mammalscan fly …
... but then again, do I
have to override for all
objects that can„t fly?
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 20/29
Software Design Patterns
© SAP 2009 / Page 20
Each pattern describes a problem
which occurs over and over again in
our environment, and then describesthe core of the solution to that
problem, in such a way that you can
use this solution a million times over,
without ever doing it the same way
twice.
Christopher Alexander
„
“
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 21/29© SAP 2009 / Page 21
Software Design Patterns
Object Orientated Programming comes with
great potentials, but as seen earlier, also withrisks.
Over the years, a selection of patterns and
idioms have evolved reducing the risk of
driving the software in deadend scenarios or
increasing complexities.
The main goals are to:
Avoid classical pits and traps
Maximize reusability
Minimize the need for modification
Unify the various implementation
Increase understanding Decrease development risk
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 22/29
Software Design Patterns
1: The Singleton Pattern – An Example
© SAP 2009 / Page 22
Find a pattern to enable
global access from all requesting parties
to one and the same object instance.
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 23/29© SAP 2009 / Page 23
Software Design Patterns
1: The Singleton Pattern
The singleton pattern covers 2 problems of software
development with classes.
Be best prepared for future changes
Keep track of my class instances
The primary advantage of Singleton is that the class
definition can be done with instance elements. So, if there isa later need for polymorphism, the methods can be re-
defined.
Also, the singleton can then be transferred into a multi
instance construct with minimal impact on the code base. In
such a case, an additional criteria might be needed at the
factory method (get_instance( ) ).
A Singleton is a class thatensures that exactly oneinstance of it can exist duringrun time. This one instancecan be globally accessed.
„
“
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 24/29© SAP 2009 / Page 24
Software Design Patterns
2: The Factory Pattern
The factory pattern is primarily fulfilling 3 tasks:
Conceal the decision which concrete class will be
instantiated based on the requested criteria.
Have a centrally accessible component in order to retrieve
objects of a specific type
Keep track of my class instances
Factories are usually static objects whose main public
method is the factory method itself. By separating instance
creator and implementing classes, changes/additions in the
inheritance tree can be carried out without impacting
existing implementations.
A Factory is a class that takesresponsibility for the instantiation(and additonally the instancemanagement) of objects fulfillinga common definition (abstractclass / interface).
„
“
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 25/29
Software Design Patterns
2: The Factory Pattern – An Example
© SAP 2009 / Page 25
This Factory onlyprovides the
right Product
This Factory
provides Orders
and keeps track
of them.
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 26/29
© SAP 2009 / Page 26
Software Design Patterns
3: The Decorator Pattern
Decorator classes solve the problem that multiple
classes within an inheritance tree share a common
behavior which does contradict the original hierarchy.
Instead of defining and redefining from one level to
the next, and in order to avoid duplicate (i.e.
individual) method definitions and implementations, a
decorator class wraps itself around the respective
objects and simulates them completely except for the
additional “decoration”.
Since Decorators are as well part of the inheritance
tree, they can be wrapped by other decorators.
A Decorator is a class that canadd a certain behavior tomultiple classes within aninheritance without followingthe existing hierarchy.
„
“
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 27/29
Software Design Patterns
3: The Decorator Pattern – An Example
© SAP 2009 / Page 27
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 28/29
Q&A
© SAP 2007 / Page 28
8/13/2019 OO Principles and Patterns
http://slidepdf.com/reader/full/oo-principles-and-patterns 29/29
Thank you!