Jump to content
Wikibooks The Free Textbook Project

C++ Programming/Code/Design Patterns/Structural Patterns

From Wikibooks, open books for an open world
The latest reviewed version was checked on 5 June 2024. There are template/file changes awaiting review.

Structural Patterns

[edit | edit source ]

Adapter

[edit | edit source ]

Convert the interface of a class into another interface that clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

#include<iostream>

classDog{// Abstract Target
public:
virtual~Dog()=default;
virtualvoidperformsConversion()const=0;
};

classDogFemale:publicDog{// Concrete Target
public:
virtualvoidperformsConversion()constoverride{std::cout<<"Dog female performs conversion."<<std::endl;}
};

classCat{// Abstract Adaptee
public:
virtual~Cat()=default;
virtualvoidperformsConversion()const=0;
};

classCatFemale:publicCat{// Concrete Adaptee
public:
virtualvoidperformsConversion()constoverride{std::cout<<"Cat female performs conversion."<<std::endl;}
};

classDogNature{
public:
voidcarryOutNature(Dog*dog){
std::cout<<"On with the Dog nature!"<<std::endl;
dog->performsConversion();
}
};

classConversionAdapter:publicDog{// Adapter
private:
Cat*cat;
public:
ConversionAdapter(Cat*c):cat(c){}
virtualvoidperformsConversion()constoverride{cat->performsConversion();}
};

intmain(){// Client code
DogFemale*dogFemale=newDogFemale;
CatFemale*catFemale=newCatFemale;
DogNaturedogNature;
//	dogNature.carryOutNature (catFemale); // Will not compile of course since the parameter must be of type Dog*.
ConversionAdapter*adaptedCat=newConversionAdapter(catFemale);// catFemale has adapted to become a Dog!

dogNature.carryOutNature(dogFemale);
dogNature.carryOutNature(adaptedCat);// So now catFemale, in the form of adaptedCat, participates in the dogNature!
// Note that catFemale is carrying out her own type of nature in dogNature though.

deleteadaptedCat;// adaptedCat is not needed anymore
deletecatFemale;// catFemale is not needed anymore
deletedogFemale;// dogFemale is not needed anymore, too
return0;
}

Bridge

[edit | edit source ]

The Bridge Pattern is used to separate out the interface from its implementation. Doing this gives the flexibility so that both can vary independently.

The following example will output:

API1.circle at 1:2 7.5
API2.circle at 5:7 27.5
#include<iostream>
usingnamespacestd;
/* Implementor*/
classDrawingAPI{
public:
virtualvoiddrawCircle(doublex,doubley,doubleradius)=0;
virtual~DrawingAPI(){}
};
/* Concrete ImplementorA*/
classDrawingAPI1:publicDrawingAPI{
public:
voiddrawCircle(doublex,doubley,doubleradius){
cout<<"API1.circle at "<<x<<':'<<y<<' '<<radius<<endl;
}
};
/* Concrete ImplementorB*/
classDrawingAPI2:publicDrawingAPI{
public:
voiddrawCircle(doublex,doubley,doubleradius){
cout<<"API2.circle at "<<x<<':'<<y<<' '<<radius<<endl;
}
};
/* Abstraction*/
classShape{
public:
virtual~Shape(){}
virtualvoiddraw()=0;
virtualvoidresizeByPercentage(doublepct)=0;
};
/* Refined Abstraction*/
classCircleShape:publicShape{
public:
CircleShape(doublex,doubley,doubleradius,DrawingAPI*drawingAPI):
m_x(x),m_y(y),m_radius(radius),m_drawingAPI(drawingAPI)
{}
voiddraw(){
m_drawingAPI->drawCircle(m_x,m_y,m_radius);
}
voidresizeByPercentage(doublepct){
m_radius*=pct;
}
private:
doublem_x,m_y,m_radius;
DrawingAPI*m_drawingAPI;
};
intmain(void){
CircleShapecircle1(1,2,3,newDrawingAPI1());
CircleShapecircle2(5,7,11,newDrawingAPI2());
circle1.resizeByPercentage(2.5);
circle2.resizeByPercentage(2.5);
circle1.draw();
circle2.draw();
return0;
}

Composite

[edit | edit source ]

Composite lets clients treat individual objects and compositions of objects uniformly. The Composite pattern can represent both the conditions. In this pattern, one can develop tree structures for representing part-whole hierarchies.

