<file_sep># Abstract Factory Method

Factory patterns are examples of creational patterns.
Class creational patterns focus on the use of inheritance to decide the
object to be instantiated.
# Example 


![Factory Method Structure](current_UML.png)

# Intent

 *  Provide an interface for creating families of related or dependent
    objects without specifying their concrete classes.
 * The Abstract Factory pattern is very similar to the Factory Method
      pattern.One difference between the two is that with the Abstract
      Factory pattern, a class delegates the responsibility of object
      instantiation to another object via composition whereas the Factory
      Method pattern uses inheritance and relies on a subclass to handle the
      desired object instantiation
 * Actually, the delegated object frequently uses factory methods to
   perform the instantiation!

# Participants

* **AbstractFactory**:
    Declares an interface for operations that create abstract product objects
    
* **ConcreteFactory**:
    Implements the operations to create concrete product objects Implements the product interfcae
    
* **AbstractProduct**:
    Declares an interface for a type of product object
  
* **ConcreteCreator**
  Defines a product object to be created by the corresponding concrete factor
  
  Implements the AbstractProduct interface
* **Client**
  Uses only interface declared by abstractFactory and AbstractProduct classes

# Structure

![Factory Method Structure](UML_Structure.png)<file_sep># Command Pattern
    
  an object oriented callback,
  Using command as a object gives you lots of opportunities, 
  you can declare macro command or support undoable operations
  
# Example 

![Factory Method Structure](current_UML.png)

# Intent

 *  Encapsulate a request as an object, thereby letting you manipulate the
    requests in various ways, queue or log requests, support undoable
    operations.

# Participants

* **Command**:
    Declares an interface for executing an operation.
    
* **ConcreteCommand**:
    Defines a biding between a Receiver object and an action
    
* **Client**:
    creates a ConcreteCommand object and sets its receiver
  
* **Invoker**
  Asks the command to carry out the request
  
* **Receiver**
  Knows how to perform the operations associated with 
  carrying out a request, anc class may serve as a Receiver

# Structure

![Factory Method Structure](UML_Structure.png)<file_sep># Template Method

 Define a method in base-super class for an algorithm, and let sub-classes redefine sub-steps.
 It is just an method, that performs with the same structure & order & algorithm.

# Example 

This example for creating game with GameEngines, the algorithm is same for creating a new project in game engines.

![Visitor Pattern Structure](current_UML.png)


# Intent

 *  Define the skeleton of an algorithm in an operation, deferring some
    steps to subclasses. Template Method lets subclasses redefine certain
    steps of an algorithm without changing the algorithm’s structure.

# Problem

 Sometimes you want to specify the order of operations that a method
 uses, but allow subclasses to provide their own implementations of
 some of these operations.


# Structure

![Visitor Pattern Structure](UML_Structure.png)<file_sep># Singleton Pattern 

# Example 

![Visitor Pattern Structure](current_UML.png)


# Intent

 *  Ensure a class only has one instance, and provide a global point of
    access to it.
 
# Problem

*  Sometimes we want just a single instance of a class to exist in the
   system.
 *  A GUI application must have a single mouse.
 *  An OS must have one window manager.
 *  An active modem needs one telephone line.
 *  PC is connected to one keyboard.
   
 *  We need to have that one instance easily accessible.
   And we want to ensure that additional instances of the class can not
   be created.
# Participants

* **Singleton**:
  defines a getInstance operation that lets clients access its unique
  instance. getInstance is a class operation.
  May be responsible for creating its own unique instance.

# Structure

![Visitor Pattern Structure](UML_Structure.png)<file_sep># Factory Method

Factory patterns are examples of creational patterns.
Class creational patterns focus on the use of inheritance to decide the
object to be instantiated.
# Example 


![Factory Method Structure](current_UML.png)

# Intent

 *  Define an interface for creating an object, but let subclasses decide
    which class to instantiate

# Participants

* **Product**:
    Defines the interface for the type of objects the factory method creates
    
* **ConcreteProduct**:
    Implements the product interface
    
* **Creator**:
    Declares the factory method which returns an object of type Product
  
* **ConcreteCreator**
  Overrides the factory method to return an instance of a ConcreteProduct

# Structure

![Factory Method Structure](UML_Structure.png)<file_sep># Visitor Pattern


