OOP PHP

Question 1

What methods should be private in a singleton class and why?

Answer 1

__clone and __construct

This prevents the object from being copied, and multiple instances being created.

Question 2

Should the singleton class in PHP be marked final?

Answer 2

No, not necessarily. There are legitimate reasons (such as adding functionality) to leave the class as ‘not final’. However, you have to be careful to not violate the principles of the design pattern as a result of the PHP limitations.

Question 3

What are some of the issues with the singleton class?

Answer 3

It is impossible to extend (if implemented correctly)

Being global, it’s difficult to test because changes made to the single are reflected across all tests, not just the area under test

PHP allows the developer to redeclare the __construct and __clone methods as public in a child class (which breaks the whole concept of a singleton

Violates many of the SOLID principles - creates itself, so can’t abstract that away (Single Responsibility Principle). It can’t be swapped with a subclass of itself (Liskov Substitution principle).

Question 4

Is the singleton pattern useful in web development?

Answer 4

Generally - no. It seems to have few real, legitimate uses.

However, it could be part of the Registry pattern (to make sure you only have one Registry), or you could use it for configuration / or preferences object. But there are probably better uses.

Question 5

The builder pattern is useful for…

Answer 5

more complex objects

Question 6

The builder pattern allows creation in a …

Answer 6

step by step process

Question 7

What is one of the major differences between the Abstract Factory pattern and the Builder pattern?

Answer 7

The Builder Pattern only returns the object to the client when the client asks for it (i.e. it may be sometime AFTER the object has begun creation).

Question 8

What kind of elements might a HTTP request object contain?

Answer 8

Headers / status codes, page templates, HTML layout etc.

Question 9

What design pattern would be a good fit for creating a HTTP request object?

Answer 9

Potentially the builder pattern, since it can be a complex object requiring building up in stages.

Question 10

Why is the abstract factory not suitable for something like a HTTP request object (complex object)?

Answer 10

Abstract Factory expects the configuration and settings to be injected when the client commands the factory to create the object. This is usually not possible in more complex objects such as a HTTP request object.

Question 11

What step is critical, when using the builder pattern, to ensure the client and the builder are loosely coupled?

Answer 11

Use interfaces

Question 12

The client should always know about, and expect ‘what’ kind of builder?

Answer 12

An abstract builder (via an interface)

Question 13

Before creating the concrete builders - what is the most important thing to create?

Answer 13

The Abstract Builder

Question 14

What’s a good substitute from using the traditional decorator pattern in PHP?

Answer 14

Use traits

Question 15

What is one draw back to the decorator pattern?

Answer 15

The decorator pattern creates objects that use a common interface, however, depending on whether the object is the concrete object or the decorator, the objects behave differently. I.e. a user needs to know that passing a concrete decorator object to another decorator object will be syntactically correct (due to shared interfaces) but will certainly not give the expected results.

Question 16

What is the purpose of the decorator pattern?

Answer 16

To add additional functionality or formatting to an existing interface. Typically by taking a reference to an object, providing a new object with the same interface that adds functionality around, or in, the result of the first object.

(i.e. takes a string object, adds formatting before and after to make it bold, before printing it out)

Question 17

What is another, looser term for a decorator pattern?

Answer 17

Wrapper.

Question 18

Is using a switch statement in a factory method and appropriate way to decide which class to instantiate?

Answer 18

Yes - it does work, but in a system where the number of objects may grow ridicuously large, you would be better using something dynamic:

public static function build($product_type, $sku, $name)
{
$product = “Product_” . ucwords($product_type);

  if(class_exists($product))
  {
    return new $product($sku, $name);
  }
  else {
    throw new Exception("Invalid product type given.");
  }
}

Question 19

What is a major difference between the bridge and the adapter patterns?

Answer 19

The bridge pattern is used typically when you are designing the systems (i.e you are implementing the bridge pattern, because you understand the potential for growth in this system). The adapter on the other hand is implemented when you are trying to get two systems to talk that you do not have control over (i.e. didn’t write).

Question 20

What is the use case for both the adapter and bridge patterns?

Answer 20

To Abstract the implementation of a system from the components making use of the implementation through the common interface

Question 21

What is the purpose of the repository pattern?

Answer 21

It provides a single point of entry for an application to request data from persistence (db etc). This is very useful in large products where there may be a requirement at a later date to change databases. By using a repository, rather than sprinkling access to the DB through the code, you can easily update the requests in one place - and switch out the original db.

Question 22

When would you use a bridge pattern?

Answer 22

When you as a programmer have control of both the application and the subsystem you are producing.

Question 23

When would you use an adapter pattern?

Answer 23

When you as a programmer do not have control over the subsystem api that you are adapting. (i.e. an outside library).

Question 24

What pattern is frequently confused with the adapter pattern?

Answer 24

The facade pattern

Question 25

What is the primary deciding factors between whether a facade or adapter pattern is used?

Answer 25

If the interfaces are similar - then it is likely an adapter pattern can be used to create a standardised interface for your application. A facade on the other hand wires together two very different interfaces - while trying to bring them together in a unified fashion.

Question 26

In an adapter, there are commonly four distinct parts - what are they?

Answer 26

The client - object that talks to the adapter
The target (the interface the client understands)
The Adapter (implements target interface, and holds reference to the adaptee)
The Adaptee (the object we are adapting for)

Question 27

What is the basic difference between a Factory and an Abstract Factory pattern?

Answer 27

A factory pattern creates implementations of a particularly interface (i.e. Apple, Banana), say IFruit.

With an abstract pattern, you create implementations of a particular factory interface - IFruitFactory, which knows how to create each of those different kind of fruit.

Question 28

In an adapter, the information flows in which direction?

Answer 28

Both directions, although control is usually from one direction.

Question 29

What is the purpose of the facade pattern?

Answer 29

It has a couple of purposes, namely - to simplify the interface to a 3rd party library or application, make it easier to understand, and reduce the dependencies between an application, and another applications/libraries interfaces.

The facade wraps the knowledge of how to obtain specific information from the 3rd party, and then the client application delegates to that facade.

This reduces coupling between the applications, and allows for easier changes to the applications interfaces.

Question 30

How is the facade pattern related to the gateway pattern?

Answer 30

The gateway pattern is simply a facade that connects an application to a persistance layer.

Question 31

When would be a good time to use the facade pattern?

Answer 31

For instance - if an application has a complex business logic module, that must be accessed from multiple parts in the code (perhaps calling many methods in that module, and combining the output in some way) - by using a facade you can create a simpler interface and have all clients that need that business logic use the facade. This makes later changes very easy (as it’s only in one place).