As we all know, static methods can be called without instantiating the class. So I wonder if static methods will be loaded into memory before I use them. If that, in my view, I should use more intance methods instead of too many static methods. Anyone advice? I am not familiar with the underlying mechanism of PHP.
A static method is just a regular function with a fancy name (and restricted access if it is not public).
Static methods are not OOP, they are procedural code in disguise.
Should I avoid using too many static methods in PHP?
It depends how many do you think are "too many". For pure OOP code, one static method is already "too many". But sometimes it's unavoidable (read "easier") to write a static method for some functionality.
So I wonder if static methods will be loaded into memory before I use them.
No matter if you run a PHP script using the CLI or it is invoked through the web server to serve a web page, the text of the script is loaded into memory and compiled. If the compilation is successful (i.e. there are no syntax errors), the interpreter starts executing it.
Everything that is defined in the script is already in memory at this moment, but only the items defined in the main script. The inclusion statements (include, include_once, require, require_once) are not processed during the compilation phase.
The file referred by a include statement is loaded in memory, compiled and executed when, and if, the include statement is reached during the execution of the script. The entire content of the included file is loaded, parsed and converted to opcodes, no matter if it contains functions, classes or global code. There is no differences between instance methods and static methods from this point of view.
So I wonder if static methods will be loaded into memory before I use them.
When a class is loaded, all of its methods are always loaded. This happens regardless of whether those methods are class methods or instance methods, or whether they are being used by the application.
Use whatever type of method is most appropriate for your design.
I should use more intance methods instead of too many static methods.
Anyone advice?
Well sometimes you need to define a static method, if you need to call it without creating an object of that class but this should be limited.
When to use static methods:
You can use static methods as factories to create an object according to the context or sharing resources with other instances.
If there is no relation with your purpose and an instance
If you are planning to use public static properties, I would recommend to use CONST in some cases unless you don't want to change its value.
Why?
Consts are on the class and object scope and its always immutable (You cannot change its value) and which is safe to use.
Static properties not on the object scope but on the class scope and its mutable (can be change) and which is not safe to use.
And alternatively you can check the Singleton pattern to see how to use static methods on resource sharing.
Hi I'm using Debenu Quick PDF Library in a PHP project.
And I instantiate my object with the following code.
$qp = new COM('DebenuPDFLibraryAX1012.PDFLibrary');
My question : Is it possible to extend this COM class?
Yes, it is possible to extend any class unless it is declared as final. You may not however be able to override certain methods if the individual methods have been declared with final keyword.
Extending a COM class - in the sense of overriding some functions and expecting the base class code to call the overridden versions - is not possible in general, regardless of the language you are using.
The reason is simple: even though COM interfaces resemble the virtual pointer tables of C++ objects - to the point of the latter being usable as the former in some contexts - they are effectively unidirectional. They allow you to call into the object, but they are not necessarily used by the object to invoke its own methods, and COM does not allow you to stick a new function pointer in there somewhere.
In fact, unless the interface you are using is for an in-process object created in the same apartment, invocations of interface methods do not go directly to the object. Instead they go to a proxy object created by COM, which forwards the call to a stub object in the true object's apartment (which may be in another process, even on another computer), which will in turn invoke the method on the true object and pass results back along the chain.
When you override a function of a base class you generally do this with the expectation that the base class code will call back into your derived class. In COM, calling something entails obtaining an interface pointer and invoking some of its methods. However, your derived class does not expose any interface to COM that the base class would know about and ask for.
That is why extensible COM classes must publish interfaces - basically, hooks - that users can implement in order to get called back at appropriate times. These are often called 'event interfaces', and the COM class is then said to be 'publishing events', with 'OnClick' being a famous example.
I need to develop a small CMS using PHP, and right now I'm trying to figure out the structure.
The CMS will be generated using a set of functions. Things like database functions, caching thingies, internationalization and stuff like this.
I was thinking to do it like this:
make the functions non-static methods part of a big "site" class; that way I could run multiple instances of that class. Not sure I would need to do that though..
or split the functions into separate classes with static methods
The main problem here is that the CMS should be able to manage multiple small sites, not just one. So either I make all methods static and add a "site switch" function, or make them normal objects which I instantiate based on the site which I want to manage
Which of these would be the best option?
Static methods are generally bad practice. They introduce a lot of potential issues.
1) They introduce hidden dependencies. Code which arbitrarily calls foo::bar() has a dependency on foo and cannot run without foo being defined. The object using foo::bar() will construct correctly but won't be usable if foo is not defined.
2) Statics are globals. Global state is very bad, anything can change the code and its state is unknown. You sacrifice the power and control achieved by OOP encapsulation by using static methods.
3) It's impossible to substitute the functions for a different version
4) It makes unit testing impossible.
For more detailed information and code examples, see this article and this article
I'd definitely suggest using static classes for this job. Going this route will create a pseudo namespace for all of your functions so you don't have to worry about conflicting function names, etc, and it also prevents you from having to pass around an instance of your helper class just to call one of your helper functions.
Is there something similar to the ruby module construct in php ?
Basically I need to create a modules for a mix-in b/w different classes etc.
I know that php has the concept of mixins b/w different classes, but not sure about modules.
PHP doesn't have mixins in the same way Ruby has them. That is, you can't change anything about a class after it's been defined, and you can't sanely add new methods to an instance after it's been created 1. PHP only has the plain old vanilla single-inheritance mechanism, interfaces, and composing traits in 5.4.
The closest thing that PHP might have to a Ruby module is going to be a class. The closest thing that PHP might have to a Ruby mixin is a trait, but traits are not dynamic. They must be referenced by any implementing class at the time that the class is defined. They can not be added or modified at runtime, and apply to the class as a whole, not to individual instances.
While PHP 5.3 has namespaces, they are restricted to holding functions, classes, constants, traits and interfaces only, meaning you can't define variables as a first-class member of a namespace. Attempting to do so results in them being defined in the root namespace instead, which is certainly not what anybody would want. Further, there is no namespace inheritance mechanism, only a namespace reference mechanism.
1: While you can add instance variables (properties) after an object has been created by simply referencing them, this is considered a bad practice. Properties can also contain anonymous functions, but abusing properties this way to emulate adding methods is also bad practice.
Interfaces allow you to create code which defines the methods of classes that implement it. You cannot however add any code to those methods.
Abstract classes allow you to do the same thing, along with adding code to the method.
Now if you can achieve the same goal with abstract classes, why do we even need the concept of interfaces?
I've been told that it has to do with OO theory from C++ to Java, which is what PHP's OO stuff is based on. Is the concept useful in Java but not in PHP? Is it just a way to keep from having placeholders littered in the abstract class? Am I missing something?
The entire point of interfaces is to give you the flexibility to have your class be forced to implement multiple interfaces, but still not allow multiple inheritance. The issues with inheriting from multiple classes are many and varied and the wikipedia page on it sums them up pretty well.
Interfaces are a compromise. Most of the problems with multiple inheritance don't apply to abstract base classes, so most modern languages these days disable multiple inheritance yet call abstract base classes interfaces and allows a class to "implement" as many of those as they want.
The concept is useful all around in object oriented programming. To me I think of an interface as a contract. So long my class and your class agree on this method signature contract we can "interface". As for abstract classes those I see as more of base classes that stub out some methods and I need to fill in the details.
Why would you need an interface, if there are already abstract classes?
To prevent multiple inheritance (can cause multiple known problems).
One of such problems:
The "diamond problem" (sometimes referred to as the "deadly diamond of
death") is an ambiguity that arises when two classes B and C inherit
from A and class D inherits from both B and C. If there is a method
in A that B and C have overridden, and D does not override it, then
which version of the method does D inherit: that of B, or that of C?
Source: https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem
Why/When to use an interface?
An example... All cars in the world have the same interface (methods)... AccelerationPedalIsOnTheRight(), BrakePedalISOnTheLeft(). Imagine that each car brand would have these "methods" different from another brand. BMW would have The brakes on the right side, and Honda would have brakes on the left side of the wheel. People would have to learn how these "methods" work every time they would buy a different brand of car. That's why it's a good idea to have the same interface in multiple "places."
What does an interface do for you (why would someone even use one)?
An interface prevents you from making "mistakes" (it assures you that all classes which implement a specific interface, will all have the methods which are in the interface).
// Methods inside this interface must be implemented in all classes which implement this interface.
interface IPersonService
{
public function Create($personObject);
}
class MySqlPerson implements IPersonService
{
public function Create($personObject)
{
// Create a new person in MySql database.
}
}
class MongoPerson implements IPersonService
{
public function Create($personObject)
{
// Mongo database creates a new person differently then MySQL does. But the code outside of this method doesn't care how a person will be added to the database, all it has to know is that the method Create() has 1 parameter (the person object).
}
}
This way, the Create() method will always be used the same way. It doesn't matter if we are using the MySqlPerson class or the MongoPerson class. The way how we are using a method stays the same (the interface stays the same).
For example, it will be used like this (everywhere in our code):
new MySqlPerson()->Create($personObject);
new MongoPerson()->Create($personObject);
This way, something like this can't happen:
new MySqlPerson()->Create($personObject)
new MongoPerson()->Create($personsName, $personsAge);
It's much easier to remember one interface and use the same one everywhere, than multiple different ones.
This way, the inside of the Create() method can be different for different classes, without affecting the "outside" code, which calls this method. All the outside code has to know is that the method Create() has 1 parameter ($personObject), because that's how the outside code will use/call the method. The outside code doesn't care what's happening inside the method; it only has to know how to use/call it.
You can do this without an interface as well, but if you use an interface, it's "safer" (because it prevents you to make mistakes). The interface assures you that the method Create() will have the same signature (same types and a same number of parameters) in all classes that implement the interface. This way you can be sure that ANY class which implements the IPersonService interface, will have the method Create() (in this example) and will need only 1 parameter ($personObject) to get called/used.
A class that implements an interface must implement all methods, which the interface does/has.
I hope that I didn't repeat myself too much.
The difference between using an interface and an abstract class has more to do with code organization for me, than enforcement by the language itself. I use them a lot when preparing code for other developers to work with so that they stay within the intended design patterns. Interfaces are a kind of "design by contract" whereby your code is agreeing to respond to a prescribed set of API calls that may be coming from code you do not have aceess to.
While inheritance from abstract class is a "is a" relation, that isn't always what you want, and implementing an interface is more of a "acts like a" relation. This difference can be quite significant in certain contexts.
For example, let us say you have an abstract class Account from which many other classes extend (types of accounts and so forth). It has a particular set of methods that are only applicable to that type group. However, some of these account subclasses implement Versionable, or Listable, or Editable so that they can be thrown into controllers that expect to use those APIs. The controller does not care what type of object it is
By contrast, I can also create an object that does not extend from Account, say a User abstract class, and still implement Listable and Editable, but not Versionable, which doesn't make sense here.
In this way, I am saying that FooUser subclass is NOT an account, but DOES act like an Editable object. Likewise BarAccount extends from Account, but is not a User subclass, but implements Editable, Listable and also Versionable.
Adding all of these APIs for Editable, Listable and Versionable into the abstract classes itself would not only be cluttered and ugly, but would either duplicate the common interfaces in Account and User, or force my User object to implement Versionable, probably just to throw an exception.
Interfaces are essentially a blueprint for what you can create. They define what methods a class must have, but you can create extra methods outside of those limitations.
I'm not sure what you mean by not being able to add code to methods - because you can. Are you applying the interface to an abstract class or the class that extends it?
A method in the interface applied to the abstract class will need to be implemented in that abstract class. However apply that interface to the extending class and the method only needs implementing in the extending class. I could be wrong here - I don't use interfaces as often as I could/should.
I've always thought of interfaces as a pattern for external developers or an extra ruleset to ensure things are correct.
You will use interfaces in PHP:
To hide implementation - establish an access protocol to a class of objects an change the underlying implementation without refactoring in all the places you've used that objects
To check type - as in making sure that a parameter has a specific type $object instanceof MyInterface
To enforce parameter checking at runtime
To implement multiple behaviours into a single class (build complex types)
class Car implements EngineInterface, BodyInterface, SteeringInterface {
so that a Car object ca now start(), stop() (EngineInterface) or goRight(),goLeft() (Steering interface)
and other things I cannot think of right now
Number 4 it's probably the most obvious use case that you cannot address with abstract classes.
From Thinking in Java:
An interface says, “This is what all classes that implement this particular interface will look like.” Thus, any code that uses a particular interface knows what methods can be called for that interface, and that’s all. So the interface is used to establish a “protocol” between classes.
Interfaces exist not as a base on which classes can extend but as a map of required functions.
The following is an example of using an interface where an abstract class does not fit:
Lets say I have a calendar application that allows users to import calendar data from external sources. I would write classes to handle importing each type of data source (ical, rss, atom, json) Each of those classes would implement a common interface that would ensure they all have the common public methods that my application needs to get the data.
<?php
interface ImportableFeed
{
public function getEvents();
}
Then when a user adds a new feed I can identify the type of feed it is and use the class developed for that type to import the data. Each class written to import data for a specific feed would have completely different code, there may otherwise be very few similarities between the classes outside of the fact that they are required to implement the interface that allows my application to consume them. If I were to use an abstract class, I could very easily ignore the fact that I have not overridden the getEvents() method which would then break my application in this instance whereas using an interface would not let my app run if ANY of the methods defined in the interface do not exist in the class that implemented it. My app doesn't have to care what class it uses to get data from a feed, only that the methods it needs to get that data are present.
To take this a step further, the interface proves to be extremely useful when I come back to my calendar app with the intent of adding another feed type. Using the ImportableFeed interface means I can continue adding more classes that import different feed types by simply adding new classes that implement this interface. This allows me to add tons of functionality without having to add unnecessarily bulk to my core application since my core application only relies on there being the public methods available that the interface requires so as long as my new feed import classes implement the ImportableFeed interface then I know I can just drop it in place and keep moving.
This is just a very simple start. I can then create another interface that all my calendar classes can be required to implement that offers more functionality specific to the feed type the class handles. Another good example would be a method to verify the feed type, etc.
This goes beyond the question but since I used the example above:
Interfaces come with their own set of issues if used in this manner. I find myself needing to ensure the output that is returned from the methods implemented to match the interface and to achieve this I use an IDE that reads PHPDoc blocks and add the return type as a type hint in a PHPDoc block of the interface which will then translate to the concrete class that implements it. My classes that consume the data output from the classes that implement this interface will then at the very least know it's expecting an array returned in this example:
<?php
interface ImportableFeed
{
/**
* #return array
*/
public function getEvents();
}
There isn't much room in which to compare abstract classes and interfaces. Interfaces are simply maps that when implemented require the class to have a set of public interfaces.
Interfaces aren't just for making sure developers implement certain methods. The idea is that because these classes are guaranteed to have certain methods, you can use these methods even if you don't know the class's actual type. Example:
interface Readable {
String read();
}
List<Readable> readables; // dunno what these actually are, but we know they have read();
for(Readable reader : readables)
System.out.println(reader.read());
In many cases, it doesn't make sense to provide a base class, abstract or not, because the implementations vary wildly and don't share anything in common besides a few methods.
Dynamically typed languages have the notion of "duck-typing" where you don't need interfaces; you are free to assume that the object has the method that you're calling on it. This works around the problem in statically typed languages where your object has some method (in my example, read()), but doesn't implement the interface.
In my opinion, interfaces should be preferred over non-functional abstract classes. I wouldn't be surprised if there would be even a performance hit there, as there is only one object instantiated, instead of parsing two, combining them (although, I can't be sure, I'm not familiar with the inner workings of OOP PHP).
It is true that interfaces are less useful/meaningful than compared to, say, Java. On the other hand, PHP6 will introduce even more type hinting, including type hinting for return values. This should add some value to PHP interfaces.
tl;dr: interfaces defines a list of methods that need to be followed (think API), while an abstract class gives some basic/common functionality, which the subclasses refine to specific needs.
I can't remember if PHP is different in this respect, but in Java, you can implement multiple Interfaces, but you can't inherit multiple abstract classes. I'd assume PHP works the same way.
In PHP you can apply multiple interfaces by seperating them with a comma (I think, I don't find that a clean soloution).
As for multiple abstract classes you could have multiple abstracts extending each other (again, I'm not totally sure about that but I think I've seen that somewhere before). The only thing you can't extend is a final class.
Interfaces will not give your code any performance boosts or anything like that, but they can go a long way toward making it maintainable. It is true that an abstract class (or even a non-abstract class) can be used to establish an interface to your code, but proper interfaces (the ones you define with the keyword and that only contain method signatures) are just plain easier to sort through and read.
That being said, I tend to use discretion when deciding whether or not to use an interface over a class. Sometimes I want default method implementations, or variables that will be common to all subclasses.
Of course, the point about multiple-interface implementation is a sound one, too. If you have a class that implements multiple interfaces, you can use an object of that class as different types in the same application.
The fact that your question is about PHP, though, makes things a bit more interesting. Typing to interfaces is still not incredibly necessary in PHP, where you can pretty much feed anything to any method, regardless of its type. You can statically type method parameters, but some of that is broken (String, I believe, causes some hiccups). Couple this with the fact that you can't type most other references, and there isn't much value in trying to force static typing in PHP (at this point). And because of that, the value of interfaces in PHP, at this point is far less than it is in more strongly-typed languages. They have the benefit of readability, but little else. Multiple-implementation isn't even beneficial, because you still have to declare the methods and give them bodies within the implementor.
Interfaces are like your genes.
Abstract classes are like your actual parents.
Their purposes are hereditary, but in the case of abstract classes vs interfaces, what is inherited is more specific.
I don't know about other languages, what is the concept of interface there. But for PHP, I will try my best to explain it. Just be patient, and Please comment if this helped.
An interface works as a "contracts", specifying what a set of subclasses does, but not how they do it.
The Rule
An Interface can't be instantiate.
You can't implement any method in an interface,i.e. it only contains .signature of the method but not details(body).
Interfaces can contain methods and/or constants, but no attributes. Interface constants have the same restrictions as class constants. Interface methods are implicitly abstract.
Interfaces must not declare constructors or destructors, since these are implementation details on the class
level.
All the methods in an interface must have public visibility.
Now let's take an example.
Suppose we have two toys: one is a Dog, and other one is a Cat.
As we know a dog barks, and cat mews.These two have same speak method, but with different functionality or implementation.
Suppose we are giving the user a remote control that has a speak button.
When the user presses speak button, the toy have to speak it doesn't matter if it's Dog or a Cat.
This a good case to use an interface, not an abstract class because the implementations are different.
Why? Remember
If you need to support the child classes by adding some non-abstract method, you should use abstract classes. Otherwise, interfaces would be your choice.
Below are the points for PHP Interface
It is used to define required no of methods in class [if you want to load html then id and name is required so in this case interface include setID and setName].
Interface strictly force class to include all the methods define in it.
You can only define method in interface with public accessibility.
You can also extend interface like class. You can extend interface in php using extends keyword.
Extend multiple interface.
You can not implement 2 interfaces if both share function with same name. It will throw error.
Example code :
interface test{
public function A($i);
public function B($j = 20);
}
class xyz implements test{
public function A($a){
echo "CLASS A Value is ".$a;
}
public function B($b){
echo "CLASS B Value is ".$b;
}
}
$x = new xyz();
echo $x->A(11);
echo "<br/>";
echo $x->B(10);
We saw that abstract classes and interfaces are similar in that they provide abstract methods that must be implemented in the child classes. However, they still have the following differences:
1.Interfaces can include abstract methods and constants, but cannot contain concrete methods and variables.
2.All the methods in the interface must be in the public visibility
scope.
3.A class can implement more than one interface, while it can inherit
from only one abstract class.
interface abstract class
the code - abstract methods - abstract methods
- constants - constants
- concrete methods
- concrete variables
access modifiers
- public - public
- protected
- private
etc.
number of parents The same class can implement
more than 1 interface The child class can
inherit only from 1 abstract class
Hope this will helps to anyone to understand!