#include<vector>
#include<iostream> // std::cout
#include<memory> // std::auto_ptr
#include<algorithm> // std::for_each
usingnamespacestd;

classGraphic
{
public:
virtualvoidprint()const=0;
virtual~Graphic(){}
};

classEllipse:publicGraphic
{
public:
voidprint()const{
cout<<"Ellipse \n";
}
};

classCompositeGraphic:publicGraphic
{
public:
voidprint()const{
for(Graphic*a:graphicList_){
a->print();
}
}

voidadd(Graphic*aGraphic){
graphicList_.push_back(aGraphic);
}

private:
vector<Graphic*>graphicList_;
};

intmain()
{
// Initialize four ellipses
constauto_ptr<Ellipse>ellipse1(newEllipse());
constauto_ptr<Ellipse>ellipse2(newEllipse());
constauto_ptr<Ellipse>ellipse3(newEllipse());
constauto_ptr<Ellipse>ellipse4(newEllipse());

// Initialize three composite graphics
constauto_ptr<CompositeGraphic>graphic(newCompositeGraphic());
constauto_ptr<CompositeGraphic>graphic1(newCompositeGraphic());
constauto_ptr<CompositeGraphic>graphic2(newCompositeGraphic());

// Composes the graphics
graphic1->add(ellipse1.get());
graphic1->add(ellipse2.get());
graphic1->add(ellipse3.get());

graphic2->add(ellipse4.get());

graphic->add(graphic1.get());
graphic->add(graphic2.get());

// Prints the complete graphic (four times the string "Ellipse")
graphic->print();
return0;
}

Decorator

[edit | edit source ]

The decorator pattern helps to attach additional behavior or responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. This is also called "Wrapper". If your application does some kind of filtering, then Decorator might be good pattern to consider for the job.

#include<string>
#include<iostream>
usingnamespacestd;
classCar//Our Abstract base class
{
protected:
string_str;
public:
Car()
{
_str="Unknown Car";
}

virtualstringgetDescription()
{
return_str;
}

virtualdoublegetCost()=0;

virtual~Car()
{
cout<<"~Car()\n";
}
};

classOptionsDecorator:publicCar//Decorator Base class
{
public:
virtualstringgetDescription()=0;

virtual~OptionsDecorator()
{
cout<<"~OptionsDecorator()\n";
}
};


classCarModel1:publicCar
{
public:
CarModel1()
{
_str="CarModel1";
}
virtualdoublegetCost()
{
return31000.23;
}

~CarModel1()
{
cout<<"~CarModel1()\n";
}
};


classNavigation:publicOptionsDecorator
{
Car*_b;
public:
Navigation(Car*b)
{
_b=b;
}
stringgetDescription()
{
return_b->getDescription()+", Navigation";
}

doublegetCost()
{
return300.56+_b->getCost();
}
~Navigation()
{
cout<<"~Navigation()\n";
delete_b;
}
};

classPremiumSoundSystem:publicOptionsDecorator
{
Car*_b;
public:
PremiumSoundSystem(Car*b)
{
_b=b;
}
stringgetDescription()
{
return_b->getDescription()+", PremiumSoundSystem";
}

doublegetCost()
{
return0.30+_b->getCost();
}
~PremiumSoundSystem()
{
cout<<"~PremiumSoundSystem()\n";
delete_b;
}
};

classManualTransmission:publicOptionsDecorator
{
Car*_b;
public:
ManualTransmission(Car*b)
{
_b=b;
}
stringgetDescription()
{
return_b->getDescription()+", ManualTransmission";
}

doublegetCost()
{
return0.30+_b->getCost();
}
~ManualTransmission()
{
cout<<"~ManualTransmission()\n";
delete_b;
}
};

intmain()
{
//Create our Car that we want to buy
Car*b=newCarModel1();
cout<<"Base model of "<<b->getDescription()<<" costs $"<<b->getCost()<<"\n";

//Who wants base model let's add some more features

b=newNavigation(b);
cout<<b->getDescription()<<" will cost you $"<<b->getCost()<<"\n";
b=newPremiumSoundSystem(b);
b=newManualTransmission(b);
cout<<b->getDescription()<<" will cost you $"<<b->getCost()<<"\n";
// WARNING! Here we leak the CarModel1, Navigation and PremiumSoundSystem objects!
// Either we delete them explicitly or rewrite the Decorators to take 
// ownership and delete their Cars when destroyed.
deleteb;
return0;
}

