Download the PHP package kael-shipman/factory without Composer
On this page you can find all versions of the php package kael-shipman/factory. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download kael-shipman/factory
More information about kael-shipman/factory
Files in kael-shipman/factory
Package factory
Short Description A class that provides overridable instantiation of classes through declarative method calls.
License GPL3
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package factory
Factory
DEFUNCT
This project is not useful anymore. For purposes of useful type-checking, Abstract Factory Classes should use explicit method names for instantiation, rather than string-based instantiation. This fact negates any benefit that this class once offered.
For those who came here hoping to find a solution to their instantiation woes, the correct answer is something like this:
You can use this same technique to execute static methods, get static class constants, etc. The line is blurry about what you should actually implement within the Factory class, but you can feel that out yourself.
A class that provides overridable instantiation of classes based on text descriptors rather than concrete class names.
If you don't know about Dependency Injection, there are plenty of resources on the internet about it. Please make sure you understand what this is for before using it.
The short version is that you should find a way to allow yourself and other programmers to change what concrete implementation of the requested functionality is being used at any given time without having to change the code that uses it.
I've chosen to implement this by creating a Factory class that is passed on construct to all of my other classes. When one of my objects needs to create a child object, it tells the factory what it wants, giving it the parameters it wants to be passed into the constructor, and the Factory gives it an instance of some class that was defined by the programmer when the application was configured.
The program itself won't always know what actual class of object this is, and in fact shouldn't care. What it should care about is that whatever object it gets back implements the interface it's expecting.
Usage
Here's a basic example of how this should be used (implementation is below):
This is an extremely high-level example, but it demonstrates that
- you tell the factory what type of object you want (my implementation actually also allows for subtypes); and
- you verify that the instance that you get back implements the interface you're expecting.
You'll usually find more complex examples of this further inside the code. Consider this:
In the above example, we used the factory to instantiate a collection, then used its special "create" method (which only works for classes that implement a static "create" method themselves) to "restore" instances of Things from data. This worked because somewhere, you told your factory what class represented a "collection of things", and what class represented a "thing".
You did that by....
Creating Your Type Map
In the above examples, we requested an object of type app, an object of type collection with subtype things, and several objects of type thing. But the factory isn't born knowing how to create these objects. You have to tell it. And you do this by subclassing Factory and overriding the getClass method.
To create a factory that can instantiate all these objects, here's what we do:
Sometimes you'll put this in a separate file. More often, though, this can go right in your front controller (usually index.php in a web app).
If you're writing something that someone may extend, it's a good idea to put your custom factory in its own class file. That way, someone else can extend it and avoid having to remap all the objects you've already mapped.
Conclusion
That's it! Hope it's useful to someone.
