confiz-3c-blog

[confiz-3c-blog]

Factory Design Pattern

Introduction

Design Patterns represent solutions to problems what arise when developing software within a particular context.

Each pattern describes a problem which occurs over and over again in our environment, and then describes the 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.

Basically, there are three categories:

Creational Patterns: deal with initializing and configuring classes and objects

Structural Patterns: deal with decoupling the interface and implementation of classes and objects

Behavioral Patterns: deal with dynamic interactions among societies of classes and objects

Intent

creates objects without exposing the instantiation logic to the client.

refers to the newly created object through a common interface

Implementation

The implementation is really simple

The client needs a product, but instead of creating it directly using the new operator, it asks the factory object for a new product, providing the information about the type of object it needs.

The factory instantiates a new concrete product and then returns to the client the newly created product(casted to abstract product class).

The client uses the products as abstract products without being aware about their concrete implementation.

Applicability & Examples

Probably the factory pattern is one of the most used patterns.

For example a graphical application works with shapes. In our implementation the drawing framework is the client and the shapes are the products. All the shapes are derived from an abstract shape class (or interface). The Shape class defines the draw and move operations which must be implemented by the concrete shapes. Let's assume a command is selected from the menu to create a new Circle. The framework receives the shape type as a string parameter, it asks the factory to create a new shape sending the parameter received from menu. The factory creates a new circle and returns it to the framework, casted to an abstract shape. Then the framework uses the object as casted to the abstract class without being aware of the concrete object type.

 The advantage is obvious: New shapes can be added without changing a single line of code in the framework(the client code that uses the shapes from the factory). As it is shown in the next sections, there are certain factory implementations that allow adding new products without even modifying the factory class.

Look at the following example in C++:

Abstract Interface Class:

struct IAutoMobile  {    virtual bool Register(const std::string& RegistrationNumber) = 0;        virtual VehicleType GetType() = 0;    virtual VehicleColor GetColor() = 0;  };

Specific Implementation Class(es)

class CCar:public IAutoMobile  {  public:    CCar(const VehicleSpecification& VSpecs);        virtual bool Register(const std::string& RegistrationNumber);    virtual VehicleType GetType(){ return m_VehicleType;}    virtual VehicleColor GetColor(){return m_VehicleColor;}      virtual ~CCar();      private:    VehicleType m_VehicleType;    VehicleColor m_VehicleColor;    bool m_fRegistered;    std::string m_RegistrationNumber;  };

CCar::CCar(const VehicleSpecification& VSpecs)  {    m_VehicleType = VehicleType::CAR;    m_VehicleColor = VSpecs.Color;    m_fRegistered = false;  }  bool CCar::Register(const std::string& RegistrationNumber)  {    m_RegistrationNumber = RegistrationNumber;    m_fRegistered = true;    return true;  }

Factory Class Declaration

class CVehicleFactory  {  public:    static IAutoMobile* GetVehicle(const VehicleSpecification& VSpecs);  private:    //Lock-Down un-wanted stuff/Don't let this class to be initiated    CVehicleFactory();    CVehicleFactory(CVehicleFactory& CloneObj);    CVehicleFactory& operator=(CVehicleFactory& CloneObj);  };

IAutoMobile* CVehicleFactory::GetVehicle(const VehicleSpecification& VSpecs)  {         IAutoMobile *pAutoMobile = nullptr;

         if(VSpecs.Type == VehicleType::CAR ){

                  pAutoMobile = new CCar(VSpecs);

          }

          return pAutoMobile;

 }

[confiz-3c-blog]

Storage Classes (C++)

Introduction

This blog will be covering the concept of Storage classes in the context of C++. Every variable in C/C++ has a storage class. Storage class determines the scope/lifetime, linkage and memory location of objects. A variable can have only one storage class. .Storage classes Following are the storage classes in C++.

auto

register

static

extern

mutable

thread_local

After reading this list you might have got a clear idea of what are the storage classes and what is going to be in the rest of the blog.

Auto

Auto is the default storage class of every variable. Variables defined within a block have automatic storage unless explicitly defined otherwise. Automatic objects and variables have no linkage, they are not visible to code outside the block.

{       int mount;        auto int month; }

The example above defines two variables with the same storage class.

Register

In C++11, the register keyword is deprecated. It specifies that the variable is to be stored in a machine register, if possible. This means that the variable has a maximum size equal to the register size (32 or 64 bits). Like auto variables, register variables persist only until the end of the block in which they are declared.

{   register int  reg_var; }

Declaring a variable as register does not mean that it will always be stored in a register. It means it MIGHT be stored in a register. If the address-of operator (&) is used on an object that is declared with register, the compiler must put the object in memory rather than a register.

Static

The static storage class instructs the compiler to keep a local variable in existence during the life-time of the program instead of creating and destroying it each time it comes into and goes out of scope.

#include <iostream> using namespace std; void showstat( int curr ) {          static int nStatic;    // Value of nStatic is retained                                                              // between each function call          nStatic += curr;          cout << "nStatic is " << nStatic << endl; } int main() {           for ( int i = 0; i < 5; i++ )                    showstat( i ); }

output

nStatic is 0 nStatic is 1 nStatic is 3 nStatic is 6 nStatic is 10

This example shows how a variable declared static in a function retains its state between calls to that function.

If we make a const variable static it causes that variable's scope to be restricted to the file in which it is declared.

Extern

Objects and variables declared as extern declare an object that is defined in another scope or transition unit as having external linkage. For example we declare a function header with extern keyword in one file (.cpp) and provide its implementation in another file(.cpp).

//File1.cpp

#include <iostream> int count ; extern void write_extern();

main() {         count = 5;         write_extern(); }

#include <iostream> extern int count; void write_extern(void) {         std::cout << "Count is " << count << std::endl; }

Output

Count is 5

Mutable

Mutable storage class allows a member of an object to override constness. That is, a mutable member can be modified by a const member function.

class X {  public:        bool GetFlag() const   {                m_accessCount++;                return m_flag;        }  private:        bool m_flag;        mutable int m_accessCount; };

Thread_local

This is available in C++11. A variable declared with the thread_local specifier is accessible only on the thread on which it is created. The variable is created when the thread is created, and destroyed when the thread is destroyed. Each thread has its own copy of the variable. 

The thread_local specifier may be combined with static or extern. You can apply thread_local only to data declarations and definitions.