The output of the program above is:

BasemodelofCarModel1costs31000ドル.2
CarModel1,Navigationwillcostyou31300ドル.8
CarModel1,Navigation,PremiumSoundSystem,ManualTransmissionwillcostyou31301ドル.4
~ManualTransmission
~PremiumSoundSystem()
~Navigation()
~CarModel1
~Car()
~OptionsDecorator()
~Car()
~OptionsDecorator()
~Car()
~OptionsDecorator()
~Car()

Another example(C++14):

#include<iostream>
#include<string>
#include<memory>
classInterface{
public:
virtual~Interface(){}
virtualvoidwrite(std::string&)=0;
};
classCore:publicInterface{
public:
~Core(){std::cout<<"Core destructor called.\n";}
virtualvoidwrite(std::string&text)override{};// Do nothing.
};
classDecorator:publicInterface{
private:
std::unique_ptr<Interface>interface;
public:
Decorator(std::unique_ptr<Interface>c){interface=std::move(c);}
virtualvoidwrite(std::string&text)override{interface->write(text);}
};
classMessengerWithSalutation:publicDecorator{
private:
std::stringsalutation;
public:
MessengerWithSalutation(std::unique_ptr<Interface>c,conststd::string&str):Decorator(std::move(c)),salutation(str){}
~MessengerWithSalutation(){std::cout<<"Messenger destructor called.\n";}
virtualvoidwrite(std::string&text)override{
text=salutation+"\n\n"+text;
Decorator::write(text);
}
};
classMessengerWithValediction:publicDecorator{
private:
std::stringvalediction;
public:
MessengerWithValediction(std::unique_ptr<Interface>c,conststd::string&str):Decorator(std::move(c)),valediction(str){}
~MessengerWithValediction(){std::cout<<"MessengerWithValediction destructor called.\n";}
virtualvoidwrite(std::string&text)override{
Decorator::write(text);
text+="\n\n"+valediction;
}
};
intmain(){
conststd::stringsalutation="Greetings,";
conststd::stringvalediction="Sincerly, Andy";
std::stringmessage1="This message is not decorated.";
std::stringmessage2="This message is decorated with a salutation.";
std::stringmessage3="This message is decorated with a valediction.";
std::stringmessage4="This message is decorated with a salutation and a valediction.";
std::unique_ptr<Interface>messenger1=std::make_unique<Core>();
std::unique_ptr<Interface>messenger2=std::make_unique<MessengerWithSalutation>(std::make_unique<Core>(),salutation);
std::unique_ptr<Interface>messenger3=std::make_unique<MessengerWithValediction>(std::make_unique<Core>(),valediction);
std::unique_ptr<Interface>messenger4=std::make_unique<MessengerWithValediction>(std::make_unique<MessengerWithSalutation>
(std::make_unique<Core>(),salutation),valediction);

messenger1->write(message1);
std::cout<<message1<<'\n';
std::cout<<"\n------------------------------\n\n";
messenger2->write(message2);
std::cout<<message2<<'\n';
std::cout<<"\n------------------------------\n\n";
messenger3->write(message3);
std::cout<<message3<<'\n';
std::cout<<"\n------------------------------\n\n";
messenger4->write(message4);
std::cout<<message4<<'\n';
std::cout<<"\n------------------------------\n\n";
}

The output of the program above is:

Thismessageisnotdecorated.
------------------------------
Greetings,
Thismessageisdecoratedwithasalutation.
------------------------------
Thismessageisdecoratedwithavalediction.
Sincerly,Andy
------------------------------
Greetings,
Thismessageisdecoratedwithasalutationandavalediction.
Sincerly,Andy
------------------------------
MessengerWithValedictiondestructorcalled.
Messengerdestructorcalled.
Coredestructorcalled.
MessengerWithValedictiondestructorcalled.
Coredestructorcalled.
Messengerdestructorcalled.
Coredestructorcalled.
Coredestructorcalled.

Facade

[edit | edit source ]

The Facade Pattern hides the complexities of the system by providing an interface to the client from where the client can access the system on a unified interface. Facade defines a higher-level interface that makes the subsystem easier to use. For instance making one class method perform a complex process by calling several other classes.

