OO Principles and Patterns

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



© SAP 2007 /

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



© SAP 2009 /

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



© SAP 2009 /

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.



© SAP 2009 /



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.





© SAP 2009 /

Overview over Object Oriented Programming Languages:

non-OO OOABAP OO

ABAP

http://upload.wikimedia.org/wikipedia/commons/0/04/Historie.svg






http://slidepdf.com/reader/full/oo-principles-and-patterns 7/29© SAP 2009 /



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.



Object Oriented Programming requires

Object Oriented Thinking

© SAP 2009 /

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

!



Object Oriented Programming requires

Object Oriented Thinking

© SAP 2009 /

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.



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



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 /

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



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



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:



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 /

Object1 Object2

Object1 Object2

Object1 Object2

Object1 Object2

Object1 Object2

Interface1

Object1



Component Overview:

Object Relations (applied)

© SAP 2009 /

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



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!



Component Overview:

Special Focus: Curse of Inheritance

© SAP 2009 /

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?



Component Overview:

Special Focus: Curse of Inheritance

© SAP 2009 /

... but most insects and

even some mammalscan fly …

... but then again, do I

have to override for all

objects that can„t fly?



Software Design Patterns

© SAP 2009 /

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

„

“




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




1: The Singleton Pattern – An Example

© SAP 2009 /

Find a pattern to enable

global access from all requesting parties

to one and the same object instance.




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.

„

“




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).

„

“




2: The Factory Pattern – An Example

© SAP 2009 /

This Factory onlyprovides the

right Product

This Factory

provides Orders

and keeps track

of them.



© SAP 2009 /


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.

„

“



Thank you!

OO Principles and Patterns

Documents

Transcript of OO Principles and Patterns