OOP PHP Flashcards
What methods should be private in a singleton class and why?
__clone and __construct
This prevents the object from being copied, and multiple instances being created.
Should the singleton class in PHP be marked final?
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.
What are some of the issues with the singleton class?
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).
Is the singleton pattern useful in web development?
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.
The builder pattern is useful for…
more complex objects
The builder pattern allows creation in a …
step by step process
What is one of the major differences between the Abstract Factory pattern and the Builder pattern?
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).
What kind of elements might a HTTP request object contain?
Headers / status codes, page templates, HTML layout etc.
What design pattern would be a good fit for creating a HTTP request object?
Potentially the builder pattern, since it can be a complex object requiring building up in stages.
Why is the abstract factory not suitable for something like a HTTP request object (complex object)?
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.
What step is critical, when using the builder pattern, to ensure the client and the builder are loosely coupled?
Use interfaces
The client should always know about, and expect ‘what’ kind of builder?
An abstract builder (via an interface)
Before creating the concrete builders - what is the most important thing to create?
The Abstract Builder
What’s a good substitute from using the traditional decorator pattern in PHP?
Use traits
What is one draw back to the decorator pattern?
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.
What is the purpose of the decorator pattern?
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)
What is another, looser term for a decorator pattern?
Wrapper.
Is using a switch statement in a factory method and appropriate way to decide which class to instantiate?
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.");
}
}
What is a major difference between the bridge and the adapter patterns?
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).
What is the use case for both the adapter and bridge patterns?
To Abstract the implementation of a system from the components making use of the implementation through the common interface
What is the purpose of the repository pattern?
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.
When would you use a bridge pattern?
When you as a programmer have control of both the application and the subsystem you are producing.
When would you use an adapter pattern?
When you as a programmer do not have control over the subsystem api that you are adapting. (i.e. an outside library).
What pattern is frequently confused with the adapter pattern?
The facade pattern
