Skip to content

Instantly share code, notes, and snippets.

@amadeu01
Created May 29, 2018 04:27
Show Gist options
  • Save amadeu01/f32c39b980271cb5f04765b41e2b15f1 to your computer and use it in GitHub Desktop.
Save amadeu01/f32c39b980271cb5f04765b41e2b15f1 to your computer and use it in GitHub Desktop.
Design Patterns Explanations

Design Pattern

  • Creational Patterns
    1. Abstract Factory
    2. Builder
    3. Factory Method
    4. Object Pool
    5. Prototype
    6. Singleton
  • Structural Patterns
  • Behavioural Patterns

Factory Method Design Pattern

This patterns is one of the Creational Pattern

Intent

Define an interface for creating a standard for an object. However, let the subclass of that of object be able to define and instantiate the new object.

Even though the creation of the object is defined in the superclass, the subclass can change the returned object that will be created.

Problem

The need of standard return models for one application. For instance:

  • Depending on the goal of the this class. The way how the objects are instantiated can cause or not some trouble. So, I just need the objects, but the implementation of the objects initialisation can prevent or cause problems.
class CoreDataStore {

    static var persistentStoreCoordinator: NSPersistentStoreCoordinator? {
        ...
    }

    static var managedObjectModel: NSManagedObjectModel? {
       ...
    }

    static var managedObjectContext: NSManagedObjectContext? {
        ...
    }

}

Struct

  1. Product:

Declares the single interface for all objects that can be produced by the creator and its subclasses.

  1. Concrete Product

Concrete Products are the different implementations of the Product interface. Concrete Creators will create and return instances of these classes.

  1. Creator

Creator declares a factory method that returns the Product type. This method can either be abstract or have some default implementation. In the first case, all Concrete Creators must implement their factory methods.

Despite the name, in the real world, the product creation is not the main responsibility of a Creator class. Usually, it has some core business logic that works with Products.

Here is the analogy: a large software development company can have a training department for programmers. But the primary function of the company is still writing code.

  1. Concrete Creator

Concrete Creators implement or override the base factory method, by creating and returning one of the Concrete Products.

Note that a factory method does not have to create new instances all the time. It can also return existing objects from some cache, etc.

Discussion

Factory Method makes subclasses responsible for choosing concrete classes of products that will be created.

In the above code:

class CoreDataStore {

    static var persistentStoreCoordinator: NSPersistentStoreCoordinator? {
        ...
    }

    static var managedObjectModel: NSManagedObjectModel? {
       ...
    }

    static var managedObjectContext: NSManagedObjectContext? {
        ...
    }

}

We could use a Protocol to make sure we will get some stuff from CoreDataStore

class CoreDataStoreProtocol {

    var persistentStoreCoordinator: NSPersistentStoreCoordinator? { get }

    var managedObjectModel: NSManagedObjectModel? { get }

    var managedObjectContext: NSManagedObjectContext? { get }

}

Then on test I could do something like:

extension NSPersistentStoreCoordinator {
    // Do stuff for new Product instantiation for test
    init(_ customInit: SomeParameter) { ... }
}

And my test creator:

class CoreDataStoreTest: CoreDataStoreProtocol {

    static var persistentStoreCoordinator: NSPersistentStoreCoordinator? {
        return NSPersistentStoreCoordinator(SomeParameter)
    }

    static var managedObjectModel: NSManagedObjectModel? {
       ...
    }

    static var managedObjectContext: NSManagedObjectContext? {
        ...
    }

}

Applicability

  • When you do not know what type of particularities your initialisation code will need. For instance if you need some default SDK context for initialise your object on one kind of environment, that might broke your code on other environment.
  • When you want to provide flexibility, such as when you, at the same, want to provide a standard but that can be altered/transformed by its subclasses. Such as bottoms, they might have default methods and ways to behaviour, but they can have tiny different characteristics such as color or size.

How to implement

Pros and Cons

  • Pros

    • Follows the Open/Closed Principle.
      • Avoids tight coupling between concrete products and code that uses them.
      • Simplifies code due to moving all creational code to one place.
      • Simplifies adding new products to the program.
  • Cons

    • Requires extra subclasses.

Source

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment