SE-2811 Software Component Design l Week 2 Day

SE-2811 Software Component Design l Week 2, Day 1 SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick 1

6 x + = + SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick 6 x 2

Class Schedule Manager SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick 3

Schedule. sort() public void sort() { Array. List new. List = new Array. List<>(); for(int old. Index = 0; old. Index < classes. size(); old. Index++) { int new. Index = 0; Class new. Class = classes. get(old. Index); while (new. Index < new. List. size() && new. List. get(new. Index). get. Name(). compare. To(new. Class. get. Name()) <= 0) { new. Index++; } new. List. add(new. Index, new. Class); } classes = new. List; } SE-2811 4 Dr. Josiah Yoder Slide style: Dr. Hornick

Class Schedule Manager (2) SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick 5

Applying the Strategy Pattern: Evidence 1 The Strategy Pattern is a behavioral pattern usually considered and applied at design-time. Premise: Your application requires similar objects whose behavior varies. SE-2811 Dr. Mark L. Hornick 6

Applying the Strategy Pattern: Evidence 2 As a designer, you watch for inheritance patterns that result in excessive behavior overrides and/or code duplication among classes. SE-2811 Dr. Mark L. Hornick 7

Applying the Strategy Pattern: Action! (Code v 5) Leave behavior that is truly shared in abstract classes. Isolate behavior(s) that vary and declare interfaces that define those behaviors Implement the behaviors in separate concrete classes whose references can be passed to the constructor SE-2811 Dr. Mark L. Hornick 8

Grassba l l l Goal: automatically mow your lawn Issue: need to support different patterns Classic solution: if statement

public class Grassba. Drive { public void move() { step(); if ( blocked() ) { if ( style == STRIP ) turn. Right(180); else if ( style == CROSS ) turn. Right(90); else turn. Right(random(180)); } } • But what about more interesting patterns? … • What if need to store pattern-specific } information? • What if there are large numbers of patterns?

Solution: write a class public class Grassba. Drive { public Grassba. Drive(Movement. Strategy s) { strategy = s; strategy. set. Drive(this); } public void move() { step(); is ( is. Blocked() ) behavior. Strategy. turn(); } … } public class Striped. Movement extends Movement. Behavior { public void turn() { turn. Right(180); } }

public class Criss. Cross. Movement extends Movement. Behavior { public void turn() { turn. Right(90); } } public class Random. Movement extends Movement. Behavior { public void turn() { turnright(random(180)); } }

Using the strategies: Grasba. Drive striped. Drive = new Grasba. Drive(new Striped. Movement()); Grasba. Drive rand. Drive = new Grasba. Drive(new Random. Movement()); // note would also have striped. Drive->get. Behavior. Strategy()->set. Driver(striped. Drive); How does this affect reusability?

General form Elements: • Context: class that encapsulates, uses specific behavior • Strategy: interface that defines the behavior • Concrete. Strategy: implements a specific behavior Is there a preference for interfaces over abstract classes?

When to use the Strategy pattern? Strategy pattern: a behavioral pattern l l l Captures run-time behavior Indicator: application requires similar objects whose behavior varies But is there another way to capture the different behavior?

Alternative to Strategy pattern l l Have an abstract base class with alternatives But what happens if add gas engine/ electric motor option?

Alternative to Strategy pattern l l Inheritance simpler in some cases, strategy pattern better in others. In general: significant code duplication, too many overrides What is this like with Strategy?

Singleton l l Sometimes it is important to have only one instance of a class One factory (that creates many “product” instances) l l l More on this later! One window manager One event logger The challenge: l l Ensure that a certain class has only one instance Provide global access to it

Question: How can you prevent any instances of a class from being created? Don’t write it? . . . Tell programmers, “just don’t create instances”?

Moving towards a solution… 1. Restrict the ability to construct more than one instance of a Singleton class 2. Make the class responsible for keeping track of its one and only instance 3. Provide a global (static) access method

Basic solution public class Singleton { private static Singleton unique. Instance = new Singleton(); // private constructor cannot be called; // no instances can be created. private Singleton() { } // return the same instance to all callers of this method public static Singleton get. Instance() { return unique. Instance; } }

public class Printer { private static Printer unique. Instance = new Printer(); Example private Printer() { } public static get. Instance() { return unique. Instance; } public write(String text) { System. out. println(text); // or something fancier… } }

Important Concepts 1. Why a private constructor? ake you m Could tor nstruc co d? otecte pr the Instantiating the Singleton class directly: compilation error l 2. Only the Singleton class can create instances of itself How can you access the single instance of the Singleton class? get. Instance() is a static method, so accessible through the class name l l Singleton. get. Instance() Provides global access to the instance

Summary Lazy versus eager instantiation l l Lazy initialization: create instance when needed Eager initialization: instance created at load time, before needed l And whether or not it is actually ever accessed Singleton class: encapsulates its sole instance l l Only one instance, has global access Wins over public, global variables l l Retain control of the instance Can ensure just a single instance