Thanks to visit codestin.com
Credit goes to www.scribd.com

0% found this document useful (0 votes)
7 views47 pages

Oop Asai

This document provides an overview of Object-Oriented Programming (OOP) principles and practices, emphasizing the importance of good software design for collaborative and long-term projects. It covers fundamental concepts such as classes, encapsulation, inheritance, abstraction, and polymorphism, along with the Unified Software Development Process. The lecture aims to guide developers in creating modular, maintainable, and reusable code using OOP methodologies.

Uploaded by

dalinda
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views47 pages

Oop Asai

This document provides an overview of Object-Oriented Programming (OOP) principles and practices, emphasizing the importance of good software design for collaborative and long-term projects. It covers fundamental concepts such as classes, encapsulation, inheritance, abstraction, and polymorphism, along with the Unified Software Development Process. The lecture aims to guide developers in creating modular, maintainable, and reusable code using OOP methodologies.

Uploaded by

dalinda
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 47

Object-Oriented

Design and
Implementation
CSC2000 - Marathon

Makoto ASAI
Hiroshima Institute of Technology
( Geant4 / ATLAS )
[email protected]
Contents
1. Introduction
2. Class/Object, Encapsulation
3. Class hierarchies, Inheritance
4. Abstraction, Polymorphism
5. Unified Software Development Process

2
Chapter 1

Introduction
Motivation of this lecture
v If you are writing your code which is
exclusively used by yourself and it will be
used within a temporary short duration, you
can ignore this lecture.
v But you are developing your code with
your colleagues and/or your code will be
used by your collaborators for years, you
should be aware of “good software”.

4
Motivation of this lecture
v Good software is
– Easy to understand the structure
– Easy to find/localize/fix a bug
– Easy to change one part without affecting to
other parts
– Well modularized and reusable
– Easy to maintain and upgrade
– etc. etc.
v Object-Orientation is a paradigm which
helps you to make a good software.

5
Motivation of this lecture
v Use of so-called “Object-Oriented language”
such as C++ or Java does not guarantee the
Object-Oriented Programming.
– Badly written C++/Java code is worse than badly
written Fortran code.
v Well designed, Object-Oriented good
software can be relatively easily
implemented by using Object-Oriented
language.
– Language is a tool to realize Object-Orientation.
6
Motivation of this lecture
v In this lecture I will show you some basic
concepts of Object-Oriented Programming.
v These concepts are more important than the
detailed syntaxes of a language and they
will guide you to learn C++/Java as a
language which stands on Object-
Orientation.

7
Object-Oriented Programming
v Object-Oriented Programming (OOP) is the
programming methodology of choice in the 1990s.
v OOP is the product of 30 years of programming
practice and experience.
– Simula67
– Smalltalk, Lisp, Clu, Actor, Eiffel, Objective C
– and C++, Java
v OOP is a programming style that captures the
behavior of the real world in a way that hides
detailed implementation.

8
Fundamental Ideas
v When successful, OOP allows the problem
solver to think in terms of the problem domain.
– Requirements document
– Object-Oriented Analysis and Design (OOA&D)
– CASE tools
v Three fundamental ideas characterize Object-
Oriented Programming.
– Class/Object, Encapsulation
– Class hierarchies, Inheritance
– Abstraction, Polymorphism

9
Chapter 2

Class/Object and
Encapsulation
Class and Object
v Object-Oriented Programming (OOP) is a
data-centered view of programming in
which data and behavior are strongly linked.
v Data and behavior are conceived of as
classes whose instances are objects.
v OOP also views computation as simulating
behavior. What is simulated are objects
represented by a computational abstraction.

11
Abstract Data Type
v The term abstract data type (ADT) means a
user-defined extension to the native types
available in the language.
v ADT consists of
– a set of values
– a collection of operators and methods that can act
on those values

12
Abstract Data Type
v Class objects are class variables. OOP allows
ADT to be easily created and used.
– For example, integer objects, floating point
number objects, complex number objects, four
momentum objects, etc., all understand addition
and each type has its own code of executing
addition.
FourMomentum a, b, c;
c = a + b;

