I'm working on a PHP library and I have two classes.
First one is like this:
/**
* #method static A getInstance()
*/
interface A {...}
Second one is like this:
class B implements A {...}
getInstance is not defined in A, except in PHPDoc above class. Now, my IDE (PHPStorm) suggests an error, saying that I should implement getInstance in B.
My questions are:
Why they put this method in PHPDoc even though it's not declared in the interface? I doubt it's a mistake, since they used the same comment in many other classes.
What do you recommend? should I implement in B or should I remove the PHPDoc comment from A?
I think it's the mistake because any of the classes which implement OW_Storage interface don't implement getInstance() method. You can make sure it with help search. It means this function isn't used.
You can remove the doc block from the interface but right way is to do pull-request in origin repository.
Related
Recently I got someones PHP site project (and this someone don't wan't to help me), so I have to understand his code. And maybe my answer would be stupid, but...
But there's some methods before class, that are doxumented as in example:
namespace Base\Classes;
/**
* #method int method1()
* #method $this method2(int $parameter)
*/
class SomeClass extends ParentClass
{
public $_s_a = false;
public $_user_roles = [];
public function SomeClassMethod() {
somethingDone();
}
}
And as you can see in this example, these documented methods are not implemented in defined class. But what my question is about - this methods are called from another classes and templates. And PHPStorm (my IDE) connects this documentation lines with calls, and ctrl+B leads from between references. But I can't find exact implementation of this methods. They cannot be found in parent classes, they are not in this file. And I thought maybe this is some syntax sugar that I'm not familiar with. Am I right? Or there something I'm missing, and all implementations somewhere in another place? (search by method name in folder gives nothing for me)
PHP has a few magic methods, and one of them is __call().
When you have an object that implements __call() (by itself or by one of the parent classes), you may call an inaccessible method on it, and the __call() method will be called instead. This happens, for example, when you call a private method from the outside, or when you call a method that was not defined in code.
When you use such calls to inaccessible methods, IDEs will most likely show a warning that the method does not exist, although the code itself will probably work at runtime. These warnings are quite annoying, so you can add a #method tag to your class, and the IDE will know that this method exists, and will not show a warning.
So, to support the code that you got from someone, take a look at the __call() method implementation. Be aware that this method may be implemented in one of the parent classes, so check them out as well.
Can anyone give me an example of the following desired OOP structure please.
I want a main class (super class) (interface or abstract class?) where all the other classes that are extending from it can have their functions called from instances of the main super class.
e.g.
class mainSupoerClass() {
}
class doWork exends mainSupoerClass(){
public function addEntity(){
//do stuff for entity
}
}
I want be able to do this:
$data = new mainSupoerClass;
$data->addEntity(); (doesnt belong to this class but its fetching the function from doWork class)
Can anyone give me a start on the correct OOP structure to carry out this work?
In simple terms, you can't. You have to instantiate the extended class and you'll get all functions within the instantiated class and also the parent class/classes.
Is there any reason you need this to be done this way?
That won't work the way you describe it. PHP (nor any other language) can know which derived class you refer too. It would work if you instantiate doWork instead of mainSupoerClass.
I think you are looking for the factory pattern, but I'm not sure.
With that pattern, you build an interface (either an interface or an abstract class), and let a factory instantiate any descendant of that class.
Now your code doesn't need to know which instance it is, because it can call any method declared in the interface/abstract base class.
An interface is more flexible in this regard. If you create an abstract class, you will need to derive all other classes from that class. Usually this won't be a problem, but sometimes you want a whole new implementation. In that case, an interface is better. You can implement the interface in a completely different class, and still make use of PHP's typehinting for validating that any object you pass to a function or method implements the interface.
Even it's called super-class, it does not mean that it has all classes defined elsewhere. The methodology is the following:
[super] --> [concrete]
and not
[concrete] --> [super]
So a concrete class extends the superclass. The concrete class will then have everything of the superclass plus what the concrete class has / overwrites - but not the other way round.
class Super
{
public function a() {}
}
class Concrete extends Super
{
public function b() {}
}
Super has ::a() and in addition Concrete has ::b(). But Super will never have ::b().
Additionally even you have multiple classes, there is always one instance regardless of how many classes it is compound of, commonly called object:
$object = new Concrete;
This makes a Concrete object.
You'll have to read. Try these:
Article: http://sourcemaking.com/design_patterns/abstract_factory
Code: http://sourcemaking.com/design_patterns/abstract_factory/php/2
It appears that the factory design pattern is what you are looking for.
I don't understand why you wanted to be able to do:
(doesnt belong to this class but its fetching the function from doWork class)
What's the reason behind it?
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Interface vs Abstract Class (general OO)
EDIT:
I just read the questions and answers to the questions from "possible duplicate" and I feel really sad that someone considers these two questions even similar... but, oh well...
-------------------------------------------------------------------------
Hello everyone,
I am trying to understand something about Interfaces in OOP paradigm.
I know the difference between abstract class and interface, I also know that interfaces basically allow easy multiple inheritance behaviour and design, but what I don't get is the "principle of promise". I mean, interface should be a promise that a class implementing an interface has all interface methods implemented.
What I don't understand is do we have to check if class implements interface with instanceOf every time we call its methods? Without reading documentation you have no idea some class implements interface. And if you read the code than you can see yourself that there is that method defined and you can call it?!
If I have
case A.
class Ball{
function kick(){...};
}
or
case B.
interface Kickable{
function kick;
}
class Ball implements Kickable{
function kick(){...};
}
the only difference is that in case A I'll get an error when calling a method that it doesn't exist ("in runtime") and in case B I'll get this error when trying to run the code while trying to "compile". Runtime and compile are definitely used wrong here (PHP environment).
I remember in Java there was a Runnable interface which enables threading. Why do we have to implement an interface Runnable and then define run() method in that class? I mean, class could have a Run method without implementing an interface and there are means to check if class has a special method defined. Ok, maybe my Java part of question is a bit confusing :)))
I'm sorry for such a confusing question, but I hope someone went through these problems in understanding and that now he can share his conclusion :)
Thanks,
Luka
You've already named most of the benefits of interfaces in your question, namely:
they allow for multiple (interface) inheritance
You also mention that you know the difference between abstract classes and interfaces. Therein lies another benefit of using interfaces:
Any class can implement an interface, whereas not any class can derive from an abstract class
This is basically a re-hash of the first point above, but it puts it in a perspective that you might not have considered before. Take your Java Runnable example: If Runnable was an abstract class, then any and every class that implements threading would need to inherit from it. That would lead to extremely inflexible code in the end, as you'd not be able to inherit from any other base class. However, since Runnable is an interface, you can have any class implement it (regardless of what base class it may inherit from).
I understand your concern about having to check if a class implements an interface - unfortunately in a weakly typed language you will have to do that, especially since PHP type hinting hasn't totally come into its own yet.
In a strongly typed language, like Java, you generally don't have such concerns, as you will get a compile-time error if you call an interface method on a class that doesn't implement the interface (or doesn't implement the specific method).
No. You haven't to use instanceof. That's for run-time type checking.
If you want to ensure that you are using a class that implements that interface simply put the interface type in your method signature. For example
public interface yourInterface{
public void foo();
}
public class yourClass implements yourInterface{
public void foo(){} //you need to implement this method, otherwise it won't compile
}
public class anotherClass{
public void bar(yourInterface object){} //you can pass any object to "bar" method if the object implements yourInterface. yourClass object will be fine
}
Then some other nice things you can do, depends on your language. For example with java you can force a generic type to implement a given interface, allowing generic programming:
class generiClass<T extends yourInterface>{
public void genericMethod(T object){} //you can use a generic T class, but T needs to implement yourInterface
}
The reason of interfaces are mainly 2:
force a class to implement some methods
Allow multiple inheritance like features in language without multiple inheritance (in language like C++, where you have multiple inheritance, you don't need an interface. Or saying it better, interfaces are quite the same thing of a pure abstract class)
"I also know that interfaces basically allow easy multiple inheritance behaviour and design"
I think you misunderstood that part. Interfaces allow you to ensure that a particular class has a set of properties/methods.
Example:
function foo($obj) {
$obj->bar(); // fails with foo(array());
}
vs:
interface foobar {
function bar();
}
function foo(foobar $obj) { // $obj *must* have a bar() method
$obj->bar();
}
I am using php 5.3, and yes, there is a bug open for that, but some think this is not a bug, and this makes me wonder.
abstract class A{
private function bobo(array $in){
//do something
}
}
class B extends A{
private function bobo($shmoo,$shmaa){
//do something
}
}
This throws an error. Shouldn't inheritance ignore private methods?!
'Declaration of B::bobo() should be
compatible with that of A::bobo()'
Note that the bug report is slightly off, as PHP will log this message any time you have an error level of E_STRICT (or, more recently, regardless of your error level provided that you've set a custom error handler).
PHP's visibility rules clearly demonstrate that a child lacks the ability to see its parent's private members, which I doubt is all that surprising to anyone. If the child can't see its parent's methods, I don't understand how it can have a duty to obey their definitions.
I personally think that the bug being marked as bogus without any explanation of why it wasn't a real flaw (since it's non-obvious and I couldn't find any mention of it in the documentation) is a bit wrong, but yeah. That aside, I'm of the opinion line 2669 in zend_compile.c should actually read as follows:
} else if (child->prototype &&
(EG(error_reporting) & E_STRICT || EG(user_error_handler))) {
...which would avoid the error popping up when the parent's method was marked private. Given that you always have the option not logging E_STRICT though, and it doesn't really negatively impact anything, I suppose it's not really a big deal. I definitely don't see how it could have been intentional, but I'm not a PHP engine developer either.
I think there are two possibilities here. Either it's a bug or the documentation on PHP.net/manual is incorrect. Here are three sections of the PHP manual. First on inheritance:
Object Inheritance
Inheritance is a well-established
programming principle, and PHP makes
use of this principle in its object
model. This principle will affect the
way many classes and objects relate to
one another.
For example, when you extend a class,
the subclass inherits all of the
public and protected methods from the
parent class. Unless a class overrides
those methods, they will retain their
original functionality.
This is useful for defining and
abstracting functionality, and permits
the implementation of additional
functionality in similar objects
without the need to reimplement all of
the shared functionality.
And on abstract classes:
Class Abstraction
PHP 5 introduces abstract classes and methods. It is not allowed to create an instance
of a class that has been defined as abstract. Any class that contains at least one
abstract method must also be abstract. Methods defined as abstract simply declare the
method's signature they cannot define the implementation.
When inheriting from an abstract class, all methods marked abstract in the parent's
class declaration must be defined by the child; additionally, these methods must be
defined with the same (or a less restricted) visibility. For example, if the abstract
method is defined as protected, the function implementation must be defined as either
protected or public, but not private.
Finally, interfaces
Object Interfaces
Object interfaces allow you to create code which specifies which methods a class must
implement, without having to define how these methods are handled.
Interfaces are defined using the interface keyword, in the same way as a standard class,
but without any of the methods having their contents defined.
All methods declared in an interface must be public, this is the nature of an interface.
Suffice it to say: there is nothing in the documentation that mentions inheritance of private methods. If there is a relationship between the parent and child method signatures, then it is not documented and the bug report should at least show someone that the documentation needs to be updated (if the decision to have this behavior is intentional). And if there was not supposed to be a relationship, then well, it's a real bug.
That's my opinion...
In the bug report when you remove the interface there isn't an error.
That makes it "more" strange behavior because the interface is just empty.
I guess this is a design decision of the language. The Java language developers decided that this should be possible.
Private methods should certainly not be ignored by inheritance, consider for example Template method pattern where you may override behavior of a function in a derived class, but the parent class can still call that function
public class Parent {
public final function doThings() {
$this->initialize();
$this->customStuff();
$this->cleanup();
}
private final function initialize() {
// initialize processing
}
private final function cleanup() {
// cleanup processing
}
private function customStuff() {
// parent specific processing
}
}
public class Derived extends Parent {
private function customStuff() {
parent::customStuff();
// + derived class specific processing
}
}
Calling doThings method on Derived class instance will do parent specific processing, but because of possibility to override private methods it is still possible to take advantage of the extension point provided by the non-final parent class customStuff method.
EDIT: Also PHP method signature consists of only the method name as you can define a method taking zero parameters and still call it with multiple parameters. Function can then access the arguments using func_get_args function.
After enabling strict warnings in PHP 5.2, I saw a load of strict standards warnings from a project that was originally written without strict warnings:
Strict Standards: Static function Program::getSelectSQL() should not be abstract in Program.class.inc
The function in question belongs to an abstract parent class Program and is declared abstract static because it should be implemented in its child classes, such as TVProgram.
I did find references to this change here:
Dropped abstract static class functions. Due to an oversight, PHP 5.0.x and 5.1.x allowed abstract static functions in classes. As of PHP 5.2.x, only interfaces can have them.
My question is: can someone explain in a clear way why there shouldn't be an abstract static function in PHP?
It's a long, sad story.
When PHP 5.2 first introduced this warning, late static bindings weren't yet in the language. In case you're not familiar with late static bindings, note that code like this doesn't work the way you might expect:
<?php
abstract class ParentClass {
static function foo() {
echo "I'm gonna do bar()";
self::bar();
}
abstract static function bar();
}
class ChildClass extends ParentClass {
static function bar() {
echo "Hello, World!";
}
}
ChildClass::foo();
Leaving aside the strict mode warning, the code above doesn't work. The self::bar() call in foo() explicitly refers to the bar() method of ParentClass, even when foo() is called as a method of ChildClass. If you try to run this code with strict mode off, you'll see "PHP Fatal error: Cannot call abstract method ParentClass::bar()".
Given this, abstract static methods in PHP 5.2 were useless. The entire point of using an abstract method is that you can write code that calls the method without knowing what implementation it's going to be calling - and then provide different implementations on different child classes. But since PHP 5.2 offers no clean way to write a method of a parent class that calls a static method of the child class on which it is called, this usage of abstract static methods isn't possible. Hence any usage of abstract static in PHP 5.2 is bad code, probably inspired by a misunderstanding of how the self keyword works. It was entirely reasonable to throw a warning over this.
But then PHP 5.3 came along added in the ability to refer to the class on which a method was called via the static keyword (unlike the self keyword, which always refers to the class in which the method was defined). If you change self::bar() to static::bar() in my example above, it works fine in PHP 5.3 and above. You can read more about self vs static at New self vs. new static.
With the static keyword added, the clear argument for having abstract static throw a warning was gone. Late static bindings' main purpose was to allow methods defined in a parent class to call static methods that would be defined in child classes; allowing abstract static methods seems reasonable and consistent given the existence late static bindings.
You could still, I guess, make a case for keeping the warning. For instance, you could argue that since PHP lets you call static methods of abstract classes, in my example above (even after fixing it by replacing self with static) you're exposing a public method ParentClass::foo() which is broken and that you don't really want to expose. Using a non-static class - that is, making all the methods instance methods and making the children of ParentClass all be singletons or something - would solve this problem, since ParentClass, being abstract, can't be instantiated and so its instance methods can't be called. I think this argument is weak (because I think exposing ParentClass::foo() isn't a big deal and using singletons instead of static classes is often needlessly verbose and ugly), but you might reasonably disagree - it's a somewhat subjective call.
So based upon this argument, the PHP devs kept the warning in the language, right?
Uh, not exactly.
PHP bug report 53081, linked above, called for the warning to be dropped since the addition of the static::foo() construct had made abstract static methods reasonable and useful. Rasmus Lerdorf (creator of PHP) starts off by labelling the request as bogus and goes through a long chain of bad reasoning to try to justify the warning. Then, finally, this exchange takes place:
Giorgio
i know, but:
abstract class cA
{
//static function A(){self::B();} error, undefined method
static function A(){static::B();} // good
abstract static function B();
}
class cB extends cA
{
static function B(){echo "ok";}
}
cB::A();
Rasmus
Right, that is exactly how it should work.
Giorgio
but it is not allowed :(
Rasmus
What's not allowed?
abstract class cA {
static function A(){static::B();}
abstract static function B();
}
class cB extends cA {
static function B(){echo "ok";}
}
cB::A();
This works fine. You obviously can't call self::B(), but static::B()
is fine.
The claim by Rasmus that the code in his example "works fine" is false; as you know, it throws a strict mode warning. I guess he was testing without strict mode turned on. Regardless, a confused Rasmus left the request erroneously closed as "bogus".
And that's why the warning is still in the language. This may not be an entirely satisfying explanation - you probably came here hoping there was a rational justification of the warning. Unfortunately, in the real world, sometimes choices are born from mundane mistakes and bad reasoning rather than from rational decision-making. This is simply one of those times.
Luckily, the estimable Nikita Popov has removed the warning from the language in PHP 7 as part of PHP RFC: Reclassify E_STRICT notices. Ultimately, sanity has prevailed, and once PHP 7 is released we can all happily use abstract static without receiving this silly warning.
static methods belong to the class that declared them. When extending the class, you may create a static method of the same name, but you are not in fact implementing a static abstract method.
Same goes for extending any class with static methods. If you extend that class and create a static method of the same signature, you are not actually overriding the superclass's static method
EDIT (Sept. 16th, 2009)
Update on this. Running PHP 5.3, I see abstract static is back, for good or ill. (see http://php.net/lsb for more info)
CORRECTION (by philfreo)
abstract static is still not allowed in PHP 5.3, LSB is related but different.
There is a very simple work around for this issue, which actually makes sense from a design point of view. As Jonathan wrote:
Same goes for extending any class with static methods. If you extend that class and create a static method of the same signature, you are not actually overriding the superclass's static method
So, as a work around you could do this:
<?php
abstract class MyFoo implements iMyFoo {
public static final function factory($type, $someData) {
// don't forget checking and do whatever else you would
// like to do inside a factory method
$class = get_called_class()."_".$type;
$inst = $class::getInstance($someData);
return $inst;
}
}
interface iMyFoo {
static function factory($type, $someData);
static function getInstance();
function getSomeData();
}
?>
And now you enforce that any class subclassing MyFoo implements a getInstance static method, and a public getSomeData method. And if you don't subclass MyFoo, you can still implement iMyFoo to create a class with similar functionality.
I know this is old but....
Why not just throw an exception the that parent class's static method, that way if you don't override it the exception is caused.
I would argue that an abstract class/interface could be seen as a contract between programmers. It deals more with how things should look/ behave like and not implement actual functionality. As seen in php5.0 and 5.1.x it's not a natural law that prevents the php developers from doing it, but the urge to go along with other OO design patterns in other languages. Basically these ideas try to prevent unexpected behavior, if one is already familiar with other languages.
I don't see any reason to forbid static abstract functions. The best argument that there is no reason to forbid them is, that they are allowed in Java.
The questions are:
- Are the technically feasable? - Yes, since the existed in PHP 5.2 and they exist in Java.
So whe CAN do it. SHOULD we do it?
- Do they make sense? Yes. It makes sense to implement an part of a class and leave another part of a class to the user. It makes sense in non-static functions, why shouldn't it make sense for static functions? One use of static functions are classes where there must not be more than one instance (singletons). For example an encryption engine. It does not need to exist in several instances and there are reasons to prevent this - for example, you have to protect only one part of the memory against intruders. So it makes perfect sense to implement one part of the engine and leave the encryption algorithm to the user.
This is only one example. If you are accustomed to use static functions you'll find lots more.
In php 5.4+ use trait:
trait StaticExample {
public static function instance () {
return new self;
}
}
and in your class put at the beggining:
use StaticExample;
Look into PHP's 'Late Static Binding' issues. If you're putting static methods on abstract classes, you're probably going to run into it sooner rather than later. It makes sense that the strict warnings are telling you to avoid using broken language features.