I have a class ParentClass(), some child-classes ChildClass1(), ChildClass2(), etc. and an interface iChild(). The ChildClass() inherits from the ParentClass() and implements iChild():
class ChildClass1
extends ParentClass
implements iChild {}
class ChildClass2
extends ParentClass
implements iChild {}
In the iChild()-Interface, I would like to require, that some constants need to be filled (which are mainly identifiers and some functionality definitions). I have not found any meaning to do so, as constants may only be defined in the interface, but which are not redefinable in the implementing classes. The only workaround I found is to define some getter-functions in iChild(), which in turn return the necessary values, but that does not seem to be the right way to do. As I already extend from the ParentClass(), I also cannot use an abstract class to e.g. check the definition of the required constants in all ChildClasses.
Any ideas on how to tackle this problem?
Update: To answer a comment - with leaner and more readable I mean to following:
class ChildClass1 {
const MY_NAME = "Foo Bar Name 1";
}
-- vs --
class ChildClass1 {
public function GetMyName() {
return "Foo Bar Name 1";
}
}
I find the first example a lot more readable and understandable than the second. Unfortunatly, I currently do not have a way to enforce MY_NAME to be set by the ChildClasses.
I'm not sure that the proper solution here is for a constant. The very definition of a constant is that it does not change. If each implementation of iChild needs to define the constant it isn't really a constant, it is a variable. I suggest adding in the appropriate getter methods, communicating to the user that they need to supply this information in their implementation.
Ok, I did a little testing and it simply is not possible for a class to override a constant set by an interface it is implementing or a parent class it is extending. Class constants appear to be checked at compile time and a fatal error is thrown if you attempt to override it. For what you are trying to do the appropriate answer is providing getter methods in your interface.
Related
I need static class (object) to store a global variable value. I'm new in PHP but i have experience in other language that have OOP concept like in Java. In Java i can make static variable and can call anywhere i want. But how to do same in PHP?
I use CodeIgniter framework , before i try this i try using session to store but i want to use another way like above. can anyone help me?
Can i do like this ?
static class myClass{
public static myVar = "";
}
Because you mentioned framework Codeigniter and use of session I assume that you need to use this in multiple controller and views.
So I there is also another way which works bit different than property of class but more similar than session (except changed value won't affect on another page).
So Use Constant.
Define it in
application > config > constant.php
page. There are many constant defined in that page, using exact same syntax you can define your values and you can use it very easily to any where.
just like if you define SITE_NAME constant in constant.php as
defined('SITE_NAME') OR define('SITE_NAME', "My Example Site");
After that you can use it anywhere in any controller, view or model of your Codeigniter, What you need to do is just echo it
<?php echo SITE_NAME; //only SITE_NAME not $SITE_NAME ?>
I hope it is what you want, if not sorry for my misunderstanding.
You can have a static-like class in PHP. But you don't have an app-cycle in PHP. This means you won't get a real static (or singleton) in your whole application.
If you shouldn't be able to instantiate a class then it should be abstract and define its methods as static. However, somebody could just subclass the class and make it non-abstract. If you don't want that to be a possibility either then the class should be abstract final.
If you do this, you can call methods directly on the class in question with ClassName::methodName() syntax. Do bear in mind that classes written like this can't make use of $this because it is only valid for an object instance. If you need the class to maintain state then you will have to define a static variable and use it with self:: or static:: syntax.
abstract final class SomeClass
{
private static $var = "";
public static function setVar($newVal)
{
self::$var = (string) $newVal;
}
public static function getVar()
{
return self::$var;
}
}
A word of caution on doing this though, use of abstract classes/methods can very easily lead to tightly coupled code which is bad for a number of reasons.
For example, if you write a class that calls the methods of an abstract class directly by any means other than inheriting from the abstract class, then it will be impossible to unit test that class in isolation. It will always require your abstract class to be part of the test suite too, which means it's more difficult to determine whether a test failure has been caused by a fault in the class under test or in the abstract class it's depending on.
What's more, if the abstract class you're depending on serves as an accessor for a data source, then you also will not be able to mock the class during tests. Mocking is a very powerful way of verifying the correctness of a class without having to rely on the environment that the class is running in. for example, you can mock a database access class with a compatible object that always returns the same data from an array instead of hitting an actual database. This means that you can guarantee that when you run a test it will run with data in a state that you have full control over. If you access a database via an abstract class's methods then you can't replace that for testing and suddenly you may end up with a test suite that might succeed or fail depending on the state of the database at the time you run the test. Even worse, if your tests involve writing to the database then you could potentially corrupt your data source when running tests.
I am a self-taught programmer and I am learning Zend Framework 2 at the moment.
I always wonder why every times when I'm trying to include a certain service, they are always required me to use Interface version of it.
For example, if I'm trying to use Service Locator, I will have to include serviceLocatorInterface in order to use Service Locator.
Why can't I just use Service Locator class itself.
Here is from Abstract Factory class.
use Zend\ServiceManager\ServiceLocatorInterface;
Then I would use in it this way
public function canCreateServiceWithName(ServiceLocatorInterface $serviceLocator, $name, $requestedName)
Here is another example from Zend tutorial, https://framework.zend.com/manual/2.4/en/in-depth-guide/services-and-servicemanager.html#bringing-the-service-into-the-controller
use Blog\Service\PostServiceInterface;
We include PostServiceInterface. Why not just PostService?
public function __construct(PostServiceInterface $postService)
We use the PostServiceInterface here. Why not just PostService as a Type.
I am sure this is a very simple answer that all students can answer but since i'm learning this myself so I am having a hard time understanding it.
PS. I do understand the concept of interface and inheritance. I just don't know why we include Interface this way.
Edit: After the answer I found a link that helps me understand better why people are passing interface as a type dependency instead of a concrete type.
What is the difference between an interface and abstract class?
http://kristopherwilson.com/2015/03/26/using-interfaces-effectively-in-php/
I hope those links help someone elses too.
use creates an local alias of the used class's full qualified name. An class name isn't just the name of the class, it always contains the namespace, where it is defined.
If you don't use the use keyword to create an local alias, php assumes, the class is in the current namespace (If you don't declare an namespace in the file, this is the root namespace \)
A simple example
// the current namespace
namespace Foo;
use Test\ClassName;
class Bar {
public function __construct(Baz $a) {
// Baz isn't a full qualified class name (missing leading \), so
// php assumes, Baz is inside the current namespace Foo
// => full class name is \Foo\Baz;
}
public function doSomething(ClassName $a) {
// ClassName isn't a full qualified class name, BUT there is an use
// statement, which imported ClassName to the local file
// => \Test\ClassName
}
public function doSomethingElse(\ClassName $a) {
// ClassName IS a full qualifed class name
// => \ClassName
}
}
note, that \ClassName and \Test\ClassName are two different classes.
So why use PostServiceInterface instead of PostService
You don't have to, but it's a good practice doing so with many benefits. I.e. you want to test the function later and don't have a PostService. Creating an new class, which inherits from PostService don't might be a good solution (and even couldn't be possible, because PostService could be declared final)
They way out of this is: Don't use the class, use the interface as parameter. This principle is part of the SOLID principles, named Dependency Inversion Principle and states two things:
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
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?
In every example I've seen, extended classes implement the interfaces of their parents. For reference, the following example:
interface MyInterface{
public function foo();
public function bar();
}
abstract class MyAbstract implements MyInterface{
public function foo(){ /* stuff */ }
public function bar(){ /* stuff */ }
}
// what i usually see
class MyClass extends MyAbstract implements MyInterface{}
// what i'm curious about
class MyOtherClass extends MyAbstract{}
Is failure to implement an interface in a child, which is implemented by a parent, considered bad practice or something? Are there any technical drawbacks to omitting the implementation in the child?
I would consider that you are on the right path. There is no need to declare that you are implementing the interface, when extending a class that already implements it. For me it's just another piece of code to maintain if change is needed. So, yes, you are correct!
Is failure to implement an interface
in a child, which is implemented by a
parent, considered bad practice or
something? Are there any technical
drawbacks to omitting the
implementation in the child?
I just can't answer your question better than this guy has:
By their nature, although sometimes
they may look quite similar, abstract
classes and class interfaces serve
very distinct purposes.
The interface of a class is meant as a
tool for the "user" of that class. An
interface is a public presentation for
the class, and it should advertise, to
anyone considering to use it, what
methods and constants are available
and accessible from the outside. So,
as it name suggests, it always sits
between the user and the class
implementing it.
On the other hand, an abstract class
is a tool aimed at helping the
"implementor" of the classes that
extend it. It is an infrastructure
that can impose restrictions and
guidelines about what the concrete
classes should look like. From a class
design perspective, abstract classes
are more architecturally important
than interfaces. In this case, the
implementor sits between the abstract
class and the concrete one, building
the latter on top of the former.
Reference
Thus, it's up to you to decide, based on who is going to use (instantiate) your classes, and who is going to write them. If you are the sole user and writer of your classes, then, maybe, just maybe, you don't need them both. But, if you want to give everyone a stripped down to core bits blueprint for the class writer(s) and class user(s), then you should consider using both abstracting and implementing.
Maybe a little late to the table but I see the above comments do not clarify the main misunderstanding underlying the OP's question.
So the underlying questions are:
Why we use both an Abstract class and an Interface on the same line?
Should both an Abstract method and an Interface declare the same methods at all?
But before some clarifications why to use either of the two above:
Either of them are used by one programmer to define the contract (requirements, obligations, limitations) the other programmers have to obey when they create the concrete classes (and eventually entire software application) based on Abstract classes / Interfaces developed by that programmer.
An Abstract class, in turn, is used to provide the later created concrete class with methods & data structures blueprint via:
data structures declarations (optional),
base implementation of methods (and their signatures, optional)
just methods declarations (similar to an Interface usage, optional).
An Interface is used to provide a concrete class with a methods blueprint via
just methods (and their signatures, optional) declarations.
Here is an example for an Abstract and concrete classes.
abstract class MyAbstractClass {
public function foo() {
// Base implementation of the method here.
}
public function bar() {
// Base implementation of the method here.
}
// Effectively similar to baz() declaration within some interface:
public abstract function baz($value);
}
class MyConcreteClass extends MyAbstractClass {
// foo() and bar() are inherited here from MyAbstractClass.
// baz() must be implemented or declared abstract again.
public function baz($value) {
// implementation.
}
}
Then the questions come:
Why we need an Interface here?
Do we need an Interface to duplicate same method declarations?
The answers:
Due to the fact that PHP allows only single inheritance for each subclass (you cannot write class MyConcreteClass extends MyAbstractClass, MyAnotherClass {}), when we need to expand the concrete class functionality beyond the already used Abstract class we have to declare this additional functionality via one or more Interfaces.
Like this:
class MyConcreteClass
extends MyAbstractClass
implements MyInterface, MyAnotherInterface {
// Methods and data implementations go here.
}
As the result from the answer 1, an Interface better not to duplicate an Abstract class methods' declarations (this is basically useless). An Interface(s) should decalre the methods that may help to enhance the concrete (or another Abstract class, why not) functionality to provide the programmer that will use these with the firm contract for each object built on top of these classes and interfaces.
Finally, answer to the the OP question whether to use an Interface for an Abstract class or for the concrete class is:
use for either or both (or as needed) as long as an Interface enhances a class contract with new methods' declarations.
Is failure to implement an interface in a child, which is implemented by a parent, considered bad practice or something?
The child always implements the interface, it can not go around with this.
I have no clue if that is bad practice or something. I would say it's a language feature.
Are there any technical drawbacks to omitting the implementation in the child?
You can not test the reflection of the abstract class for having the interface for example.
However, abstract class are already an interface, so technically they themselves not really need the interface but you can do so to keep things fluid within the inheritance.
Well, I was confused too, but I think you should use the latter one, You are right, If you implement the interface in the abstract class, then there is no need to write the interface, you can write the method in interface all into abstract as abstract methods, because you will extend the abstract class whatever, and you will have to use the abstract class as a param type when you use the class in other place, that's not a good thing, I think an abstract class should't be used as a param type, while an interface should be.
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.