# Example 

 This example for increasing the employees income and vacation days, 
 To increase Employee income and vacation days we don't want to change 
 class representation so that we use **Visitor** pattern, 
 Firstly, We create **IncomeVisitor** for **changing the income of the employee** 
 and **VacationVisitor** for **manipulating the vacation days of the employee**

![Visitor Pattern Structure](current_UML.png)


# Intent

 *  The visitor pattern let you define a new operation for a class/object without
 changing the classes representation.
 *  Do the right thing based on the type of the objects.
 *  Double dispatch

# Problem

 Sometimes you need to add new operations to (interface)node objects but 
 it needs to know each sub type to performs the operation different in 
 each object&sub-classes.
 
 Many distinct and unrelated operations would need to be performed on node objects/classes
 in a heterogeneous aggregate structure. You dont want to have to query  the type of 
 each node and cast the pointer to correct type before performing the desired operation.
 

# Participants

 **Visitor** : Defins a Visit operation for each class 
 of **ConcreteElement** in the object structure.
 
 **ConcreteVisitor** : Implements each operation declared by the **Visitor**
 
 **Element** : Defines an accept operation that takes visitor as an argument.
 
 **ConcreteElement** : Implements an accept operation that takes **Visitor** as an argument.
 
 **ObjectStructure** : Can enumerate its elements.
                       May provide a high-level interface to allow the visitor to visit its
                       elements.
                       May either be a composite or a collection such as a list or set.


# Structure

![Visitor Pattern Structure](UML_Structure.png)<file_sep># Iterator Pattern(Cursor)

An aggregate object such as a list should allow a way to traverse its
elements without exposing its internal structure.

It should allow different traversal methods.
But, we really do not want to add all these methods to the interface
for the aggregate.
  
# Example 

![Factory Method Structure](current_UML.png)

# Intent

 *  Provide a way to access the elements of an aggregate object
    sequentially without exposing its underlying representation.
    
 *   An aggregate object is an object that contains other objects for the
    purpose of grouping those objects as a unit. It is also called a
    container or a collection. Examples are a linked list and a hash table
   
# Participants

* **Iterator**
Defines an interface for accessing and traversing elements.
* **ConcreteIterator**
Implements the Iterator interface.
Keeps track of the current position in the traversal.
* **Aggregate**
Defines an interface for creating an Iterator object (a factory method!)
* **ConcreteAggregate**
Implements the Iterator creation interface to return an instance of the
proper ConcreteIterator

# Structure

![Factory Method Structure](UML_Structure.png)
<file_sep># Facade Pattern 

# Example 

![Visitor Pattern Structure](current_UML.png)


# Intent

 *  Provide a unified interface to a set of interfaces in a subsystem.
 
 * Facade defines higher-level interface 
that makes the subsystem easier to use, 
but the client still has access to subsystem.  
# Problem

![Visitor Pattern Structure](motivation.png)

* Structuring a system into subsystems helps reduce complexity.

* Subsystems are groups of classes, or groups of classes and other
  subsystems.

* One way to reduce this complexity is to introduce a facade object that
  provides a single, simplified interface to the more general facilities of a
  subsystem.

# Participants

* **Facade**:
  Knows which subsystem classes are responsible for a request.
  Delegates the client requests to appropriate subsystem objects.
  
* **Subsystem classes**
  Implement subsystem functionality.
  Handle work assigned by the facade object.
  Have no knowledge of the facade; that is they keep no references to it.


# Structure

![Visitor Pattern Structure](UML_Structure.png)<file_sep># Composite Pattern
    
  A composite object represents a composition of heterogeneous, possibly
  recursive, component objects.
  
  **Problem**: composite object consists of several heterogeneous parts
  Client code is complicated by knowledge of object structure.
  Client must change if data structure changes.
  
  **Solution**: create a uniform interface for the object’s components
  Interface advertises all operations that components offer.
  Client deals only with the new uniform interface.
  Uniform interface is the union of the components’ services
  
# Example 

Flutter widgets example with transparent version of the Composite pattern.

![Factory Method Structure](current_UML.png)

# Intent

 *  Compose objects into tree structures to represent part-whole
    hierarchies.
    
 *   Composite lets clients treat individual objects and compositions of
    objects uniformly. This is called recursive composition

# Participants