v An ADT object can be used in exactly same


manner as a variable of native type. This
feature increases the readability of the code.
13
Abstract Data Type
v In OOP, classes are responsible for their
behavior.
class FourMomentum
{
public:
FourMomentum(double px, double py, double pz, double e);
~FourMomentum();
public:
FourMomentum& operator = (const FourMomentum & right);
FourMomentum operator + (const ThreeMomentum & right);
....

14
Encapsulation
v Encapsulation consists of
– the internal implementation details of a specific type
– the externally available operators and functions that
can act on objects of that type
v The implementation details should be
inaccessible to client code that uses the type.
v Make data members private and provide public
Set/Get methods accessible to them.
v Make all Get and other methods which do not
modify any data member “cosnt”.
– “const” methods can be accessed even for constant
ADT objects.
– Strict use of constant ADT objects allows you the
safe programming.
15
Encapsulation
v Changes of the internal implementation should
not affect on how to use that type externally.
class FourMomentum class FourMomentum
{ {
… …
private: private:
double m_Px; double m_P;
double m_Py; double m_Theta;
double m_Pz; double m_Phi;
double m_E; double m_E;
public: public:
void SetP(double p); void SetP(double p);
double GetP() const; double GetP() const;
.... ....

16
G4Step and G4StepPoint
G4St ep
f St epLengt h : G4doubl e
f Tot al Ener gyDepos i t : G4doubl e
1 G4Tr ack
I ni t i al i zeSt ep( ) f pTr ack
Updat eTr ack( )
Get Del t aMoment um( )
Get Del t aTi me( )
Get Pr eSt epPoi nt ( )
Get Pos t St epPoi nt ( )

f pPr eSt epPoi nt f pPos t St epPoi nt

1
1
G4St epPo i nt
f Pos i t i on : G4Thr eeVect or
f Gl obal Ti me : G4doubl e
f Local Ti me : G4doubl e
f Moment umDi r ect i on : G4Thr eeVect or
f Ki net i cEner gy : G4doubl e
G4VTouchabl e
Get Pos i t i on( )
Get Gl obal Ti me( )
Get Local Ti me( )
Get Moment um( ) G4Touchabl eHi s t or y
Get Tot al Ener gy( )
Get Vel oci t y( )
Get Bet a( )

17
Chapter 3

Class hierarchies and


Inheritance
Class hierarchies and Inheritance
v Inheritance is a mean of deriving a new class
from existing classes, called base classes. The
newly derived class uses existing codes of its
base classes.
v Through inheritance, a hierarchy of related
types can be created that share codes and
interfaces.
v A derived class inherits the description of its
base class. Inheritance is a method for
copying with complexity.

19
Class hierarchies and Inheritance
v It is better to avoid protected data members.
– Make data members in a base class private and
provide protected non-virtual access methods to
them.
v Avoid unnecessary deep hierarchies.
– Should a trajectory class and a detector volume
class be derived from a single base class, even
though both of them have a “Draw()” method?
– Follow the naïve concepts everyone can easily
understand.

20
Class hierarchies and Inheritance

21
Class hierarchies and Inheritance
v Avoid unnecessary multiple inheritance.
– In many cases, delegation can solve the problem.

G4VSolid G4LogicalVolume G4VPhysicalVolume

G4Box G4Material G4VisAttributes G4PVPlacement

G4Tubs G4VSensitiveDetector
G4PVParametrized

22
Comments on Collection
v Type-unsafe collection is quite dangerous.
– C++ case, pointer collection of void or very bogus
base class
– Java case, default vector collection of “Object”
base class
v Type-unsafe collection easily reproduces the
terrible difficulties we experienced with the
Fortran common block.

23
Chapter 4

Abstraction and
Polymorphism
Rapid Prototyping
v Abstraction and Polymorphism enable
“Rapid Prototyping”.
– High level class diagrams and scenario
diagrams should be made first before going to
the detailed design/implementation of actual
concrete classes.
– “Proof of concepts” demonstration must be
done with just a couple of concrete classes (or
just one dummy concrete class) for each
abstract base class.

25
Abstraction and Polymorphism
v Abstraction and polymorphism localizes
responsibility for an abstracted behavior.
v They also help the modularity and
portability of the code.
– For example, Geant4 is free from the choice
of histogramming and persistency techniques.
Also, GUI and visualization are completely
isolated from Geant4 kernel via the abstract
interfaces.

26
Polymorphism
v Polymorphism has lots of forms.
– Function and operator overloading
– Function overriding
– Parametric polymorphism

Refer A.Johnson’s lecture for dynamic


class loading featured in Java.

27
Operator Overloading
v In C++, an operator is overloadable . A
function or an operator is called according to
its signature, which is the list of argument
types.
– If the arguments to the addition operator are
integral, then integer addition is used. However,
if one or both arguments are floating point, then
floating point addition is used.
v Operator overloading helps the readability.
double p, q, r;
r = p + q;
FourMomentum a, b, c;
c = a + b;
28
Function Overriding
v Using virtual member functions in an
inheritance hierarchy allows run-time
selection of the appropriate member function.
Such functions can have different
implementations that are invoked by a run-
time determination of the subtype (virtual
method invocation, dynamic binding).
G4VHit* aHit;
for(int i = 0; i < hitCol->entries(); i++)
{
aHit = (*hitCol)[i];
aHit->Draw();
}
29
Function Overloading
v Functions of same name are distinguished
by signatures.
v For the case of function overloading of
“non-pure virtual” virtual functions, all (or
none) of them should be overridden.
– Overriding “overrides” overloading!!!
– Intrinsic source of a bug even though compiler
warns.
– You will see this warning for
G4VParameterisedVolume…

30
class Base {
public:
Base() { ;}
virtual void Show(int i) { cout << “Int” << endl; }
virtual void Show(double x) { cout << “Double” << endl; }
}
Class Derived : public Base {
public:
Derived() { ;}
virtual void Show(int i) { cout << “Int” << endl; }
}
main() {
Base* a = new Derived();
a->Show(1.0); Gives “Int”!!!
}

31
Template
v C++ also has parametric polymorphism,
where type is left unspecified and is later
instantiated.
v STL (Standard Template Library) helps a lot
for easy code development.

32
CSCG4ExEmCalorimeter
class CSCG4ExEmCalorimeterHit : public G4VHit
{
public:
CSCG4ExEmCalorimeterHit();
CSCG4ExEmCalorimeterHit(G4int z);
virtual ~CSCG4ExEmCalorimeterHit();
const CSCG4ExEmCalorimeterHit& operator=(const
CSCG4ExEmCalorimeterHit &right);
virtual void Draw();
virtual void Print();
………
};

typedef G4THitsCollection<CSCG4ExEmCalorimeterHit>
CSCG4ExEmCalorimeterHitsCollection;

33
Chapter 5

Unified Software
Development Process
Software Development Process
v A software development process is the set of
activities needed to transform a user’s
requirements to a software system.
v The Unified Software Development Process
is a software development process which is
characterized by
– Use-case driven
– Architecture centered
– Iterative and incremental
Software
User’s Software
Development
requirements Process System
35
Requirements
v There are many different types of
requirements.
– Functional requirements
– Data requirements
– Performance requirements
– Capacity requirements
– Accuracy requirements
– Test/Robustness requirements
– Maintainability, extensibility, portability, etc.,
“ability” requirements
v Requirements drives use-cases and
architectures.
36
Use-case
v A software system should be used by the
users. Thus the developers of the system must
know the users’ needs.
v The term user refers not only to human users
but also to other system which interacts with
the system being developed.
v An interaction from/to the user is a use-case.
A use-case is a piece of functionality in the
system which captures a requirement.

37
Architecture
v The role of software architecture is similar
in nature to the role of architecture plays in
building construction.
– A plan of building is looked at from various
viewpoints, such as structure, services, heat
conduction, electricity. This allows the builder
to see a complete picture before actual
construction.
– The software architecture must be influenced
by the requirements of both use-case
dependent and use-case independent.
v Architecture is not a framework.

38
Major UML diagrams
v Dynamic diagrams
– Use-case diagram
– Scenario (sequence) diagram
– State diagram
v Static diagrams
– Domain Model diagram
– Class diagram

Refer R.Jones’ lecture for details of UML.

39
Domain Model diagram
v The term “problem domain” refers to the area
which encompasses real-world things and
concepts related to the problem that the system
is being designed to solve.
v Domain modeling is a task of discovering
objects (classes) that represent those things and
concepts.
Cl as s A
Package1
+ Cl as s A

Cl as s B Cl as s C
Package2 Package3
+ Cl as sP + Cl as s X

40
Use-case diagram
v Major use-cases can be found
in the user’s functional UseCase 1

requirements. Act or

v Two courses of use-cases must UseCase 2

be designed simultaneously.
– Basic courses
– Alternative courses

41
State diagram
v State diagram captures the
St ar t
lifecycle of objects.
v This cycle is expressed in
St a t e 1
terms of the different states
St at e 3
that the objects can assume,
St a t e 2
and the events that cause
state changes.
End

42
Scenario (sequence) diagram
v A scenario diagram Obj ec t A :
Cl a s s A
Ob j e ct P :
Cl as sP
Obj e c t X :
Cl a s s X

should be prepared for Met hod1


Me t hod2 Sel f Met hod1

each use-case.
v Methods necessary for a
class are found with
writing this diagram.

43
Scenario diagram
(Geant4/Intercoms)
session or theUImanager : aCommandTree : theCommand : aParameter : aMessenger : destination
kernel G4UImanager G4UIcommandTree G4UIcommand G4UIparameter G4UImessenger Class
1: applyCommand(G4String)

2: findPath(G4String)

3: doIt(G4String)
4: isOmittable()

5: getCurrentAsDefaultFlag( )

6: getCurrentValue(G4UIcommand*)
7: get

8: getDefaultValue( )

9: checkNewValue(G4String)

10: setNewValue(G4UIcommand*)
11: set

If a value of a parameter is given with the


command, 4,5,6,7,8 will be skipped.
If a value is not given, and "isOmittable()" is
true, 5 will be invoked.
If "getCurrentAsDefaultFlag()" is true, 6 will
be invoked, otherwise 8 will be invoked.

44
Class diagram
v Domain Model diagram is upgraded to class
diagram by adding data members, methods,
multiplicities, etc.

Cl as s A
Cl as sPQR dat a1
dat a Pqr dat a2

opna mePqr ( ) opname1( ) 1


opname2( )

1. . *
Cl as s ABC
Cl as s B Cl as s C dat aA1

opnameA1( )

45
Class diagram (Geant4/Intercoms)
destinationSession
strstreambuf
1
G4VUIsession G4VStateDependent
sync()
sessionStart() pauseSession()
pauseSessionStart()
ReceiveG4cout()
ReceiveG4cerr()
0..1 1 G4strstreambuf
G4UImanager Coutbuf
currentSession 1 setCoutDestination()
getUIpointer()
addNewCommand() Cerrbuf
G4UIbatch removeCommand()
applyCommand() G4UIparameter
storeHistory() 1
executeMacroFile() g4cout 1
ostream
checkNewValue()
setSession() isOmittable()
setCoutDestination() g4cerr getDefaultValue()
1 setCerrDestination()
treeTop getCurrentAsDefaultFlag()
getTree() setDefaultValue()
G4UIcommandTree 1 getCurrentValues() 0..n setRange()
1 startSession() G4UIcommand setParameterCandidate()
tree addNewCommand() parameter setCurrentAsDefault()
1 getCurrentValue()
0..n findPath()
1
list() 1 doIt()
removeCommand() command 0..n list()
0..1 setParameter()
guidance setGuidance() 1..n
1 G4UImessenger
setRange() messenger
availableForStates() getCurrentValue()
isAvailable() setNewValue()
checkNewValue()
valueOf()

46
Spiral approach
v Four steps
– Object-Oriented Analysis
OOA
– Object-Oriented Design
– Implementation

OOD
Test
– Test
v Repeat these steps several tation
turns to make a software Implemen
products.
v Don’t hesitate to update
diagrams in earlier cycles.

47

You might also like