i've got 3 Log classes that all implements iLog interface:
DatabaseLog
FileLog
ScreenLog
there can only be one instance of them. initially i though of using single pattern for each class but then i thought why not use a factory for instantiation instead, cause then i wont have to create single pattern for each one of them and for all future Log classes.
and maybe someone would want them as multiple objects in the future.
so my questions is: should i use factory or singleton pattern here?
Where should responsibility for creating the Logger instance reside? With each class that wants to log? With some kind of supervisory component that understands the overall context?
I think it's more likely to be the latter, and hence a Factory will make sense. The faactory can have all the logic for deciding which kind of logging is needed.
The singleton and the factory pattern serve completely different purposes. This singleton-pattern is used to ensure that there is only ever one instance of a class. The factory-pattern is used to abstract object instantiation. You can use a factory to create a singleton, and factories themselves often are singletons, but there is no one vs the other. They are complementary rather than opposed patterns.
In your case, implementing the singleton-pattern makes sure you can have only one instance of each class. You can use a factory that does not create new instances if one already exists.
If you have an interface for logging, and several implementations for it (e.g. logging to file or logging to network), you can use a factory to instantiate the implementations dynamically, and hide the instantiation process, which might differ for each implementation (e.g. open a file or open a socket). You can still make your objects singletons if that is what you want.
Well if someone might want to create multiple objects of these types, then singleton is clearly out of question.
Create a factory that reads the type of the log from a config file (maybe) and return a ILog reference to the concrete type
Like others stated, I would also suggest using a factory. One advantage when not using Singletons is that you have no global state thus making your code much more testable.
I'd use a factory here, a singleton can't satisfy your requirement of one instantiation between all three classes.
Related
I have a number of Soap Server classes most of which will need to implement 3 methods:
ping() // something to bounce a signal off to prove it has been reached
getCredentials($creds) // credentials to check sets session value
getCaller() // for logging, uses session value
As they form part of the WSDL defn they need to be public.
I am fairly sure this (I have christened it a Soaplogin) would need to be an abstract class (because it must never be instantiated on its own)
The concrete classes which extend then this core then have their own methods, none of which are shared.
I am searching for the best type of Pattern to use and am getting a bit confused, though I think a Template Method just about fits the bill - but I could just plain extend the SoapLogin class.
What advice can you give me on the best pattern to use, and maybe a preferred name for this class.
(while this uses ZF1 components it does not use full blown MVC - in case that was of importance)
Prefer composition over inheritance.
What you really do is you create completely independent interfaces that only by chance happen to have the same methods.
Fine. Generic methods that always do the same - that should be in a class of it's own. But not ONE class for all these methods! One class per method!
You can then add all these method classes to your server classes, and also add all the special functions the same way.
That way you can combine any of the generic functions in any way, and add another only to one API if needed.
This pattern could be a good solution if you just want to create several soap connect.
An other one could be to use interface. It will tell your program that every class that implements SoapItf (for example, rename it if you want) are able to perform soap method.
If you look for an evolutive application, maybe you'll need to connect with Rest webservice after so you can create an abstract class Werbservice, two class Soap and Rest that extends it and this two class implements interface SoapItf ans RestItf respectively.
This method helps using polymorphism, an important concept in OOP.
In this case I can add method to Soap or Rest without changing both.
After that if you have specificity with Soap like in your example, you could extends Soap class. It will be easier to evolve the application and using package architecture (interesting if you work with namespaces)
In my opinion, you can use template pattern to manage a common resource that is spreadable in sub-classes. For instance, you have a soaplogin common abstract class and that might have some resource that can be used by most of the sub-classes. Then it's better to manage that resource in super-class and pass the callback in subclass to use the resource of the super-class. Advantage is that you are managing resource at a single place.
For example, I have a common resource in my super-class. I can create a callback passing resource as a parameter.
interface ResourceCallback {
T call(Resource resource);
}
Then can define a abstract method in super-class like as doWithResource(ResourceCallback callback) and all the subclass can now use the resource with their own implementation of their methods.
Consider Martin Fowler's Patterns Of Enterprise Application Architecture, and the pattern of Front Controller: http://martinfowler.com/eaaCatalog/frontController.html
Apparently, it uses the singleton pattern. Well, I have a package of classes in php application that work together (like Zend's Controller Package) and there is one class that makes them all usable and since it resembles much of Front Controller's concepts, I named it PackageName_Front. But it shouldn't be a singleton class (as opposed to Front Controller), so do I still let it have the name Front? If not, what do I name it?
Since it's a quite big package, I just need it to follow conventions as much as possible (not in a dogmatic way!) so it would be readable to other developers.
More info: It's not anything related to controllers. It's just an object that works like Zend_Form (which consolidates use of all the other objects like Zend_Form_Element_X and Zend_Validate into one object) But I can't just name it PackageName. It has to be PackageName_Something, and I'm just not sire what Something should be. Maybe "Handler"?... I just wanna make sure when someone reads it's name, doesn't get confused about it's role in the whole Package :)
Apparently, it [FrontController] uses the singleton pattern.
FrontController does not have to be implemented as Singleton. The book does not suggest anything like this. The example in the book uses a Servlet for the Handler.
Just because a class will only be needed once in an application doesnt justify it's implementation as a Singleton. It's missing the purpose of the Singleton which is to enforce a class can only have one instance and provide global access to it. If you need a particular instance only once, consider Just Create One instead.
Many people nowadays (including Erich Gamma of GoF fame) view the Singleton as a code smell and discourage it's use. In a shared-nothing-architecture the Singleton can only restrict instances inside the current request anyway, so the use in PHP is limited. Global access to an object can be achieved without the Singleton pattern, either through the (evil) global keyword or static methods. Global access always creates unneeded coupling. The better way would be to use Dependency Injection, which has the added benefit of providing less coupling and thus better maintainability.
so do I still let it have the name Front? If not, what do I name it? Since it's a quite big package, I just need it to follow conventions as much as possible (not in a dogmatic way!)
There is no such convention about naming classes Front classes to my knowledge. What you describe could be a Facade or a Gateway though. Also, are you sure you cannot name the class after the PackageName? After all, the Zend_Form package has a Zend_Form class, too.
Just from a purely design view, it sounds like you're using that PackageName_Front as a Facade when you say:
there is one class that makes them all
usable
Fowler's implementation of the pattern says:
The Front Controller consolidates all
request handling by channeling
requests through a single handler
object
This insinuates that a Singleton might be used to implement the Front Controller class, but it certainly doesn't constrain it to use it. He doesn't explicitly mention it though.
I don't think it's important whether or not its a Singleton. Just makes sure its the sole channel for requests, and you'll have successfully used the pattern. :)
The idea behind the singleton pattern is to make sure there is only one instance of an object that is supposed to only exist in a single instance. The front controller falls very well into this category, so it would, perhaps, be wise to make it follow a singleton pattern.
If, however, your code will always make sure it calls the constructor only once, then there is room for your non-singleton pattern object.
My 2 cents here, since I'm not any book author or something.
I have am working on a web application that makes use of helper classes. These classes hold functions to various operation such as form handling.
Sometimes I need these classes at more than one spot in my application, The way I do it now is to make a new Object. I can't pass the variable, this will be too much work.
I was wondering of using singleton classes for this. This way I am sure only one instance is running at a time.
My question however is when I use this pattern, should I make a singleton class for all the objects, this would b a lot of code replication.
Could I instead make a super class of superHelper, which is a singleton class, and then let every helper extend it.
Would this sort of set up work, or is there another alternative?
And if it works, does someone have any suggestions on how to code such a superHelper class.
Thank you guys
I can't pass the variable, this will be too much work.
Are you sure though? People tend to overestimate the effort of passing around dependencies. If you do it in the constructor, it's usually fairly simple to do.
That said, you can put shared functionality in the global scope, in different ways in php. The simplest is to use a global function. Eg. a function that doesn't belong to any class. Another option is to use a static class method. These two a very similar; except for their syntax, they essentially have the same properties. A slightly looser coupled solution is to put the functionality as a method on an (abstract) base class, that your concrete class extends from. This shares the functionality between all child classes.
Common for the above-mentioned solutions is that they have a compile time coupling. You can't change the dependency at run time, which makes your application rather rigid. Their main benefit is the low level of complexity they carry.
If you want a looser coupled application, you can try to replace the hard dependency with a variable, to give a level of indirection. The simples is to create an object and make this shared globally throughout the application. There are a number of ways to do this in PHP, such as a singleton or simply a variable in the global scope (You can access this with the global keyword, or through the $GLOBALS array).
While global variables offer a level of indirection, they also tend to introduce a lot of complexity, since they make it very hard to figure out which parts of the application that depends on each other. For this reason, they are often avoided by experienced programmers. This is especially true if the variable has state; The problem is less prevalent if the shared object is stateless.
The only way to avoid the perils of global variables, is to use local variables instead. Eg. To pass the dependencies around. This can be a bit of a hassle, but in my experience it's often not as big a problem as it's made out to be. At least, the benefits often outweigh the problems. That said, there are techniques to easy the pain; Notably dependency injection containers, which are automatic factories that take care of all the wiring for you. They come with their own level of complexity though, but for larger applications they can certainly be a good solution.
Look into the factory pattern and dependency injection.
http://www.potstuck.com/2009/01/08/php-dependency-injection/
You can't extend a singleton class. Remember in singleton class we make the constructor private so if a constructor is private than how could you extend this class? We all know what we create an object of a class we call its constructor and in child class constructor it implicitly called the parent constructor. So in this scenario a private constructor can't be called in the child class.
While sometimes necessary, singletons are evil (because they're global state). Try to avoid them if you can help it.
EDIT: If you can't avoid singletons, at least parameterise the reference to that state. In other words, in a class, pass in the singleton to its constructor or those methods that use the singleton.
Simply making references all over your codebase to your singleton will compromise your ability to test classes in isolation.
If your singleton's stateful, your tests will suddenly become stateful, and your tests can start "cascade failing" because their preconditions become corrupted by earlier tests failing.
I'd like to:
Make commonly required services visible to all classes that need them,
with a minimum of boilerplate, and
without sacrificing testability!
It's a small project and I think DI might be overkill, but maybe I'm wrong? Anyhow, I have been focusing on the ServiceLocator pattern as described by Martin Fowler
In a client class' constructor, I have something like this:
this->db = Locator::getDb();
this->log = Locator::getLogger();
Then the rest of the class' methods access the service through those member attributes, e.g.:
this->fooModel = new fooModel(this->db);
fooItem1234 = this->fooModel->findById(1234);
However I would also like this level of visibility for "model" objects (like fooModel above) because they are accessed from several different places and there is no need to have more than one instance.
So my initial thought was to extend Locator to have a ::getFooModel() but now it seems I'm violating the Open/Closed Principle, since I'll have to modify Locator every time I introduce a new model class.
To satisfy OCP, I could use the Dynamic Service Locator (also described on Fowler's page) however I'm not totally sold on this for the same reasons as him, i.e. it's not explicit enough.
Another solution would be to just make all my models' methods static. So:
fooItem1234 = FooModel::findById(1234);
I like this because it's zero boilerplate. I can just create a new model class and start calling it from anywhere with a single line. But now the model depends on Locator to find its DB connection and I'm not sure how I feel about that. For one, if I ever needed to have two fooModels open on separate database connections, it would be a mess and/or impossible. That said, I don't actually need to do that currently so this option seems a little tempting.
Finally, there's DI. But like I said above I think it might be too much for this little project.
Conclusion: I'm a little stuck here and would appreciate some advice from the gurus of StackOverflow!
Why do you think that DI is overkill for your project? DI patterns such as Constructor Injection is way simpler and cleaner than Service Locator (which I consider an anti-pattern).
I consider Service Locator to be an anti-pattern since it is totally opaque to the user of the API which dependencies need to be in place; thus, one could easily invoke methods on your objects in a context where the Service Locator would throw, and the API gives you absolutely no clue that this is the case.
You don't need a DI Container to use DI. If just have a simple project, you can use what is known as Poor Man's DI where you wire up dependencies manually.
... and there is no need to have more than one instance.
You're mixing apples and oranges. The fact that you only need one instance of a class for an application, is not the same thing as it being a good idea to make that instance globally available. With DI you don't change the cardinality - there is still just one instance. What you change is the scope of variables that address said instance. There's a difference.
I'm experiencing what I believe is a circular dependency issue with my PHP application. Please let me know if this is incorrect. Here is the situation:
Two classes, LogManager and DBSession.
DBSession is used to interact with the database, and LogManager is used to log to files. Both are widely used in my application. When you create an instance of DBSession, you must give it an instance of LogManager via a constructor parameter. This because DBSession will sometimes log information to a file, and will use the LogManager instance to do this.
Now, I wanted to extend LogManager so that it could also log to a database table, rather than a text file. Naturally, my preference is to re-use existing classes, but I soon realized this brought about an interesting situation.
DBSession already requires an instance of LogManager for construction. If I want to re-use the DBSession class in LogManager, it will now require an instance of DBSession. How can I satisfy both demands? Clearly, something must be wrong with my approach.
How would you suggest I fix this?
Thanks in advance, guys.
Don't extend LogManager, let it be an aggregate type. And delay the choice of where you want to log, i.e.:
$logManager = new LogManager();
$dbSession = new DbSession($logManager);
$logManager->add(new FileLog($filename) );
$logManager->add(new DBLog($dbSession) );
Where of course FileLog and DBLog share a common interface.
This is an application of the Observer pattern, where add() is the "subscribe" operation, and FileLog/DBLog are the observers of logging events.
(In this way you could also save logs in many places.)
Owen edit: adjusted to php syntax.
One of these objects doesn't actually need the other: you guessed it, it's the DBSession. Modify that object so that the logger can be attached to it after construction.
Why demand a LogManager object for the creation of a DbSession object, if it only sometimes writes to files? lazy load it instead only when you need it. Also, in my opinion both should be independent from each other. Each could instance the other when needed.
Maybe you can apply some pattern, like the Singleton Pattern to ensure that you only have one instance of your LogManager class for example.