* **Component**
declares the interface for objects in the composition.
implements default behavior for the interface common to all classes, as
appropriate.
declares an interface for accessing and managing its child components.
* **Leaf**
represents leaf objects in the composition. A leaf has no children.
defines behavior for primitive objects in the composition.
* **Composite**
defines behavior for components having children.
stores child components.
implements child-related operations in the Component interface.
* **Client**
manipulates objects in the composition through the Component
interface.
# Structure

![Factory Method Structure](UML_Structure.png)

![Factory Method Structure](UML_Structure_transparent.png)

![Factory Method Structure](UML_Structure_safer.png)<file_sep># Observer Pattern

# Example 

 This example about stock's, when stock price change it observers should notify. 
 In this example 
 * Stock is our Subject(AbstractSubject)
 * IBM is ConcreteSubject
 * Observer is AbstractObserver(interface for observables)
 * Investor is ConcreteObserver

![Visitor Pattern Structure](current_UML.png)


# Intent

 *  Define a one-to-many dependency between objects so that 
 when one object change the state, all its dependents are notified and updated automatically.

# Problem

 A large monolithic design does not scale well as new graphing or monitoring requirements are levied.
 

# Participants

 **Subject** : 
 * Keeps track of its observers (attach,detach)
 * Defines an interface for notify its observers.
 
 **Observer** : Defines an interface for update notification.
 
 **ConcreteSubject** :
 * The object being observed
 * Stores state of interest to ConcreteObserver objects
 * Sends a notification to its observers when state change
 
 **ConcreteObserver** : 
 * The observing object
 * Stores state that should stay consistent with the subject’s.
 * Implements the Observer update interface to keep its state consistent
 with the subject’s

# Structure

![Visitor Pattern Structure](UML_Structure.png)<file_sep>## Lecture : SE 311 - Software Architecture (Design Patterns)
In Izmir University of Economics


You can find weekly patterns inside the src folder

![src](UML_Structure.png)<file_sep>package week_06_abstract_factory;

public class SE311_Week06AbstractFactory {

    public static void main(String[] args) {

        PhoneCreator appleCreator = new AppleCreator();
        PhoneCreator samsungCreator = new SamsungCreator();

        appleCreator.createPhone();

        samsungCreator.createPhone();
    }
}

/**
 * Abstract Factory
 */
abstract class PhoneCreator {
    /**
     * Factory Method, let subclasses decide which class to instantiate
     *
     * @return
     */
    abstract Screen createScreen();

    /**
     * Factory Method, let subclasses decide which class to instantiate
     *
     * @return
     */
    abstract Processor createProcessor();

    /**
     * This is an Template Method,
     * We implement it, base class and we are overriding the steps which are Factory methods in sub-classes.
     */
    void createPhone() {
        createScreen();
        createProcessor();
    }
}

class AppleCreator extends PhoneCreator {

    @Override
    Screen createScreen() {
        return new AppleScreen();
    }

    @Override
    Processor createProcessor() {
        return new AppleProcessor();
    }
}

class SamsungCreator extends PhoneCreator {

    @Override
    Screen createScreen() {
        return new SamsungScreen();
    }

    @Override
    Processor createProcessor() {
        return new SamsungProcessor();
    }
}

/**
 * Product one
 */
interface Processor {
}

class AppleProcessor implements Processor {
    AppleProcessor() {
        System.out.println("AppleProcessor created!!");
    }
}

class SamsungProcessor implements Processor {
    SamsungProcessor() {
        System.out.println("SamsungProcessor created!!");
    }
}

interface Screen {
}

class AppleScreen implements Screen {
    AppleScreen() {
        System.out.println("AppleScreen created!!");
    }
}

class SamsungScreen implements Screen {
    SamsungScreen() {
        System.out.println("SamsungScreen created!!");
    }
}
<file_sep>package week_10_template;

public class SE311_Week10Template {

    public static void main(String[] args) {
        GameEngine unity = new Unity();
        GameEngine unreal = new UnrealEngine();


        unity.createNewGame("the-ozon");


        unreal.createNewGame("FindIt");
    }
}

abstract class GameEngine {


    /**
     * this is the template method
     * it has some steps which is can differ according to gameEngines
     * but the steps is generally is same.
     * <p>
     * We use this method from the base class
     *
     * @param gameName
     */
    public void createNewGame(String gameName) {
        startGameEngine();
        performCreateGame();
        typeGameProjectName(gameName);
        completeProcess();
        System.out.println("---------------------------------");
    }

