• Nem Talált Eredményt

The Factory Method

In document Programming Technologies (Pldal 51-54)

6. Creational design patterns

6.3. The Factory Method

static void Main(string[] args) {

//creating the prototype of the sportscar and the truck

Car prototype1 = new SportsCar("Aston Martin", 4, 180, 220);

Car prototype2 = new Truck("Csepel", 3, 200, 1000);

Factory prod_queue = new Factory();

// makes 10 red SportsCar

Car[] vk = prod_queue.manufact(prototype1, “Red", 10);

foreach (SportsCar v in vk) { Console.WriteLine(v); } // makes 20 gray trucks

Car[] tk = prod_queue.manufact(prototype2, “Gray", 20);

foreach (Truck t in tk) { Console.WriteLine(t); } Console.ReadLine();

} }

6.3. The Factory Method

With this pattern, we can replace the many similar „new‟ commands in our program. The patterns describe how to make a creator function. In English, we often start with the „create‟ word (“készít” in Hungarian). The creator function returns the product given in its name, so the createDog returns a dog and the createCat returns a cat.

This is better than the „new Dog()‟ or „new Cat()‟ constructor call, because we can encapsulate the algorithm of creation. The advantage of this is if the procedure of creation changes, we only need to change it at one place.

The procedure of creating rarely changes, the question is often what needs to be created. This changes often, so according to the OCP principle, the child class will decide it.

So the creator method in the parent describes the algorithm of the creation, while the child class decides what exactly needs to be created. To attain this, the algorithm has three kinds of steps:

• The common steps of the creation: These are concrete methods in the parent; usually they are not virtual (or not final in JAVA).

• The obligatory changing steps of the creation. These are abstract methods in the parent that the child overwrites to decide what to create. This is the point where the child classes call the product‟s constructor.

• The optional steps of the creation: These are „hook‟ methods in the parent, namely, the method has body, but it‟s empty. These can be overwritten without breaching the OCP principle to describe the optional steps.

The „New‟ menu option in the applications of the Office package is a good example for the creator method. This creates and opens a new document for every application. The opening is the same, but the creation is different in every case. In the case of the word processor, a new text document is created, while in the case of the spreadsheet application, a new spreadsheet is created.

It is interesting to note that the abstract parent and its child classes are in an IOC (inversion of control) relationship. Namely, it‟s not the child that calls the methods of the parent, but the parent is the one to call the

child‟s. To attain this, the creator function calls abstract and virtual methods, When we will call the creator methods through the child class‟ instance, then - due to the late binding - instead of these methods, the ones that overwrites them in the child will run.

6.3.1. Source code

using System;

abstract class Qualification Factory {

public Qualification createQualification() {

// before manufacturing, this-and-that, like logging, can be done here return Qualifying();

}

public abstract Qualification Qualifying();

}

class ConcQualifFactory1 : QualificationFactory {

public override Qualification Qualifying() { return new A_ Qualification(); } }

class ConcQualifFactory2 : Qualification Factory {

public override Qualification Qualifying() { return new B_ Qualification (); } }

interface Qualification { void Qualifying(); } class A_ Qualification : Qualification {

public void Qualifying() { Console.WriteLine(“Qualified A!"); } }

class B_ Qualification : Qualification {

public void Qualifying() { Console.WriteLine(“Qualified B!"); } }

class Program {

static void Main(string[] args) {

QualificationFactory[] qualifier = new QualificationFactory[2];

qualifier[0] = new ConcualifFactory1();

qualifier[1] = new ConcQualifFactory2();

foreach (QualifFactory q in qualifier) {

Qualification qual = q.ceateQualification();

qual.Qualifying();

}

Console.ReadLine();

} }

6.3.2. UML figure

Figure 5 : The Factory method design pattern

6.3.3. Practice exercise

Make a source code according to the description below. Use the Factory Method design pattern for the solution!

Exercise

This morning, one of our programmers, who is usually completely sane, came out with the idea to wipe out the

„new‟ keyword from our codes. At first, we thought that he hadn‟t drunk his coffee yet and he‟ll recover after one, but then we gave it another thought. Now, what does „new‟ mean for us? It means we bind ourselves to a

concrete class, which is not a problem until we think of the magic phrases: “program on interface” and “open to changes, closed to modifications”. The latest order, in which we need to work on a greased-bread franchise network, just came handy to try our new ideas. The wrapping must be the same on country-level, but the bread is sliced to different thickness in every county, there is a difference even between Pest and Buda, and we haven‟t talked about the different greases: goose-grease, duck-grease and the like. We create two abstract classes, one for the shop (factory) and one for the product (interface). In this case, this will be the Greased_Plank. We wrote up the wrap function in the shop to achieve the same wrapping, but we made the function of creation to be abstract. In brief, we entrust the thickness of the bread and the type of grease on the concrete shop. We created the other class for the product. Now, what does a Greased Plank need? Bread, grease, salt, onion - but even for bread, we can list at eight for the first try. So a shop (factory) in Nyíregyháza can make greased bread of its own style. If we need to make greased bread in Kecskemét, our code will look something like this: Greased_Plank greased_bread = KecskemetShop.createGreased_Bread();

In document Programming Technologies (Pldal 51-54)