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>classMuslim{// Abstract Targetpublic:virtual~Muslim()=default;virtualvoidperformsMuslimRitual()const=0;};classMuslimFemale:publicMuslim{// Concrete Targetpublic:virtualvoidperformsMuslimRitual()constoverride{std::cout<<"Muslim girl performs Muslim ritual."<<std::endl;}};classHindu{// Abstract Adapteepublic:virtual~Hindu()=default;virtualvoidperformsHinduRitual()const=0;};classHinduFemale:publicHindu{// Concrete Adapteepublic:virtualvoidperformsHinduRitual()constoverride{std::cout<<"Hindu girl performs Hindu ritual."<<std::endl;}};classMuslimRitual{public:voidcarryOutRitual(Muslim*muslim){std::cout<<"On with the Muslim rituals!"<<std::endl;muslim->performsMuslimRitual();}};classMuslimAdapter:publicMuslim{// Adapterprivate:Hindu*hindu;public:MuslimAdapter(Hindu*h):hindu(h){}virtualvoidperformsMuslimRitual()constoverride{hindu->performsHinduRitual();}};intmain(){// Client codeHinduFemale*hinduGirl=newHinduFemale;MuslimFemale*muslimGirl=newMuslimFemale;MuslimRitualmuslimRitual;// muslimRitual.carryOutRitual (hinduGirl); // Will not compile of course since the parameter must be of type Muslim*.MuslimAdapter*adaptedHindu=newMuslimAdapter(hinduGirl);// hinduGirl has adapted to become a Muslim!muslimRitual.carryOutRitual(muslimGirl);muslimRitual.carryOutRitual(adaptedHindu);// So now hinduGirl, in the form of adaptedHindu, participates in the muslimRitual!// Note that hinduGirl is carrying out her own type of ritual in muslimRitual though.deleteadaptedHindu;// adaptedHindu is not needed anymoredeletehinduGirl;// hinduGirl is not needed anymoredeletemuslimGirl;// muslimGirl is not needed anymore, tooreturn0;}

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.

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";}};classPremiumSoundSystem:publicOptionsDecorator{Car*_b;public:PremiumSoundSystem(Car*b){_b=b;}stringgetDescription(){return_b->getDescription()+", PremiumSoundSystem";}doublegetCost(){return0.30+_b->getCost();}~PremiumSoundSystem(){cout<<"~PremiumSoundSystem()\n";}};classManualTransmission:publicOptionsDecorator{Car*_b;public:ManualTransmission(Car*b){_b=b;}stringgetDescription(){return_b->getDescription()+", ManualTransmission";}doublegetCost(){return0.30+_b->getCost();}~ManualTransmission(){cout<<"~ManualTransmission()\n";}};intmain(){//Create our Car that we want to buyCar*b=newCarModel1();cout<<"Base model of "<<b->getDescription()<<" costs $"<<b->getCost()<<"\n";//Who wants base model let's add some more featuresb=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;}

#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 Facade Pattern hides the complexities of the system by providing an interface to the client from where the client can access the system on an 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

The pattern for saving memory (basically) by sharing properties of objects. Imagine a huge amount of similar objects which all have most of their properties the same. It's 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 be may of floating point typestaticstd::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 sizeunsignedshortfontNameIndex;// index instead of font nameunsignedpositionInStream;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 it's 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 whith 1000 chars in each group which will save us 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 ammount of memory and will make each object super light in comparisson to it's 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;}

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.

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.

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