C++ Design Patterns Seminar

C++ Design Patterns
Advanced C++ Programming Seminar, Summer Term 2009

Georg Altmann
University Erlangen-Nuremberg System Simulation
June 4th 2009
Georg Altmann (LSS Erlangen) C++ Design Patterns 6/4/2009 1 / 48
Outline
Introduction
The Singleton Pattern
The Monostate Pattern
The Bridge Pattern
What is a Design Pattern?
Design Patterns are descriptions of communicating objects and classes that
are customized to solve a general design problem in a particular context.
a
a
Erich Gamma [et al.], Design Patterns, Addison Wesley, 1994
Why use Design Patterns?
Design Patterns are proven solutions to re-occurring software design
problems
Dont re-invent the wheel!
Outline
Introduction
The Bridge Pattern
The Problem
Ensure a class has only one instance with global access
Motivation
For some classes it is important, that only one instance exists:
program conguration classes
classes representing unique system devices
logging classes
etc.
singleton.h
class Singleton {
public:
// Unique global point of access
static Singleton* getInstance();
private:
static Singleton* instance_;
};
singleton.cpp
Singleton* Singleton::instance_ = 0;
Singleton* Singleton::getInstance() {
if(instance_ == 0)
instance_ = new Singleton();
return instance_;
}
Singleton?
class Singleton {
public:
private:
};
No!
Default constructor public:
It is possible to create multiple instances!
Singleton?
class Singleton {
public:
private:
};
No!
Default constructor public:
It is possible to create multiple instances!
Singleton?
class Singleton {
public:
private:
Singleton();
};
No!
Copy constructor and copy assignment operator public:
It is still possible to create multiple instances by copying!
Singleton myCopy(*Singleton::getInstance());
Singleton?
class Singleton {
public:
private:
Singleton();
};
No!
Copy constructor and copy assignment operator public:
It is still possible to create multiple instances by copying!
Singleton myCopy(*Singleton::getInstance());
Singleton!
class Singleton {
public:
private:
Singleton();
Singleton(const Singleton&); // non-
Singleton& operator=(const Singleton&); // copyable
};
Singleton gone. . .
Singleton *s = Singleton::getInstance();
delete s; // Oops!
Destructor is public:
Clients can destroy the Singleton.
Singleton gone. . .
Singleton *s = Singleton::getInstance();
delete s; // Oops!
Destructor is public:
Clients can destroy the Singleton.
A simple Singleton
class Singleton {
public:
static Singleton& getInstance(); // return reference
private:
Singleton();
Singleton& operator=(const Singleton&); // copyable
~Singleton(); // indestructible
};
Resource leak: Singleton() is never called!
Resources held by the Singleton are never freed
May be acceptable for dynamically allocated memory
OS-wide mutexes, IPC, CORBA/COM problematic!
How can the resource leak be avoided?
Use a local static variable instead of a static data member
a
a
Meyers, More Eective C++, Addison-Wesley, 1996
a
a
a
a
The Meyers Singleton
class Singleton {
public:
static Singleton& getInstance();
private:
Singleton();
Singleton& Singleton(const Singleton&); // copyable
~Singleton();
// no static instance pointer!
};
Singleton& Singleton::getInstance() {
static Singleton instance;
return instance;
}
Meyers Singleton Consequences
instance initialized when getInstance() is called the rst time
instance ist destroyed automatically (std::atexit())
Order of destruction of static objects is arbitrary!
Problematic if static objects are interdependent
Dead reference problem
return instance;
}
return instance;
}
return instance;
}
Detecting Dead Reference Access
// singleton.h
class Singleton {
// ... as before
private:
static bool destroyed_;
};
// singleton.cpp
Singleton::destroyed_ = false;
Singleton::~Singleton() {
destroyed_ = true;
}
Detecting Dead Reference Access
// singleton.cpp
if(destroyed_)
throw std::runtime_error(
"Singleton: Dead Reference Access");
else
return instance;
}
The Phoenix Singleton
Phoenix from the ashes
Dead reference access now correctly throws an exception
Situation unsatisfactory if dependency cannot be avoided
Idea: Re-create the destroyed Singleton after its destruction:
Phoenix Singleton
a
a
Alexandrescu, Modern C++ Design, Addison-Wesley, 2001
// singleton.cpp
Singleton* Singleton::pkill_ = 0;
if(destroyed_) {
new(&instance) Singleton; // placement new
pkill_ = &instance; // init kill pointer
std::atexit(kill); // register destruction
destroyed_ = false;
}
return instance;
}
void Singleton::kill() {
pkill_->~Singleton()
}
Phoenix Disadvantages
If the Singleton keeps state, it is lost after destruction
Use of atexit is a low level hack
Longevity Patterns
More advanced patterns for controlling the lifetime of objects can be
found in
Phoenix Disadvantages
If the Singleton keeps state, it is lost after destruction
Use of atexit is a low level hack
Longevity Patterns
More advanced patterns for controlling the lifetime of objects can be
found in
Outline
Introduction
The Bridge Pattern
Singleton
Ensures only one class object exists
Data is encapsulated in the class object
Monostate
Data members static and private - class level encapsulation
Class objects are stateless - any number of instances may exist
cong.h
class Config {
public:
Config();
Color getFavoriteColor() const;
/* ... */
private:
static bool initialized_;
static Color favoriteColor_;
/* ... */
};
cong.cpp
bool Config::initialized_ = false;
Color Config::favoriteColor_;
Config::Config() {
if(!initialized_) {
/* ... initialize from file/registry/etc. ... */
initialized_ = true;
}
}
Color Config::getFavoriteColor() const {
return favoriteColor_;
};
Monostate vs. Singleton
Cong as Singleton
Config &conf = Config::getInstance(); // get Config object
Color col = conf.getFavoriteColor();
Cong as Monostate
Config conf = Config(); // create new Config object
Cong as Singleton
Config &conf = Config::getInstance(); // get Config object
Cong as Monostate
Config conf = Config(); // create new Config object
Singleton
Meyers Singleton oers initialization and destruction
Ensuring single instance is dicult and error-prone
Single instance explicit in interface
Monostate
Does not handle destruction
leaks dynamic resources
Objects are stateless
no copy-construction problem
Data sharing invisible in interface (implementation detail)
Singleton
Meyers Singleton oers initialization and destruction
Ensuring single instance is dicult and error-prone
Single instance explicit in interface
Monostate
Does not handle destruction
leaks dynamic resources
Objects are stateless
no copy-construction problem
Data sharing invisible in interface (implementation detail)
Outline
Introduction
The Bridge Pattern - Pimpl
The Bridge Pattern
The Problem
C++ mixes class interface and implementation (header les)
Leads to strong compile time dependencies
Long compile times slow down development process
The Solution
Manually decouple interface and implementation:
Pimpl idiom (pointer to implementation)
Abstract Interface classes
The Bridge Pattern
The Problem
The Solution
The Bridge Pattern
The Problem
The Solution
The Bridge Pattern
The Problem
The Solution
The Bridge Pattern
The Problem
The Solution
person.h
class Person {
public:
Person(const std::string& name);
std::string name() const;
private:
std::string name_; //implementation detail
};
person.cpp
Person::Person(const std::string& name)
: name_(name) {}
std::string Person::name() const {
return name_;
}
person.h
class Person {
public:
private:
std::string name_; //implementation detail
};
person.cpp
: name_(name) {}
return name_;
}
Pimpl version person.h
class PersonImpl; // forward declaration of impl
class Person {
public:
private:
std::tr1::shared_ptr<PersonImpl> p_; //pointer to impl
};
Pimpl version person.cpp
: p_(new PersonImpl(name)) // create impl instance
{}
return p_->name(); // delegate call to impl
}
personimpl.h
class PersonImpl {
public:
PersonImpl(const std::string& name);
private:
std::string name_;
};
personimpl.cpp
PersonImpl::PersonImpl(const std::string& name)
: name_(name) {}
std::string PersonImpl::name() const {
return name_;
}
personimpl.h
class PersonImpl {
public:
PersonImpl(const std::string& name);
private:
std::string name_;
};
personimpl.cpp
PersonImpl::PersonImpl(const std::string& name)
: name_(name) {}
std::string PersonImpl::name() const {
return name_;
}
Result
person.h has no dependency on personimpl.h (forward declaration)
No need to recompile client code if personimpl.h changes
Add Write Access
void Person::setName(const std::string& name) {
p_->setName(name);
}
void PersonImpl::setName(const std::string& name) {
name_ = name;
}
Person p("Peter");
Person pc(p);
cout << "p.name(): " << p.name() << endl;
cout << "pc.name(): " << pc.name() << endl;
cout << "pc.setName(\"Hans\");" << endl;
pc.setName("Hans");
Result
p.name(): Peter
pc.name(): Peter
pc.setName("Hans");
p.name(): Hans // Oops!
pc.name(): Hans
Result
p.name(): Peter
pc.name(): Peter
pc.setName("Hans");
p.name(): Hans // Oops!
pc.name(): Hans
Person p("Peter");
Person pc(p); // (1)
What happened?
Compiler-generated Copy-Constructor is called (1)
p and pc share the same PersonImpl object!
Copying behavior
Implement Copy-Constructor and copy assignment operator and make sure
the PersonImpl object is (deep-)copied
or
implement copy-on-write. . .
Copy-on-Write
void Person::makeUnique() {
if(!p_.unique()) {
std::tr1::shared_ptr<PersonImpl> np(
new PersonImpl(*p_));
p_ = np;
}
}
void Person::setName(const std::string& name) {
makeUnique();
p_->setName(name);
}
cout << "pc.setName(\"Hans\");" << endl;
pc.setName("Hans");
Copy-on-Write Result
p.name(): Peter
pc.name(): Peter
pc.setName("Hans");
p.name(): Peter
pc.name(): Hans
Drawbacks of Pimpl
Performance penalty of impl allocation and memory fragmentation
Performance penalty due to pointer dereferencing
Copying behavior has to be taken care of
Source code bloat
Sometimes a back-pointer to the interface object is needed (e.g.
for virtual function calls)
Drawbacks of Pimpl
Source code bloat
Drawbacks of Pimpl
Source code bloat
Drawbacks of Pimpl
Source code bloat
Drawbacks of Pimpl
Source code bloat
Outline
Introduction
The Bridge Pattern - Abstract Interface Classes
Abstract Interface Class
// person.h
class Person {
public:
virtual ~Person();
virtual std::string name() const = 0;
// factory function - "virtual constructor"
static std::tr1::shared_ptr<Person>
create(const std::string& name);
};
Concrete Class
// realperson.h
class RealPerson : public Person {
public:
RealPerson(const std::string& name)
:name_(name)
{}
private:
std::string name_;
};
person.cpp
#include "person.h"
#include "realperson.h"
std::tr1::shared_ptr<Person>
Person::create(const std::string& name) {
return std::tr1::shared_ptr<Person>(
new RealPerson(name));
}
create() may choose between dierent implementations of the Interface
Class at run-time.
Result
Clients only depend on person.h
Link between Person and RealPerson hidden in person.cpp
realperson.h can be changed without needing to recompile client code
Multiple concrete classes with dierent implementations
No interface to implemenation glue code
Cost of Interface Classes
All function calls are virtual (performance)
Additional virtual function table pointer per object (memory)
Result
Result
Result
Result
Result
Questions?

C++ Design Patterns Seminar

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

C++ Design Patterns Seminar

Uploaded by

Copyright:

Available Formats

C++ Design Patterns

Advanced C++ Programming Seminar, Summer Term 2009

You might also like