I want to implement next fragment of diagram, using PHP.
See composition example diagram below:
We can implement composition in Java using inner classes.
But there is no analog of "inner class" in PHP.
Of course, there are traits. But we can use it in more than one class.
I've implemented composition like this:
class Head {
private static $instance = NULL;
private function __construct(){}
public static function getInstance() {
$traces = debug_backtrace();
if (strcmp($traces[1]['class'], 'Human')) {
echo "<br>Only human has head"; // Exception can be thrown here
return NULL;
}
if (!static::$instance) static::$instance = new self();
return static::$instance;
}
public function __toString() {
return 'Head';
}
}
class Human {
private $head;
public function __construct() {
$this->head = Head::getInstance();
}
public function __toString() {
return 'I have ' . $this->head;
}
}
class Plant {
private $head;
public function __construct() {
$this->head = Head::getInstance();
}
}
$human = new Human();
echo $human;
$superman = new Plant();
Is it right to do so?
Is there better way to implement composition relationship in PHP?
It looks like you are really confused about what "composition" is in OOP.
Composition is an association between two classes, where , for an instance of first class to be instantiated, it is mandatory to provide it with second class. In you particular diagram for Human to exists, it requires a Head. In code it would be:
class Head {
}
class Human {
private $head;
public function __construct(Head $head) {
$this->head = $head;
}
}
$bob = new Human(new Head);
And that's it. No debug_backtrace() and no singleton anti-pattern required. And, btw, this would look almost exactly the same in Java too, even with the option to have inner classes.
As for your posted code. This would be wrong:
if (strcmp($traces[1]['class'], 'Human')) {
echo "<br>Only human has head"; // Exception can be thrown here
return NULL;
}
The diagram did not say that only humans have a head. Only that human must have a head to be instantiated. You can also have $skipper = new Dog(new Head);, which would be perfectly fine.
Composition over inheritance.
Basically composition is a stronger form of aggregation. We could say that relationship between body and head is composition because we can not live without head but relationship between body and a hand is aggregation because we could lose our hand but we can stay alive. There are also weaker relations like direct association and temporary association.
Dependency injection however is just a pattern in which we create those associations (by injecting one class in to another).
In most cases you could recognized composition relationship by constructor which inject another object and assign it to its property and life cycle of object ends and start in the same moment.
Other than that from technical point of view there is not much difference between implementation of each association. It is mostly matter of relation definition rather than implementation.
Composition relation is often used to overwrite/change or enhance injected object class behavior. Don't get too excited or worried about composition. In most cases, the advantages versus inheritance are small, and are most enjoyed by third-party library creators, who use composition to add extra flexibility to their libraries.
Inheriting from parent class and overloading/adding methods gives us similar functionality, but with composition we get more flexibility. For example if our constructor accept object that inherit from Head interface we can use HumanHead class if it extends Head interface but we could also use our class to enhance other creatures which extends from same interface like DogHead or DuckHead...
This is perhaps not the best example but it shows the basic concept.
Be sure to check this [Aggregation vs Composition vs Association vs Direct Association] and this [Association-Aggregation-Composition-Dependency].
Related
First file:
class Class_one {
public function __construct() {
}
public function show_name() {
echo "My Name is Siam";
}
public function show_class() {
echo "I read in class 7";
}
}
Second file:
<?php
require_once './Class_one.php';
class Class_two {
public $class_one;
public function __construct() {
$aa = new Class_one();
$this->class_one = $aa;
}
public function history() {
$this->class_one->show_name();
}
}
$ab = new Class_two();
$ab->history();
What will happen if i don't instantiate class_one in class_two and extend class_one into class_two? Is there any difference?
There's only one potential gotcha here: Class_two won't have direct access to Class_one private/protected methods and variables. That can be a good thing (encapsulation is where a class does some specific task and you don't want children to interfere with it), but it can also mean you can't get to the data you need.
I would suggest you do Class_two as a dependency injection (as shown in your example), however
class Class_two {
public $class_one;
public function __construct(Class_one $class) {
$this->class_one = $class;
}
}
It should be a semantic difference:
You use inheritance when relationship between two classes can be expressed with to be verb. For example: My Ford is a Car
You use association/composition when relationship between two classes can be expressed with to have verb. For example: My car has an engine.
Above rules should be the first consideration when choosing inheritance or association in object-oriented programming. There've been always discussion about avoiding inheritance, and some will argue that you should choose composition over inheritance. See this other Q&A: Prefer composition over inheritance?
In terms of pure coding, as #Machavity on his answer has already said, there could be accessibility limitations when using composition instead of inheritance, but I wouldn't decide which approach to use based on member accessibility.
I have a question concerning "unit tests" and object-inheritance. For example:
I have a class A which extends class B. Let's assume the only difference of the two classes is the add method . In class B this add method is slightly extended. Now I want to write a unit test for the add function of class B but because of the parent::add call I have a dependency to the parent class A. In this case I can't mock the add method of the parent class so the resulting test will be a integration test but if I want it to be a unit test? I don't want the the test for method add in class B fails because of the parent method in class A. In this case only the unit-test of the parent method should fail.
class B exends A
{
public function add($item)
{
parent::add($item);
//do some additional stuff
}
....
}
class A
{
protected $items = [];
public function add($item)
{
$this->items[] = $item;
}
....
}
Surely I could use object-aggregation and pass my parent object to the child contructor and therefore I would be able to mock the parent method add, but is this the best approach? I would rarely use object-inheritance anymore.
class B
{
protected $a;
public function __contruct(A $a)
{
$this->a = $a;
}
public function add($item)
{
$this->a->add($item);
//do some additional stuff
}
....
}
class A
{
protected $items = [];
public function add($item)
{
$this->items[] = $item;
}
....
}
I would be very grateful for your opinions. Thanks!
Ask yourself, what kind of inheritance do you want to achieve? If B is a kind of A, then you're wanting interface inheritance. If B shares a lot of code with A, then you're wanting implementation inheritance. Sometimes you want both.
Interface inheritance classifies semantic meaning into a strict hierarchy, with that meaning organized from generalized to specialized. Think taxonomy. The interface (method signatures) represent the behaviors: both the set of messages to which the class responds, as well as the set of messages that the class sends. When inheriting from a class, you implicitly accept responsibility for all messages the superclass sends on your behalf, not just the messages that it can receive. For this reason, the coupling between super- and sub-class is tight and each must strictly substitute for the other (see Liskov Substitution Principle).
Implementation inheritance encapsulates the mechanics of data representation and behavior (properties and methods) into a convenient package for reuse and enhancement by sub-classes. By definition, a sub-class inherits the interface of the parent even if it only wants the implementation.
That last part is crucial. Read it again: Sub-classes inherit the interface even if they only want the implementation.
Does B strictly require the interface of A? Can B substitute for A, in all cases matching co-variance and contra-varience?
If the answer is yes, then you have true sub-typing. Congratulations. Now you must test the same behaviors twice, because in B you are responsible for maintaining the behaviors of A: for every thing A can do, B must be able to do.
If the answer is no, then you merely need to share the implementation, test that the implementation works, then test that B and A separately dispatch into the implementation.
In practical terms, I avoid extends. When I want implementation inheritance, I use trait to define static behaviors † in one place, then use to incorporate it where needed. When I want interface inheritance, I define many narrow interface then combine with implements in all the concrete types, possibly using trait to leverage behavior.
For your example, I'd do this:
trait Container {
public function add($item) { $this->items[] = $item; }
public function getItems() { return $this->items; }
private $items = [];
}
interface Containable { public function add($item); }
class A implements Containable { use Container; }
class B implements Containable {
use Container { Container::add as c_add; }
public function add($item) {
$this->c_add($item);
$this->mutate($item);
}
public function mutate($item) { /* custom stuff */ }
}
Container::add and B::mutate would have unit tests, while B::add would have an integration test.
In summary, favor composition over inheritance because extends is evil. Read the ThoughtWorks primer Composition vs. Inheritance: How To Choose to gain a deeper understanding of the design trade-offs.
† "static behaviors", you ask? Yes. Low-coupling is a goal and this goes for traits. As much as possible, a trait should reference only variables it defines. The safest way to enforce that is with static methods that take all their input as formal arguments. The easiest way is to define member variables in the trait. (But, please, avoid having traits use member variables that are not clearly defined in the trait -- otherwise, that's blind coupling!) The problem, I find, with trait member variables is that when mixing in multiple traits you increase the chance of collision. This is, admittedly, small, but it is a practical consider for library authors.
I'm a bit lost here because I want to do something that is very easy in Java but seems a bit complicated in PHP.
We are building an SDK for our product and in Java, we have this one class that must not (!) be instantiated by the user (i.e. the coder), since there are several constraints regarding it's integrity. So we've built that as a nested class "X" inside of the "XFactory" and you will get an instance of X by calling XFactory.buildMeMyX(); - Easy...
Now PHP does not support nested classes at all, and I wonder how to apply the same here. In Java, X's constructor is hidden (private), so only XFactory can call it.
In PHP, it looks like I will have to make __construct() public and move the nested class X out of XFactory. Hence, the user will be able to create an instance without the Factory.
Now - I COULD move the factory functionality to X itself and move all the stuff there, but this would kind of break the design of the SDK. Is there a useful way to do such things in PHP after all?
For PHP 5.x you already described your options, there are no private/protected classes or inner classes at all, so there is no further way to restrict instantiation.
However, with PHP 7 this is going to change.
There are still no nested classes (although we might get them in the future, see: https://stackoverflow.com/a/31454435/664108), but you could instantiate an anonymous class and only provide the consumer with its interface like this:
class XFactory
{
public function buildMeMyX()
{
return new class() implements XInterface {
public function doWhatEverAnXCanDo()
{
// X X X
}
// ...
};
}
}
interface XInterface
{
function doWhatEverAnXCanDo();
}
As the others have said, there currently is no clean way to implement this behavior in PHP. In my opinion, the only valid use case for private constructors are factories inside the class that implement that factories.
Whenever you try to get around that use case it gets messy. No one should ever try to invent clever ways to bypass PHP's language limiations.
I just violated that rule by myself just to prove it is indeed possible. But please refrain from using that in production, or better: using it anywhere. I will try to find some bulletproof arguments for that suggestion and edit the answer afterwards.
<?php
class Dependency {}
class SomeClass {
protected $dep;
private function __construct(Dependency $dep)
{
$this->dep = $dep;
}
public function doSomething()
{
var_dump($this->dep);
echo "Doing Stuff and even having dependencies";
}
}
class SomeClassFactory {
public function buildSomeClass()
{
return $this->instantiateSomeClassWith(new Dependency);
}
protected function instantiateSomeClassWith()
{
$reflectionClass = new ReflectionClass('SomeClass');
$someClass = $reflectionClass->newInstanceWithoutConstructor();
$constructor = $reflectionClass->getConstructor();
$constructorClosure = $constructor->getClosure($someClass);
call_user_func_array($constructorClosure, func_get_args());
return $someClass;
}
}
$factory = new SomeClassFactory();
$someClass = $factory->buildSomeClass();
$someClass->doSomething();
?>
Output: object(Dependency)#2 (0) { } Doing Stuff and even having dependencies
The theory is simple. The constructor of the class that will be built via the Factory is made private. We make use of reflection within the factory to create an instance of the class without invoking the constructor.
Once we have an instance, we grab the closure of the constructor and invoke it via call_user_func_array(). That way you can make use of Dependency Injection just as you would if the constructor was public.
As I said before. That way is a single smell. By creating an object without invoking it's constructor, there is no real way to validate an objects state upon creation
This is a proof of concept, but the concept sucks.
There is no native way to do so, yet. However, if you really want to "enforce" that your class is only created from your factory class, there is a little "hackish" way to do so limiting the instantiation by inistantiating class.
class X
{
function __construct()
{
new Y();
}
}
class Y
{
function __construct()
{
$trace = debug_backtrace(DEBUG_BACKTRACE_PROVIDE_OBJECT, 2);
if (!isset($trace[1]['object']) || !($trace[1]['object'] instanceof X)) {
throw new \RuntimeException('This is a private class');
}
}
}
new X(); // All is fine
new Y(); // Exception
Please note that there is no "real" way to protect the class from being instantiated from elsewhere even using this approach - it still can be done via reflection by bypassing the constructor, or simply modifying your source.
I want to disable a class to be instantized by new operator, but lets suppose a getObject method what creates and returns an instance of it. Is it doable?
class C
{
protected function __construct()
{
}
public static function getObject()
{
return new self();
}
}
UPDATE:
The code above fulfills the requirement: the class cannot be instantiated using new, one needs to use the factory method getObject() to create an object. However, the OP did not specify the reason they need such a construct.
There are several reasons such a design emerges; one of them is when the creation of objects of type C needs to be completed with some initialization that, for whatever reason, cannot be done in the class' constructor.
Another reason for this way of constructing objects of class C is the Singleton design pattern; which in fact is an "anti-pattern", but this is another discussion; in order to implement a Singleton, class C should look like this:
class C
{
private static $instance = NULL;
protected function __construct()
{
}
public static function getObject()
{
if (! isset(self::$instance)) {
self::$instance = new self();
}
return self::$instance;
}
}
Singleton or not, because method getObject() is static it cannot be stubbed or mocked by the test frameworks and its original implementation have to be used. More, because it is the only way to create objects of class C, other classes that use this class cannot be tested in isolation.
All in all, even the construction is possible, it is not recommended. Enforcing the creation of objects of class C using language mechanisms made the class a nuisance for testing other classes that use it.
If the creation of objects of class C needs to be done by a certain method because of its complex initialization, a better way is use the Builder design pattern. Make it a non-static method of another class (the "builder") and instruct the programmers (using the class documentation) to not create objects of class C directly, using new. This way it does not affect the testability of other classes.
I want to disable a class to be instantized by new operator
A common approach is to privatize the constructor.
class Example {
private function __construct() {
}
}
The following would result in a fatal error.
$object = new Example();
While this will work, I would encourage you, and future readers, to review Design Patterns in PHP.
I'm writing a bunch of classes in PHP for the server-side portion of a website we're developing. The classes look something like this:
class SomeEntity {
// These fields are often different in different classes
private $field1 = 0, $field2 = 0, ... ;
// All of the classes have one of these
static function create($field1, $field2) {
// Do database stuff in here...
}
// All of the classes have similar constructors too
function __construct($id_number) {
// Do more database stuff in here...
}
// Various functions specific to this class
// Some functions in common with other classes
}
The issue is there are a lot of these classes and they all need to have similar constructors and a few common functions, so I'd ideally want to write a superclass to handle all this stuff so that there's minimal copying/pasting going on. However, each of the subclasses has different instance variables and parameters, so what would the best way to design the superclass be?
(To phrase it perhaps slightly better, how can write a constructor function or other functions that do stuff with the instance variables of the class but without necessarily knowing what the class' instance variables are and hard-coding them by name?)
You can go quite a ways towards a very generic "Entity" type class, especially is you leverage the various magic methods.
Consider class like this (just some random convenience methods for entity-like classes to share):
<?php
abstract class AbstractEntity {
protected $properties;
public function setData($data){
foreach($this->properties as $p){
if (isset($data[$p])) $this->$p = $data[$p];
}
}
public function toArray(){
$array = array();
foreach($this->properties as $p){
$array[$p] = $this->$p;
//some types of properties might get special handling
if ($p instanceof DateTime){
$array[$p] = $this->$p->format('Y-m-d H:i:s');
}
}
}
public function __set($pname,$pvalue){
if (! in_array($pname,$this->properties)){
throw new Exception("'$pname' is not a valid property!");
}
$this->$pname = $pvalue;
}
}
<?php
class Person extends AbstractEntity {
protected $properties = array('firstname','lastname','email','created','modified');
}
Basically, you separate anything you repeat into either a parent class, or a helper class.
If it's a common activity that relates to the object, and would apply to similar objects, you put that in a parent class and inherit from it. If the children of this parent have similar members/properties but are named differently for whatever reason, you just write the method to accept parameters then pass the different property names in the call to that method.
If it's a common activity that relates to the object, and only that object, it becomes a method in the child class which needs it.
If it's a common activity that doesn't relate to the class in question, then you create a new class that manages things relating to that activity, and write a public method in that class that your other classes can call.