/*Facade is one of the easiest patterns I think... And this is very simple example.
Imagine you set up a smart house where everything is on remote. So to turn the lights on you push lights on button - And same for TV,
AC, Alarm, Music, etc...
When you leave a house you would need to push a 100 buttons to make sure everything is off and are good to go which could be little 
annoying if you are lazy like me 
so I defined a Facade for leaving and coming back. (Facade functions represent buttons...) So when I come and leave I just make one 
call and it takes care of everything...
*/
#include<string>
#include<iostream>
usingnamespacestd;
classAlarm
{
public:
voidalarmOn()
{
cout<<"Alarm is on and house is secured"<<endl;
}
voidalarmOff()
{
cout<<"Alarm is off and you can go into the house"<<endl;
}
};
classAc
{
public:
voidacOn()
{
cout<<"Ac is on"<<endl;
}
voidacOff()
{
cout<<"AC is off"<<endl;
}
};
classTv
{
public:
voidtvOn()
{
cout<<"Tv is on"<<endl;
}
voidtvOff()
{
cout<<"TV is off"<<endl;
}
};
classHouseFacade
{
Alarmalarm;
Acac;
Tvtv;
public:
HouseFacade(){}
voidgoToWork()
{
ac.acOff();
tv.tvOff();
alarm.alarmOn();
}
voidcomeHome()
{
alarm.alarmOff();
ac.acOn();
tv.tvOn();
}
};
intmain()
{
HouseFacadehf;
//Rather than calling 100 different on and off functions thanks to facade I only have 2 functions...
hf.goToWork();
hf.comeHome();
}

The output of the program above is:

AC is off
TV is off
Alarm is on and house is secured
Alarm is off and you can go into the house
Ac is on
Tv is on

Flyweight

[edit | edit source ]

The pattern for saving memory (basically) by sharing properties of objects. Imagine a huge number of similar objects which all have most of their properties the same. It is natural to move these properties out of these objects to some external data structure and provide each object with the link to that data structure.

#include<iostream>
#include<string>
#include<vector>
#define NUMBER_OF_SAME_TYPE_CHARS 3;
/* Actual flyweight objects class (declaration) */
classFlyweightCharacter;
/*
	FlyweightCharacterAbstractBuilder is a class holding the properties which are shared by
	many objects. So instead of keeping these properties in those objects we keep them externally, making
	objects flyweight. See more details in the comments of main function.
*/
classFlyweightCharacterAbstractBuilder{
FlyweightCharacterAbstractBuilder(){}
~FlyweightCharacterAbstractBuilder(){}
public:
staticstd::vector<float>fontSizes;// lets imagine that sizes may be of floating point type
staticstd::vector<std::string>fontNames;// font name may be of variable length (lets take 6 bytes is average)
staticvoidsetFontsAndNames();
staticFlyweightCharactercreateFlyweightCharacter(unsignedshortfontSizeIndex,
unsignedshortfontNameIndex,
unsignedshortpositionInStream);
};
std::vector<float>FlyweightCharacterAbstractBuilder::fontSizes(3);
std::vector<std::string>FlyweightCharacterAbstractBuilder::fontNames(3);
voidFlyweightCharacterAbstractBuilder::setFontsAndNames(){
fontSizes[0]=1.0;
fontSizes[1]=1.5;
fontSizes[2]=2.0;
fontNames[0]="first_font";
fontNames[1]="second_font";
fontNames[2]="third_font";
}
classFlyweightCharacter{
unsignedshortfontSizeIndex;// index instead of actual font size
unsignedshortfontNameIndex;// index instead of font name
unsignedpositionInStream;
public:
FlyweightCharacter(unsignedshortfontSizeIndex,unsignedshortfontNameIndex,unsignedshortpositionInStream):
fontSizeIndex(fontSizeIndex),fontNameIndex(fontNameIndex),positionInStream(positionInStream){}
voidprint(){
std::cout<<"Font Size: "<<FlyweightCharacterAbstractBuilder::fontSizes[fontSizeIndex]
<<", font Name: "<<FlyweightCharacterAbstractBuilder::fontNames[fontNameIndex]
<<", character stream position: "<<positionInStream<<std::endl;
}
~FlyweightCharacter(){}
};
FlyweightCharacterFlyweightCharacterAbstractBuilder::createFlyweightCharacter(unsignedshortfontSizeIndex,unsignedshortfontNameIndex,unsignedshortpositionInStream){
FlyweightCharacterfc(fontSizeIndex,fontNameIndex,positionInStream);
returnfc;
}
intmain(intargc,char**argv){
std::vector<FlyweightCharacter>chars;
FlyweightCharacterAbstractBuilder::setFontsAndNames();
unsignedshortlimit=NUMBER_OF_SAME_TYPE_CHARS;
for(unsignedshorti=0;i<limit;i++){
chars.push_back(FlyweightCharacterAbstractBuilder::createFlyweightCharacter(0,0,i));
chars.push_back(FlyweightCharacterAbstractBuilder::createFlyweightCharacter(1,1,i+1*limit));
chars.push_back(FlyweightCharacterAbstractBuilder::createFlyweightCharacter(2,2,i+2*limit));
}
/*
		Each char stores links to its fontName and fontSize so what we get is:
		each object instead of allocating 6 bytes (convention above) for string
		and 4 bytes for float allocates 2 bytes for fontNameIndex and fontSizeIndex.
		That means for each char we save 6 +たす 4 -ひく 2 -ひく 2 = 6 bytes.
		Now imagine we have NUMBER_OF_SAME_TYPE_CHARS = 1000 i.e. with our code
		we will have 3 groups of chars with 1000 chars in each group which will save 
		3 * 1000 * 6 - (3 * 6 + 3 * 4) = 17970 saved bytes.
		3 * 6 + 3 * 4 is a number of bytes allocated by FlyweightCharacterAbstractBuilder.
		So the idea of the pattern is to move properties shared by many objects to some
		external container. The objects in that case don't store the data themselves they
		store only links to the data which saves memory and make the objects lighter.
		The data size of properties stored externally may be significant which will save REALLY
		huge amount of memory and will make each object super light in comparison to its counterpart.
		That's where the name of the pattern comes from: flyweight (i.e. very light).
	*/
for(unsignedshorti=0;i<chars.size();i++){
chars[i].print();
}
std::cin.get();return0;
}

