COMP2511 Week 7

Agenda

  • Admin Stuff
  • Abstract Factory Pattern
  • Decorator Pattern
  • Singleton Pattern and Concurrency

Admin Stuff

  • Congrats on finishing Assignment 1!
    • Marks and feedback will be coming soon :)
  • Assignment 2 should be underway!
    • Incorporate feedback from Assignment 1
    • For any group issues, it is best to first communicate with your partner, but if the problem persists let me know ASAP

Assignment 2 Tips

Assignment 2 Tips

Blog Posts

  • Follow the template in the spec and attach the merge request to the correct task
  • Tutors will not have enough time to look through your entire codebase for things not mentioned in the blogs
  • Make sure your merge requests are as clear as possible in completing a single task / implementation
  • Make it easy for us to award you marks 

Assignment 2 Tips

Task 1 Part d)

  • Address all 3 problems mentioned in the spec
  • Find and resolve more problems for higher marks
  • Do not intentionally write bad code in earlier parts and refactor them in this section
  • Do not refactor to resolve a problem that does not exist yet

Design Smells

Assignment 2 Tips

Task 2

  • If you are group of 2, only need to complete parts a) and b)
  • If you are a group of 3, must complete part c) additionally

Abstract Factory Pattern

Abstract Factory Pattern

When to use it?

  • When code needs to work with variants of each family of products
  • Many designs start by using the Factory Pattern and evolve towards Abstract Factory

What is it?

Creational design pattern that lets you produce families of related objected without specifying concrete classes. 

Abstract Factory Pattern

Say we decide to further extend our game, so that we have several variants.

For example, products King + Queen + Knight + Dragon are available in different variants:

KingdomA, KingdomB

Abstract Factory Pattern

The abstract factory is the interface with all the creation methods in the product family. 

For each family variant, we create a separate factory class

Abstract Factory Pattern

CharacterFactory

MetalFactory

PlasticFactory

MetalKing

MetalQueen

PlasticKing

PlasticQueen

King

Queen

Game

Abstract Factory Pattern

In tutorial 04, we discussed the factory pattern. We'll now look at a slightly modified scenario where the abstract factory pattern is more appropriate

Decorator Pattern

Decorator Pattern

What is it?

Structural design pattern that allows the behaviour of objects to be enhanced placing them into special wrapper objects

What problems does it solve?

Directly subclassing to combine different behaviours can lead to a large number of subclasses.

Decorator Pattern

Why not just use inheritance?

  • Inheritance can only occur at compile time
  • Most languages only allow single inheritance

Decorator Pattern

  1. Component is common interface for both wrapper and wrapped objects

  2. BaseDecorator has-a (composition) with Component. It then delegates operations to wrappee object

wrappee

wrapper

public void execute() {
	wrappee.execute();
}

Decorator Pattern

Updated Requirements:

Decorator Pattern

Component Interface (Character)

  • Defines the contract that all kinds of characters (and their decorators) must have the specified basic behaviour (e.g. damage(), canMove())

Concrete Component (CharacterBase)

  • Holds the actual implementation for the most basic Character/Entity

Character

CharacterBase

CharacterDecorator

Helmet

Singleton Pattern

Singleton Pattern

What is this?

Creational design pattern that specifies that a class can only have one instance. Accessing the instance must be via a global access point.

 

Why use it?

  • Control access to some shared resource. i.e. a file.
  • Need global variables that would not be overwritten 

 

Singleton Pattern

The instance is only created when the getInstance method is first called.

Singleton Pattern

Singleton Pattern

Currently, the threads can all access the bank account at the same time. This can lead to undesirable behaviour like

 

Denver is accessing the bank.
Tokyo is accessing the bank.
The final balance is: $100
Rio is accessing the bank.
Rio successfully withdrew $20
Tokyo successfully withdrew $6
Denver successfully withdrew $49
Tokyo successfully withdrew $6
Denver failed to withdraw $49.
Rio successfully withdrew $20
Rio failed to withdraw $20.
Denver is leaving the bank, the balance is -1
Tokyo failed to withdraw $6.
Rio failed to withdraw $20.
Tokyo failed to withdraw $6.
Rio failed to withdraw $20.
Tokyo failed to withdraw $6.
Tokyo failed to withdraw $6.
Rio is leaving the bank, the balance is -1
Tokyo is leaving the bank, the balance is -1

Bank account only had $100 but $101 was taken out!

Currently, the threads can all access the bank account at the same time. This can lead to undesirable behaviour like

 

Singleton Pattern

The undesired behaviour is caused by race conditions

This is when two or more threads can access shared data and they try to change it at the same time.

 

Because the thread scheduling can swap between threads at any time, you don't know the order the threads will access the shared data

 

Singleton Pattern

How does Singleton Pattern fix this?

 

Refactor using the Singleton Pattern to ensure only one person can access the bank account at a time!

  • Ensure class has just a single instance to control access to the shared resource.  
  • Make a global access point to that instance 
Made with Slides.com