OO: Inheritance vs Service [closed] - php

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Class A
{
public function __construct(Foo $foo, Bar $bar, MyCustomType1 $mct)
{
//...
}
//...
public function getFooBarFunction()
{
$this->foo->aMethod();
$this->bar->anotherMethod();
//some other execution here
}
}
Class B
{
public function __construct(Foo $foo, Bar $bar, MyCustomType2 $mct)
{
//...
}
//...
public function getFooBarFunction()
{
$this->foo->aMethod();
$this->bar->anotherMethod();
//some other execution here (same of Class A)
}
}
Class C
{
public function __construct(Foo $foo, Bar $bar, MyCustomType3 $mct)
{
//...
}
//...
public function getFooBarFunction()
{
$this->foo->aMethod();
$this->bar->anotherMethod();
//some other execution here (same of Class B and Class A)
}
}
As you can see this code doesn't respect the DRY principles. I can easily collapse getFooBarFunction() into another class and use that method.
A) Create a SuperClass and migrate getFooBarFunction() into it. I need to replicate __construct() also ($this-> references).
Pros
- quite easy to do
- I can create an interface for MyCustomType(s) and use that into construct in substituion of concrete class(es)
Cons
- what if child class need to add a parameter into construct phase?
- what if I can't group MyCustomType(s) under same interface?
B) Create a SuperClass and use setters to "inject" Foo and Bar objects
Pros
- quite easy too
- I don't need to share constructor
Cons
- what if I forgot to inject parameters? Have I to add additional explicit checks into SuperClass and raise exceptions?
C) Create a SuperClass and let getFooBarFunction() accept Foo and Bar objects
Pros
- quite easy too
- I don't need to share constructor
Cons
- Is really necessary, in that case, inheritance?
D) Create an indipendent class (service?) and let A,B,C instantiate it and use it directly
What's best approach (or the "best practice") and why? There are any others?
UPDATE
Class A, Class B and Class C are some objects that doesn't share any information each others (they represent a Room, a Service, a Supplement). Only common feature is that every class has a relationship with i18n table (each one with his own table). So my getFooBarFunction() is only a function used to retrieve static types (stored somewhere, it's not important) that indicates the type of i18n text (title, description, short name, and so on)
UPDATE2 Real code
private function getTextTypeNameEntity()
{
$text_type_repository = $this->getTextTypeRepository();
$text_type_name_id = $this->container->getParameter('foo_project.text_type.name');
$text_type_name = $text_type_repository->findOneById($text_type_name_id);
return $text_type_name;
}
this function is getFooBarFunction()

Answer 1

Answer for update 2
You say this function only fetches text from an repository by an unique id. Without knowing the complete class this sounds like a code smell. A class should only do one thing and do it well. When you implement features, which are not strictly related, you extend the class over is boundaries. I would change the getFooBarFunction to only provide the text id:
public function getTextId() {
return 'some-awesome-unique-text-id';
}
Original post
When looking at the code you provided I can only see one difference, the MyCustomType. I would type hint a shared interface which implements the signature for each method that can be called (interface basics). This can also be applied to the Foo and Bar classes. By using interfaces you can more easily swap actual class implementations.
You said: "What if I cannot group my custom type under the same interface?". This is tricky and one of the hard things to do with interfaces. Think of interfaces as a contract. If you change the method signatures of a class, but tries to use it in place of another you are guaranteed to run into errors. This will also make your code harder to maintain/read as you will attempt to handle edge cases all over the place. Try to stick with the interface.
You said: "what if I forgot to inject parameters?". First off this should be considered a bug/error and you as developer is responsible, sorry :D
You then later said, "what if I need to pass another parameter during construction?". To me that sounds like a different class all together and should be treated as such. Then if you need another parameter anyway, you can just extend this class and overwrite only the constructor. Something like the following.
abstract class AbstractImplementation {
public function __construct(FooInterface $foo, BarInterface $bar, CustomInterface $custom) {
// Initialize properties.
}
/*
* This could also be declared abstract if each implementation
* is different.
*/
public function getFooBarFunction() {
// Perform basic actions
}
}
class ActualImplementation extends AbstractExample {
public function getFooBarFunction() {
// Perform specific actions
}
}
Then if you need another parameter you can do. This should be considered an edge-case.
class ExtendedImplementation extends ActualImplementation {
public function __construct(Extra $extra, FooInterface $foo, BarInterface $bar, CustomInterface $custom) {
parent::__construct($foo, $bar, $custom);
$this->extra = $extra;
}
}
Hope my thoughts can help you, happy coding!

Answer 2

I would opt for D + interfacing your classes. If getFooBarFunction() has nothing to do with the inner workings of A,B or C and the implementation is always the same in all classes then it shouldn't be a member of those classes. If the code calling A,B and C needs to know, that the method is there I would extract getFooBarFunction() in an interface and implement that in A,B and C. This way, the code outside can be sure the method is always there and is implemented in a working way.