Proxy

[edit | edit source ]

The Proxy Pattern will provide an object a surrogate or placeholder for another object to control access to it. It is used when you need to represent a complex object with a simpler one. If creation of an object is expensive, it can be postponed until the very need arises and meanwhile a simpler object can serve as a placeholder. This placeholder object is called the "Proxy" for the complex object.

#include<iostream>
#include<memory>
classICar{
public:
virtual~ICar(){std::cout<<"ICar destructor!"<<std::endl;}
virtualvoidDriveCar()=0;
};
classCar:publicICar{
public:
voidDriveCar()override{std::cout<<"Car has been driven!"<<std::endl;}
};
classProxyCar:publicICar{
public:
ProxyCar(intdriver_age):driver_age_(driver_age){}
voidDriveCar()override{
if(driver_age_>16){
real_car_->DriveCar();
}else{
std::cout<<"Sorry, the driver is too young to drive."<<std::endl;
}
}
private:
std::unique_ptr<ICar>real_car_=std::make_unique<Car>();
intdriver_age_;
};
intmain(){
std::unique_ptr<ICar>car=std::make_unique<ProxyCar>(16);
car->DriveCar();
car=std::make_unique<ProxyCar>(25);
car->DriveCar();
return0;
}

Curiously Recurring Template

[edit | edit source ]

This technique is known more widely as a Mixin. Mixins are described in the literature to be a powerful tool for expressing abstractions[citation needed ].

Interface-based Programming (IBP)

[edit | edit source ]

Interface-based programming is closely related with Modular Programming and Object-Oriented Programming, it defines the application as a collection of inter-coupled modules (interconnected and which plug into each other via interface). Modules can be unplugged, replaced, or upgraded, without the need of compromising the contents of other modules.

The total system complexity is greatly reduced. Interface Based Programming adds more to modular Programming in that it insists that Interfaces are to be added to these modules. The entire system is thus viewed as Components and the interfaces that helps them to co-act.

Interface-based Programming increases the modularity of the application and hence its maintainability at a later development cycles, especially when each module must be developed by different teams. It is a well-known methodology that has been around for a long time and it is a core technology behind frameworks such as CORBA. [citation needed ]

This is particularly convenient when third parties develop additional components for the established system. They just have to develop components that satisfy the interface specified by the parent application vendor.

Thus the publisher of the interfaces assures that he will not change the interface and the subscriber agrees to implement the interface as whole without any deviation. An interface is therefore said to be a Contractual agreement and the programming paradigm based on this is termed as "interface based programming".

AltStyle によって変換されたページ (->オリジナル) /