    protected abstract void performCreateGame();

    protected abstract void typeGameProjectName(String gameName);

    protected abstract void completeProcess();

    protected abstract void startGameEngine();
}

class Unity extends GameEngine {

    @Override
    protected void performCreateGame() {
        System.out.println("Unity perform create game build.!");
    }

    @Override
    protected void typeGameProjectName(String gameName) {
        System.out.println("Unity perform type name build.! the name is : " + gameName);
    }

    @Override
    protected void completeProcess() {
        System.out.println("Unity perform complete process build.!");
        System.out.println("Game Created!!!");
    }

    @Override
    protected void startGameEngine() {
        System.out.println("Unity start game engine build.!");
    }
}

class UnrealEngine extends GameEngine {

    @Override
    protected void performCreateGame() {
        System.out.println("Unreal perform create game build.!");
    }

    @Override
    protected void typeGameProjectName(String gameName) {
        System.out.println("Unreal perform type name build.! the name is : " + gameName);
    }

    @Override
    protected void completeProcess() {
        System.out.println("Unreal perform complete process build.!");
        System.out.println("Game Created!!!");
    }

    @Override
    protected void startGameEngine() {
        System.out.println("Unreal start game engine build.!");
    }
}<file_sep>package week_04_composite;

import java.util.ArrayList;
import java.util.List;

public class SE311_Week04Composite {

    public static void main(String[] args) {

        Widget column = new Column();
        Widget container = new Container();
        Widget text = new Text();

        Widget subColumn = new Column();
        Widget subContainer = new Container();
        Widget subText = new Text();


        column.add(container);
        column.add(text);

        subColumn.add(subContainer);
        subColumn.add(subText);

        column.add(subColumn);

        column.build();

    }
}


/**
 * This is the Component, Transparent version
 */
interface Widget {

    void add(Widget widget);

    void remove(Widget widget);

    Widget getChild(int index);

    void build();
}

/**
 * This is the Composite which can have a leaf or composite
 */
class Column implements Widget {
    List<Widget> widgets = new ArrayList<>();

    @Override
    public void add(Widget widget) {
        widgets.add(widget);
    }

    @Override
    public void remove(Widget widget) {
        widgets.remove(widget);
    }

    @Override
    public Widget getChild(int index) {
        return widgets.get(index);
    }

    @Override
    public void build() {
        System.out.println("----------");
        for (int i = 0; i < widgets.size(); i++) {
            getChild(i).build();
        }
    }
}


class Container implements Widget {

    @Override
    public void add(Widget widget) {
        throw new UnsupportedOperationException();
    }

    @Override
    public void remove(Widget widget) {
        throw new UnsupportedOperationException();

    }

    @Override
    public Widget getChild(int index) {
        throw new UnsupportedOperationException();
    }

    @Override
    public void build() {
        System.out.println("Container Build!!");
    }
}


class Text implements Widget {

    @Override
    public void add(Widget widget) {
        throw new UnsupportedOperationException();
    }

    @Override
    public void remove(Widget widget) {
        throw new UnsupportedOperationException();
    }

    @Override
    public Widget getChild(int index) {
        throw new UnsupportedOperationException();
    }

    @Override
    public void build() {
        System.out.println("Text Build!!");
    }
}


<file_sep># Adapter Pattern (Wrapper)

# Example 

This example for creating game with GameEngines, the algorithm is same for creating a new project in game engines.

![Visitor Pattern Structure](current_UML.png)


# Intent

 *  Convert the interface of a class into another interface clients expect.
 Adapter lets classes work together that could not otherwise because of incompatible interfaces.
 
# Problem

*  Sometimes a toolkit or class library can not be used because its
 interface is incompatible with the interface required by an application.
*  We can not change the library interface, since we may not have its
 source code.
 * Even if we did have the source code, we probably should not change
 the library for each domain-specific application
 
# Participants

* **Target**: 
Defines the domain-specific interface that Client uses
* **Adapter**:
Adapts the interface of Adaptee to the Target interface
* **Client**
Colloborates with objects conforming to the Target interface
* **Adaptee**:
Defines an existing interface that needs adapting


# Structure

![Visitor Pattern Structure](UML_Structure.png)
![Visitor Pattern Structure](UML_Structure_Composition.png)