I'm facing the following issue in PHPStorm 9:
Say I have an interface FieldInterface that has some methods:
namespace Acme;
interface FieldInterface {
public function methodA();
public function methodB();
}
then I have an abstract class that implements base functionality of the interface. That abstract class has the user to implement certain methods, let's say it's methodB in our example:
namespace Acme;
abstract class AbstractField implements FieldInterface {
public function methodA() {
// implement methodA
}
public abstract function methodB(); // have the user implement it
}
And finally I have some ready-to-use class StringField:
namespace Acme;
class StringField extends AbstractField {
public function methodB() {
// implement methodB
}
}
At this point everything's going well. But if I add new method in the FieldInterface, PHPStorm does not say that anything is wrong with AbstractField while it's obvious that I should add public abstract function newMethod(); in there. However, it spots the error in StringField class instead.
It could be understood from the point that abstract classes are made for the purpose of extention, but usually you extend the abstract class rather than implement underlying interface. The whole meaning of making abstract class is to save user's time for implementing the interface. So why PHPStorm forces me to implement interface in concrete class rather than forcing me to implement it in abstract class that is explicitly implements the interface.
So I wonder if it is a bug in PHPStorm, or maybe it's done on purpose. Either way, is there any workaround?
That's how it should be, showing an error in the abstract class would be wrong.
In fact, public abstract function methodB(); is redundant because the abstract class already "inherits" this abstract method from the interface as it does not implement it.
The only workaround is to make AbstractField not abstract.
Related
I wonder if it is possible to not implement a method coming from an interface and let child class do it.
For example :
abstract class Foo implements Bar
{
public abstract methodFromBar();
}
And then :
class SubFoo extends Foo
{
public methodFromBar()
{
// Implementation...
}
}
The idea behind this is to simplify development and just specifying that the subclass extends from the main class instead of writing again that the subclass implements the interface.
You don't need to mention the interface method in the parent class at all. If it doesn't implement the interfaces listed, then PHP will require that the subclass fulfills the contract instead. This will work fine:
interface Bar
{
public function methodFromBar();
}
abstract class Foo implements Bar
{
}
class SubFoo extends Foo
{
public function methodFromBar()
{
echo 'Hello world';
}
}
$subFoo = (new SubFoo)->methodFromBar();
// Hello world
See https://eval.in/1016337
If the subclass does not implement the method, you'll receive a message along the lines of
Fatal error: Class SubFoo contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Bar::methodFromBar)
Whether or not you think it's a good idea for an abstract class to implement an interface is probably a discussion for another site.
I currently have an abstract class which i am extending to other controllers. I have a abstract function within the abstract class which takes the value and places it in the __construct.
abstract class Controller extends BaseController {
abstract public function something();
public function __construct(Request $request) {
if (!is_null($this->something())){
$this->global_constructor_usse = $this->something();
}
}
}
My problem is that, on controllers that don't require this abstract function, I am having to place in the empty function.
class ControllerExample extends Controller {
public function something(){
return 'somethinghere';
}
}
Is there anyway to making the abstract function optional, or have a default value?
class EmptyControllerExample extends Controller {
public function something(){}
}
It is not possible to have a abstract method optional, as it is implied in PHP that all abstract methods must have an implementation.
There are legit use cases for optional abstract methods, yes: event handlers, metadata describers, etc. Unfortunately, you'll need to use regular, non-abstract methods with an empty body, and indicate in PHPDoc that they will do nothing unless extended.
Be wary, though: this can very quickly turn into code smell by diffusing a class responsability with their children. If you're dealing with generic events, you can look into Laravel's own event system, or the Observer pattern instead.
Abstract functions in a parent class, should only be used if its required by your application to implement the following method in all controllers who inherits from it, clearly it is not the case.
In this case i would make a trait. Here you create a trait which can be implemented by the classes who needs it. Notice the use keyword usage, use somethingTrait;
trait SomethingTrait
{
public function something()
{
echo "something called";
}
}
class Controller
{
use SomethingTrait;
public function run()
{
$this->something();
}
}
phpfiddle link
Another aproach could be doing a class inheritance structure, if the controllers you want to implement the methods has something in common. Where you would implement your special method in CrmController, where you still would be able to create shared methods in the abstract controller.
AbstractController
|
CrmController
|
CompanyController
For your question, 'Is there anyway to making the abstract function optional or have a default value?' No, and you are down the wrong path if you are trying to make abstract function optional. Hope my suggestions can help.
I'm stuck into a problem with traits I can't solve on my own.
I have classes extending an abstract class (in my case these are several controller classes and an abstract class Controller, the used framework won't be important here, since this is a general PHP question…) that uses traits. I'd like to override a method defined in one of the traits. This only works as long as I define the method in my sub-classes but not in my abstract class.
So, this one works perfectly:
class MyController extends Controller
{
use AnyTrait;
public function anyMethodFromAnyTrait()
{
// override AnyTrait::anyMethodFromAnyTrait()
}
}
I also know how to call the anyMethodFromAnyTrait method from AnyTrait by using as.
class MyController extends Controller
{
use AnyTrait { AnyTrait::anyMethodFromAnyTrait as method }
public function anyMethodFromAnyTrait()
{
// invoke AnyTrait::anyMethodFromAnyTrait()
$this->method();
}
}
Both work like a charm.
But my problem is a bit different.
When using the trait and defining the method in my abstract class I am not able to override the trait's method.
Assume the following controller class:
class MyController extends Controller
{
public function anyAction()
{
// let's see what happens…
$this->anyMethodFromAnyTrait();
}
}
…and the abstract one that's extended by MyController:
abstract class Controller
{
use AnyTrait
public function anyMethodFromAnyTrait()
{
// do something different than AnyTrait
}
}
…And this is what's not working at all. Whenever I call $this->anyMethodFromAnyTrait() within MyController the trait's method as implememented in AnyTrait will be invoked. The same named method in my abstract Controller will be ignored.
Therefore I only can override a trait's method in a concrete sub-class but not in an abstract class that is extended by that sub-class.
So the method definitions in traits get a higher priority by PHP than the same method definitions in abstract classes.
Do you know any workaround for that behaviour?
One workaround would be to use the traits ONLY in the subclasses.
PHP always prefers the trait methods over the "local" ones.
The reason why it works in subclasses is, that the trait method of the superclass is extended, not the trait usage itself.
This might be a silly question. I am trying to create a generic repository interface for Doctrine 2 so I can pass it into my controller through direct injection:
//TestController.php
public function __construct(TestRepositoryInterface $p_repository){
//...
}
The method signature for an EntityRepository in Doctrine2 is as follows:
class EntityRepository implements ObjectRepository, Selectable{
//...
}
EntityRepository is missing a few functions that I would like to have in a repository(Add, Delete, Update). So I created a base repository interface and an abstract repository class to encapsulate those functions:
interface RepositoryInterface {
public function add($entity);
public function delete($entity);
public function update($entity);
}
The abstract repository class extends from EntityRepository so I can still get the functionalities of EntityRepository.
abstract class AbstractRepository extends EntityRepository{
public function add($entity){
//...
}
public function add($entity){
//...
}
public function add($entity){
//...
}
}
To tie everything together, I made TestRepositoryInterface extend from RepositoryInterface, ObjectRepository, and Selectable.
interface TestRepositoryInterface extends RepositoryInterface, ObjectRepository, Selectable{
}
Then I can just pass in an implementation of TestRepositoryInterface through direct injection:
class TestImplementation extends AbstractRepository implements TestRepositoryInterface{
//...
}
Or if I am unit testing, it would be easy to create a mock object or test stub.
My only concern is in TestImplementation class. It extends AbstractRepository which already implements ObjectRepository and Selectable (through EntityRepository), and at the same time TestImplementation also implements TestRepositoryInterface which also extends ObjectRepository and Selectable. So TestImplementation is essentially implementing ObjectRepository and Selectable twice (or is it?). It compiles just fine, but is this a valid approach?
It is perfectly OK for a class to implement multiple interfaces that in turn extend common interfaces. The methods are the same so there are no conflicts.
The only thing you need to worry about is implementing interfaces with same named methods but alternative arguments.
Say you have an interface whose implementations need to be iterated. You would probably have it implement\IteratorAggregate.
Now lets say your implementation class extends ArrayCollection (from doctrine common). Because ArrayCollection also implements IteratorAggregate it take care of some of your own interface's definitions for you.
When it comes to mixing interfaces, look for issues with compatibility rather than inheritance.
I am studying the differences between Abstract and Interface and I read some sentence
saying
A child class can only extend a single abstract (or any other) class,
whereas an interface can extend or a class can implement multiple
other interfaces.
I understand when he says, “A child class can only extend a single abstract (or any other) class,” he means:
class first
{
public function Search()
{
return 'Hellow';
}
}
abstract class first2 extends first
{
}
class second extends first2
{
}
$ob = new second();
echo $ob->Search();
However, I didn’t understand the rest of his sentence, where he says, “whereas an interface can extend or a class can implement multiple other interfaces.”
Could someone please explain his last sentence and add a code example?
Thank you all and have a nice day.
You can implement more than one interface
interface C {
public function method1();
}
interface D {
public function method2();
}
class A implements C,D {
//implement from interface C
public function method1() {
}
//implement from interface D
public function method2() {
}
}
Here you will need implement methods from interface C and D. You can also extend interfaces within interfaces, like normal classes.
interface D extends C{}
It's useful when well you need some common methods. so you write "schema" into interface what methods you are expecting from base class to be implemented.
While abstract is single extended class, you canot create instance for it, only extend. It's useful when you want have some base class with common functionality or abstract methods what should be implemented later.
More you can always read at php.net - interfaces