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.
Related
I've got a basic question:
When I'm developing PHP I often wonder, when is it reasonable to use exampleclass::getInstance()
and when to use new exampleclass()
When should I use which one? and what is the big difference between them?
I just want to get out the "best practice" out of that issue.
Thanks for your help!
A class that implements a getInstance() method is usually a singleton. In this case, you should basically never use new exampleclass(). (Actually, calling the constructor directly should be forbidden after all.)
A singleton assumes that one instance of its class at most exists during the program's lifetime. If there were more instances, they could conflict with each other which would cause some ugly problems. (For example, the singleton could access some globally available functions or methods or open some connection to another module or another network location. If two instances write to the same variables without knowning about each other, the system could get into a state where it does not know how to continue working.)
Typically, getInstance() is used in the case of a Singleton pattern, that is when you need to always use the same instance of object. In this case, the getInstance calls a usually private constructor only on the first call.
A new ExampleClass() will create a new instance of this class on each call.
I am learning about modules online and it seems like modules in js and classes in php are very similar. Both group functions together for easier to understand coding. Functions can be declared in both and made public or private. How are they similar in use and how are they different?
Javascript's modules provides some nice features like encapsulation, the private state and even inheritance from other modules. While they provide some of the features of classes, as in PHP, they are not. They try to build on the existing Javascript functonality to emulate classes, hence why the confusion. i.e. they are built to look and feel like classes.
Javascript's modules are instances of an anonymous function assigned to a variable. Therefore they have all the features of a function where their code is executed top to bottom, they have and sometimes use a return statement (in PHP classes no statements can be run directly apart from field definition and assignment) and they even have access to global variables. In PHP, on the other hand a class, or rather it's methods, cannot access a variable that is not in the class itself. In order to access global variables a class method or static function has to explicitly call the variable i.e global $a inorder to import it. In js modules, all global vars are accessible but sometimes one chooses to explicity import them for neater code (function(a){})(imported);
Another important issue is data abstraction. While js modules provide private states for the fields, PHP's classes, just like C++, java, python etc, provide more security to the properties. It allows for base classes using the abstract class and interface keywords whereby class methods and attributes are only defined or structured but not used.
PHP classes also have constructors and destructors, that are called when the class object is initialized and on the last mention used to destroy the object. Granted, you can create functions in modules to run when you want, in PHP on the other hand, functions in the method are only executed when they are called either by the object, the class or other functions.
In classes there are static functions, these can be called without even having an object of the class and run independent of objects, on the other hand in js, everything is an object; which defeats the point of static functions.
They are similar in that: both have inheritance, where you can extend an existing module with a new one, and in PHP you can use extends to inherit from a parent class. They both have private data states preventing external access, they both group and package data and methods, and both are awesome when utilized properly.
Ok guys I am struggling to understand why there is a need of singleton.
Let's make a real example: I have a framework for a my CMS
I need to have a class that logs some information (let's stick on PHP).
Example:
class Logger{
private $logs = array();
public function add($log) {
$this->logs[]=$log;
}
}
Now of course this helper object must be unique for the entry life of a page request of my CMS.
And to solve this we would make it a singleton (declaring private the constructor etc.)
But Why in the hell a class like that isn't entirerly static? This would solve the need of the singleton pattern (that's considered bad pratice) Example:
class Logger {
private static $logs = array();
public static function add($log) {
self::$logs[]=$log;
}
}
By making this helper entirely static, when we need to add a log somewhere in our application we just need to call it statically like: Logger::add('log 1'); vs a singleton call like: Logger::getInstance()->add('log 1');
Hope someone makes it easy to understand for me why use singleton over static class in PHP.
Edit
This is a pretty nice lecture on the singleton vs static class for who is interested, thanks to #James. (Note it doesn't address my question)
Many reasons.
Static methods are basically global functions that can be called from any scope, which lends itself to hard to track bugs. You might as well not use a class at all.
Since you cannot have a __construct method, you may have to put an init static method somewhere. Now people in their code are unsure if the init method has been called previously. Do they call it again? Do they have to search the codebase for this call? What if init was somewhere, but then gets removed, or breaks? Many places in your code now rely on the place that calls the init method.
Static methods are notoriously hard to unit test with many unit testing frameworks.
There are many more reasons, but it's hard to list them all.
Singletons aren't really needed either if you are using DI.
A side note. DI allows for your classes not to rely on each other, but rather on interfaces. Since their relationships are not cemented, it is easier to change your application at a later time, and one class breaking will not break both classes.
There are some instances where single state classes are viable, for instance if none of your methods rely on other methods (basically none of the methods change the state of the class).
I use singletons, so I can tell you exactly why I do it instead of a static function.
The defining characteristic of a singleton is that it is a class that has just one instance. It is easy to see the "just one instance" clause and forget to see the "it is a class" clause. It is, after all, a normal class object with all the advantages that that brings. Principly, it has its own state and it can have private functions (methods). Static functions have to do both of these in more limited or awkward ways.
That said, the two complement each other: a static function can be leveraged to return a singleton on the same class. That's what I do in the singleton I use the most often: a database handler.
Now, many programmers are taught that "singletons are bad, mm'kay?" but overlook the rider that things like are usually only bad when overused. Just like a master carver, an experienced programmer has a lot of tools at his disposal and many will not get a lot of use. My database handler is ideal as a singleton, but it's the only one I routinely use. For a logging class, I usually use static methods.
Singletons allow you to override behavior. Logger::add('1') for example can log to different devices only if the Logger class knows how. Logger::getLogger()->add('1') can do different things depending on what subtype of Logger getLogger() returns.
Sure you can do everything within the logger class, but often you then end up implementing the singleton inside the static class.
If you have a static method that opens a file, writes out and closes it, you may end up with two calls trying to open the same file at the same time, as a static method doesn't guarantee there is one instance.
But, if you use a singleton, then all calls use the same file handler, so you are always only having one write at a time to this file.
You may end up wanting to queue up the write requests, in case there are several, if you don't want them to fail, or you have to synchronize in other ways, but all calls will use the same instance.
UPDATE:
This may be helpful, a comparison on static versus singleton, in PHP.
http://moisadoru.wordpress.com/2010/03/02/static-call-versus-singleton-call-in-php/
As leblonk mentioned, you can't override static classes, which makes unit testing very difficult. With a singleton, you can instantiate a "mock" object instead of the actual class. No code changes needed.
Static classes can have namespace conflicts. You can't load 2 static classes of the same name, but you can load 2 different versions of a singleton and instantiate them under the same name. I've done this when I needed to test new versions of classes. I instantiate a different version of the class, but don't need to change the code that references that class.
I often mix singletons and static. For example, I use a database class that ensures there is only 1 connection to each master (static) and slave (singleton). Each instance of the db class can connect to a different slave, if a connection to the same slave is requested, the singleton object is returned. The master connection is a static object instantiated inside each slave singleton, so only 1 master connection exists across all db instantiated objects.
This might be a stupid question but I have to ask:
I have a big group of related functions for a project I am doing. The functions need to access a few global variables, so I was thinking about putting them into a class and loading the class as needed. I suppose my other option is to just include them as unrelated functions in an included PHP file, but putting them into 1 class seems to make sense. Is this an acceptable practice? I have worked with people who did this but it always seemed to not quite be in the spirit of good OOP practices because the classes were almost never instantiated but the functions were still called. Or maybe I'm over thinking it.
Any input would be awesome, thanks a bunch.
A class does make the most sense. Whenever you can eliminate global variables, it is a good thing. Whether the class is instantiated or a static helper usually depends on the context. However, for future unit testing, instantiations allow dependency injection.
According to http://en.wikipedia.org/wiki/Class_%28computer_programming%29, a class defines constituent members which enable class instances to have state and behavior. If you will be providing only behavior (functions) and not state (properties), you should include your functions in an include file and forgo the overhead of a class.
Correct me if I'm wrong but this seems like you should create a class that acts as a static service, where no explicit instantiation is needed of the class, yet you will still call the methods contained within this class.
Now, if you're thinking of storing those global variables in the class, obviously that's no longer a static class because there would have to be some sort of lifetime for the object, and at which point you'd have to instantiate the class first and then make calls to those methods.
Regardless, if they're all related functions working on the same data, it certainly makes sense to group them within their own class.
I am new to object oriented programming and writing some of my first classes for a PHP application.
In some of the simpler classes, I declare a function __construct(), and inside of that function, call certain class methods. In some cases, I find myself instantiating the class in my app, and not needing to do anything with the resultant object because the class's __construct() called the methods, which did their job, leaving me nothing left to do with the class.
This just doesn't feel right to me. Seems goofy that I have a new object that I never do anything with.
Again, I'll stress this is only the case for some of my more simple classes. In the more complicated ones, I do use class methods via the object and outside of __construct().
Do I need to rethink the way I coding things, or am I ok?
Well, the constructor is used to create a new instance of a class, and to do any necessary setup on that class. If you're just creating the class and leaving it, that does seem a bit of a waste. Why not, for instance, use static functions in the class as an organizational tool and just call them(or a function that calls them) instead of constructing a new instance that you'll never use?
This just doesn't feel right to me. Seems goofy that I have a new object that I never do anything with.
Yes, that should raise a red flag.
In general, you should not let constructors have any side effects; They are meant for initialising the state of the object - not for anything else. There are of course exceptions to this rule, but in general it's a good guide line. You should also abstain from doing any heavy calculations in the constructor. Move that to a method instead.
Side effects are many things - Changes to global variables or static (class) variables; output to the environment (For example calls to print(), header() or exit()); calls to a database or other external service and even changes to the state of other objects.
A side effect free function is also called a "pure" function - as opposed to a procedure, which is a function that has side effects. It's a good practise to explicitly separate pure functions from procedures (and perhaps even label them as such).