I'm using OOP aproach in php.I'm just learning though. Each time I need to access a method in a class I instantiate a object.So I have quite a number of objects created in my project to do each task.Is there a way where I can only create one object and share throughout the project to do multiple method for different task?
Also in my class, I declared the variable first and then use them like $this->property = $assign_variable.Will declaring variable earlier would consume memory much?
I'm just concerned to approach the right and effective way of instantiating object and declaring class in OOP. Can anyone suggest please?
Having multiple instances of an object consumes more memory (much is relative), as every attribute of an object needs to have allocated memory. If you have an object that consumes, lets say, x bytes of memory for its attributes, then you will need n*x bytes of memory if you instantiate n objects in total (There is also a neglactable amount of memory used which needs to be used for the code, but the amount is constant). In normal use that shouldn't be a problem though (i.e. if you don't have an unusual huge amount of objects).
If you need only one instance of a class through the whole program, I'd suggest you to use the Singleton design pattern 1].
Here is an example:
class Singleton {
// This is where the one and only instance is stored
private static $instance = null;
private __construct() {
// Private constructor so the class can't be initialized
}
// That's how you get the one and only instance
public static function getInstance() {
if (Singleton::$instance === null) {
Singleton::$instance = new Singleton();
}
return Singleton::$instance;
}
public function doSomething() {
// here you can do whatever you need to do with the one and only object of this class
}
}
You can then use it very conveniently like this:
Singleton::getInstance()->doSomething();
So you are basically just storing the address of the object in one location, namely Singleton::$instance.
Another option for you could be to use static methods. It is defined like above in the Singleton pattern:
class StaticExample {
// ...
public static function doSomething() {
// your code
}
}
And can be accessed with StaticExample::doSomething();
I also want to note that usually, you don't have much classes in a project which implements the Singleton design pattern or use the static keyword very often. If you want to use a lot of singletons or see yourself needing a lot of statics, you probably got something wrong and should post an example of your code on another site like Programmers Stack Exchange.
1] Singleton design pattern on Wikipedia
Related
I was wondering if there's a good way to implement the registry pattern in PHP, let me be more clear:
I do know that a Registry is used when you need to keep track of the object you instantiate in order to reuse them and not re-instantiate them again from script to script, e.g. I have a Database class that I want to instantiate only once and then use for all my scripts and I do not want to re-instantiate it again and again. Another example could be a User class that represents an instance of the currently logged in user. I could not use a Singleton in this case, cause e.g. I need another User instance for example when I want to retrieve a friend of the currently logged in user etc.
So I came up with the idea that the Registry better suits this kind of needs in such cases.
I also know that there are two ways of implementing it, or better two ways in order to access the stored instances:
Explicitly or externally, meaning that the Registry should be called every time you need to recover an instance inside your scripts or you need to put an instance inside of it;
Implicitly or internally, meaning that you make kind of an abstract class with a getInstance() method that returns an instance with the get_called_class() late static binding feature, adds it to the registry and then return that instance from the registry itself taking care that if a $label parameter is passed to the getInstance() method, then that particular instance from the registry will be returned. This approach is kinda transparent to the consumer and in my opinion is cleaner and neater (I'll show both implementations, though).
Let's take a basic Registry (really simple implementation, just an example took from a book):
class Registry {
static private $_store = array();
static public function set($object, $name = null)
{
// Use the class name if no name given, simulates singleton
$name = (!is_null($name)) ? $name: get_class($object);
$name = strtolower($name);
$return = null;
if (isset(self::$_store[$name])) {
// Store the old object for returning
$return = self::$_store[$name];
}
self::$_store[$name]= $object;
return $return;
}
static public function get($name)
{
if (!self::contains($name)) {
throw new Exception("Object does not exist in registry");
}
return self::$_store[$name];
}
static public function contains($name)
{
if (!isset(self::$_store[$name])) {
return false;
}
return true;
}
static public function remove($name)
{
if (self::contains($name)) {
unset(self::$_store[$name]);
}
}
}
I know, Registry could be a Singleton, so you never have two Registry at the same time (who needs them someone could think, but who knows).
Anyway the externally way of storing/accessing instances is like this:
$read = new DBReadConnection;
Registry::set($read);
$write = new DBWriteConnection;
Registry::set($write);
// To get the instances, anywhere in the code:
$read = Registry::get('DbReadConnection');
$write = Registry::get('DbWriteConnection');
And internally, inside the class (taken from the book) when getInstance is called:
abstract class DBConnection extends PDO {
static public function getInstance($name = null)
{
// Get the late-static-binding version of __CLASS__
$class = get_called_class();
// Allow passing in a name to get multiple instances
// If you do not pass a name, it functions as a singleton
$name = (!is_null($name)) ?: $class;
if (!Registry::contains($name)) {
$instance = new $class();
Registry::set($instance, $name);
}
return Registry::get($name);
}
}
class DBWriteConnection extends DBConnection {
public function __construct()
{
parent::__construct(APP_DB_WRITE_DSN, APP_DB_WRITE_USER, APP_DB_WRITE_PASSWORD);
} }
class DBReadConnection extends DBConnection {
public function __construct()
{
parent::__construct(APP_DB_READ_DSN, APP_DB_READ_USER,APP_DB_READ_PASSWORD);
}
}
Apparently referring to the registry indirectly (second case) seems more scalable for me, but what if some day I would need to change the registry and use another implementation, I would need to change that calls to Registry::get() and Registry::set() inside the getInstance() method in order to suit the changes or is there a smarter way?
Did someone of you came across this problem and found an easy way to interchange different registries depending on the type of application on the complexity etc.?
Should be a configuration class the solution? Or is there a smarter way to achieve a scalable registry pattern if it is possible?
Thanks for the attention! Hope for some help!
First of all. It's great that you spotted the problem of your approach by yourself. By using a registry you are tight coupling your classes to the registry where you pull your dependencies from. Not only that, but if your classes have to care about how they are stored in the registry and get grabbed from it (in your case every class would also implement a singleton), you also violate the Single-Responsibility-Principle.
As a rule of thumb keep in mind: Accessing objects globally from within a class from whatever storage will lead to tight coupling between the class and the storage.
Let's see what Martin Fowler has to say about this topic:
The key difference is that with a Service Locator every user of a service has a dependency to the locator. The locator can hide dependencies to other implementations, but you do need to see the locator. So the decision between locator and injector depends on whether that dependency is a problem.
and
With the service locator you have to search the source code for calls to the locator. Modern IDEs with a find references feature make this easier, but it's still not as easy as looking at the constructor or setting methods.
So you see it depends on what you are building. If you have a small app with a low amount of dependencies, to hell with it, go on with using a registry (But you absolutely should drop a classes behavior to store itself into or getting grabbed from the registry). If that's not the case and you are building complex services and want a clean and straightforward API define your dependencies explicitly by using Type Hints and Constructor Injection.
<?php
class DbConsumer {
protected $dbReadConnection;
protected $dbWriteConnection;
public function __construct(DBReadConnection $dbReadConnection, DBWriteConnection $dbWriteConnection)
{
$this->dbReadConnection = $dbReadConnection;
$this->dbWriteConnection = $dbWriteConnection;
}
}
// You can still use service location for example to grab instances
// but you will not pollute your classes itself by making use of it
// directly. Instead we'll grab instances from it and pass them into
// the consuming class
// [...]
$read = $registry->get('dbReadConnection');
$write = $registry->get('dbWriteConnection');
$dbConsumer = new DbConsumer($read, $write);
Should be a configuration class the solution? Or is there a smarter way to achieve a scalable registry pattern if it is possible?
That approach is encountered very often and you maybe have heard something about a DI-Container. Fabien Potencier writes the following:
A Dependency Injection Container is an object that knows how to instantiate and configure objects. And to be able to do its job, it needs to knows about the constructor arguments and the relationships between the objects.
The boundaries between a service locator and a DI-Container seem to be pretty blurry but I like the concept to think about it like that: A Service Locator hides the dependencies of a class while a DI-Container does not (which comes along with the benefit of easy unit testing).
So you see, there is no final answer and it depends on what you are building. I can suggest to dig more into the topic since how dependencies are managed is a core concern of every application.
Further Reading
Why Registry Pattern is antipattern. And what is alternative for it.
Service Locator is an Anti-Pattern
Do you need a Dependency Injection Container?
Sometimes when I look at code other people have written I see something like the following:
<?php
namespace sys\database;
class Statistics {
public function __construct() {
// Database statistics are gathered here using
// private methods of the class and then set to
// class properties
}
public static function getInstance() {
return new \sys\database\Statistics();
}
// ...
}
So the static function getInstance() simply returns an object of the class it belongs to. Then, somewhere else in the code I come across this:
$stats = \sys\database\Statistics::getInstance();
Which simply sets $stats to an instance of the Statistics object, ready for its class properties to be accessed to get various database statistics.
I was wondering why it was done this way as opposed to just using $stats = new \sys\database\Statistics();. At the end of the day, all the logic to gather statistics is in the constructor and the getInstance() method doesn't do anything other than returning a new object.
Is there something I'm missing here?
This is supposed to be an implementation of the Singleton pattern: http://www.oodesign.com/singleton-pattern.html
The pattern is used to never allow more than one instance of the class to be created.
However, there are a couple of flaws with the implementation you provided: the constructor should be private, and there should be a single private static instance of the class, returned every time the getInstance method is called.
This is supposed to be an implementation of the Singleton pattern, which is a term used to describe a class which can only exist once for run-time.
It seems the implementation you have is flawed however because:
there is no check to see if the class exists yet and
code can create multiple instances by calling the constructor directly (it should be made private)
That's a [bad] implementation of the Singleton pattern.
As a rule of thumb, you should avoid such pattern in favour of more convenient Dependency Injection, for instance.
I'm trying to learn when static functions should be used, and have had a difficult time finding an answer my questions. I am creating a class User, which is related to a class Group. If I have a user id and I want to get a user object from that, is it better to do something like
$existingUser = User::get($userId);
where the class is defined like this
class User()
{
public static function get($id){
$user = new User();
return $user->findById($id);
}
public function findById($id) {
//find and populate user object
}
}
or
$existingUser=new User();
$existingUser->findById($userId);
where the class is defined like this
class User()
{
public function findById($id) {
//find and populate user object
}
}
What about if I were to write a function which returns an array of Group objects based on a user id?
class User()
{
//stuff
$groupArray = Group::getAllByUserId($this->getId())
//stuff
}
or
class User()
{
//stuff
$group = new Group();
$groupArray = $group->findAllByUserId($this->getId());
//stuff
}
The second method creates an empty group object which is never used. Does it matter?
Am I misunderstanding the concept of static? I know it is useful for not having to instantiate a class, so if the function instantiates one anyway, does that kind of defeat the purpose? If so, what would be an example of when a static function would be used?
Anything else I should be considering in this over simplified example?
You don't need a static function int he case you show above.
Static functions are really just global functions with a namespace.
Use them when the global state of the application needs to be controlled, or if multiple copies of the function lead to inonsistant results.
Callbacks sometimes need to be static, especially if they are passed as a string.
I'm trying to learn when static functions should be used
Oh, it's so simple: never.
To understand it, read:
http://www.objectmentor.com/resources/articles/ocp.pdf
http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/
I find a good rule of thumb is thinking "If I don't have a [class-name], would I expect to be able to call [method-name]?"
If I don't have a user, would I expect to be able to call findByID?
Probably not. This is one of the exceptions I come across; a "load" or a "save" method sometimes makes sense to be static.
A perfect example of when to use non-static methods is (most methods in) a Database class - you should always have a database object before you try to run a query on it.
An example of when to use a static method would be a "helper" class, essentially a collection of handy functions. Say you have some methods that help you output HTML, you might have HTML::image(), HTML::url() and HTML::script(). On these, you shouldn't need a HTML object to create an image, URL, and so on.
As for stopping multiple copies of objects being created (one argument for using static methods), you should use a Singleton pattern instead (Google it) to ensure only one copy of the object ever exists.
You should probably check out this question on Active Record vs data mapper:
https://stackoverflow.com/questions/2169832/data-mapper-vs-active-record
One take from this question is that static methods on the class for loading/saving aren't really the core functionality of the class in most cases. Further, storing and loading is a kind of abstract concept that is separate from your class objects in most cases.
Isa "user" a data storage and retrieval object? In most cases, no, it is a person represented in your system that has various properties and functions. When you start tying the persistence of that object into the object, you break encapsulation and make it harder to maintain the code. What if next week you want to load your users out of memcache? It's hardly relevant to if a user can have some property or functionality.
Recently, I saw a colleague of mine instantiate his classes in a constructor, so I started doing the same, like this:
class FooBar{
private $model1;
private $model2;
public function __construct() {
$this->model1=new Model1();
$this->model2=new Model2();
}
}
And now I'm starting to wonder, if maybe instantiating the models everywhere where they are needed may be better?
E.g., function foo() needs model1 and function bar() needs model2, but now both models are loaded.
So, the question: Is this the right way to instantiate other classes? Or should I just instantiate them when I need them in a function?
Well, as always there is no one size fits all answer.
Most of the time, class FooBar aggregates $model1 and $model2 because it needs them to fulfill its function. In this scenario there's not much that FooBar can do unless it has objects in these variables, so it's the right thing to do to create them in the constructor.
Sometimes an aggregate object is not needed to perform a large part of class FooBar's function, and the construction of that object is an expensive operation. In this case, it makes sense to only construct it on demand with code like the following:
class FooBar {
private $model1;
private $model2;
public function Frob() {
$model = $this->getModel1();
$model->frob();
}
private function getModel1() {
if ($this->model1 === null) {
$this->model1 = new Model1;
}
return $this->model1;
}
}
However, that's only sometimes. If class FooBar needs $model1 for half of its operations and $model2 for the other half, this may indicate that FooBar is suffering from a case of "let's throw everything inside one class" and should be split into two classes instead.
I would like to see these dependencies injected into the constructor as parameters.
You should actually be loading them when you need them otherwise a whole bunch of models that are not required (which may have their own constructors with more models loading!) will pop into memory every time you need a trivial operation done.
Don't create a new model unless you're sure you will be using them (e.g. models needed to localize and such)
It is not exact science, and you should follow your instincts in how to organize the code.
If this approach gets unmaintainable, or you want to unit test it, dependency injection might come to the rescue.
But if you're doing simple scripts and development time is an important factor, the way you're doing it now is sufficient.
I need to clear some OOPS concepts in PHP.
Which is faster $this->method(); or self:method();
I know the concept of static keyword but can you please post the actual Use of it. Since it can not be accessed by the instance, but is there ant benefit for that?
what is factory? How can i use it?
What is singleton? How can i use that?
What is late static binding?
http://www.php.net/manual/en/oop5.intro.php
I have gone through below link but I am not getting clear with it.
1) Which is faster $this->method(); or self:method();
I set up a simple loop which calls the same method 1,000,000 times using both methods and the results are pretty much equal (in reality -> was slightly faster but by an extremely short margin)
2) I know the concept of static keyword but can you please post the actual Use of it. Since it can not be accessed by the instance, but is there ant benefit for that?
What do you mean not accessed by the instance?
public static $x;
public static function mymethod() {};
can be accessed through self::$x and self::mymethod().
There are multiple uses of static members, none of them very nice. They can be used to create singleton objects, the can be used to invoke class methods without needing to instantiate the class (for something like a bootstrap object)
3) what is factory? How can i use it?
Factories are objects used to abstract code needed to instantiate objects of a similar type. For example if you have a website which uses a hierarchy of users, each user level might have its own class. Fundamentally all the user classes will be created in the same way but there may be one or two class specific actions required.
A factory object would contain all this instantiation code and offer a simple interface to the developer. So you could use $oFactory->createUser() and $oFactory->createManager() instead of repeating yourself in multiple areas of your code.
4) What is singleton? How can i use that?
A singleton is a class that can have one and only one instance at any one time. The basic idea is that you would use a static method and a static variable to check if the object has already been instantiated.
You would use a singleton where it is important to only have one instance of a class, for example a security model may be a singleton since you want to make sure that there is only one place in your code responsible for authenticating users, a database abstraction could be a singleton if you only require one db connection (it wouldn't make sense to keep connecting to the same server and the same database for each query)
Pre-PHP5.3 singletons have some fundamental flaws since the absence of late static binding means that you can't easily extend a base singleton class.
5) What is late static binding?
Late static binding is a delay in class resolution for static methods to improve their use in OO (derived classes in particular). LSB allows self:: or __CLASS__ to resolve to the current class now instead of the class that they are defined in.
For example in earlier versions of PHP....
class parentClass {
public static function someMethod() {
echo( __CLASS__ );
}
}
class childClass extends parentClass {
}
$oObject = new childClass();
$oObject::someMethod();
would output parentClass to the browser, using LSB childClass would be output.
This is useful for many things including singletons, since the class is resolved properly it is now possible to define a singleton base class and have other objects extend it with expected results.
2) Static Key word: Unlike the methods
and data members used in OOPS where
the scope is decided by access
specifiers, the static
methods/attributes are available as a
part of the class. So it is available
to all the instance defined for the
class. To implement static keyword
functionality to the attributes or the
methods will have to be prefix with
“static” keyword. To assign values to
static variables you need to use scope
resolution operator(::) along with the
class name.
example:
< ?
class ClassName
{
static private $staticvariable; //Defining Static Variable
function __construct($value)
{
if($value != "")
{
ClassName::$staticvariable = $value; //Accessing Static Variable
}
$this->getStaticData();
}
public function getStaticData()
{
echo ClassName::$staticvariable; //Accessing Static Variable
}
}
$a = new ClassName("12");
$a = new ClassName("23");
$a = new ClassName("");
?>
Output:
12
23
23
Explanation:
* Here i have declared static variable $staticvariable
* In the constructor i am checking and value and then assigning the value
to the static variable
* Finally the getStaticData() method will output the static variable
content
1) Which is faster $this->method(); or self:method();
Answer: "self" (not $self) refers to
the type of class, where as $this
refers to the current instance of the
class. "self" is for use in static
member functions to allow you to
access static member variables. $this
is used in non-static member
functions, and is a reference to the
instance of the class on which the
member function was called.
Because "this" is an object, you use
it like: $this->member Because "self"
is not an object, it's basically a
type that automatically refers to the
current class, you use it like:
self::member
What is singleton? How can i use that? php
In software engineering, the singleton pattern is a design pattern used to implement the mathematical concept of a singleton, by restricting the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects (say, five). Some consider it an anti-pattern, judging that it is overused, introduces unnecessary limitations in situations where a sole instance of a class is not actually required, and introduces global state into an application
Example:
final class Singleton
{
protected static $_instance;
private function __construct() # we don't permit an explicit call of the constructor! (like $v = new Singleton())
{ }
private function __clone() # we don't permit cloning the singleton (like $x = clone $v)
{ }
public static function getInstance()
{
if( self::$_instance === NULL ) {
self::$_instance = new self();
}
return self::$_instance;
}
}
$instance = Singleton::getInstance();
5) What is late static binding?
Refer: Late Static Binding
What Is Factory?
refer Design Pattern
I have gone through below link but I
am not getting clear with it.
The official documentation is rich and comprehensive but some users find it hard to understand. If you are unable to grasp that, I would suggest you to go through this excellent tutorial at phpro.org (a great great resource on php topics):
Object Oriented Programming with PHP
The tutorial has been written in simple language with good real world examples, very helpful to those having problem in understanding the OOP concepts.
You are asking a pretty general question. Those are really basic concepts, so you should try to research a bit further, using also general OOP tutorials and reference.
Just to provide some hints: most of your question refer to the concept of "static". You need to understand the difference between a Class and an Instance of a class. This is the key concept.
A Class is the blueprint to create an instance. You have only one Class, but multiple Instances of it. To create an instance you use the "new" keyword, and give a name to the instance ($x = new A()); But you can have methods and fields which do not require a class instance to be run or accessed. The Class holds them, they are above any instance, they can not access any properties or methods which are not static themselves. They are useful because they can hold data and functions which are global (if you have a static variable, it'll be the same across the entire execution, wherever it is called).
I would strongly recommend you to read a couple a book on the subject. I would personally recommend PHP Object-Oriented Solutions by David Powers. This is in my opinion the best introduction to Object-Oriented coding in PHP for newcomers. You need the core knowledge before you can deploy programming patterns efficiently.
If you are really looking to understand design patterns, i would recommend Design Patterns by Christoffer G. Lasater. I've struggled to understand some of these patterns myself, and he explains them in a reasonable understandable way for the average programmer. It is written for Java, but the differences are not really that big.