My previous thread started this discussion, but having refined the issue, I figured it warranted a new thread.
I'm having difficulty coming up with a logical and functional class hierarchy for a system, and I was wondering if someone could point me towards some resources where I could find more information, or provide some insight on how I could develop this.
I was interested in creating a system where I have a single Factory/Supervisor class, responsible for designating object instantiation of Widgets, as well as controlling global parameters that affect all Widget objects it instantiates.
The design restrictions/conditions I was trying to adhere to would be:
- The Factory class can not be instantiated and it's properties/methods are static. If a design concept has it functioning as an instantiated singleton, that would work fine as well.
- The Factory and only the factory needs to be responsible for global parameters (via Factory::setParam($args) or Factory::importParams($args), etc.) whereas the Widgets need only read the parameters (via Factory::getParam($args);).
- The Widgets (say 3 or more different types) cannot be explicitly instantiated outside of the creation methods of the Factory. (Example: $widget = Factory::createWidget($args); instead of $widget = new Widget($args);)
- The different Widgets would extend a BasicWidget to inherit general functionality.
My problem with this design is that I don't want to have:
- The Widgets inheriting Factory specific methods/properties such as setParams() or createWidget().
- The Widget's __construct($args) method making use of debug_backtrace() or another process intensive function to determine the calling method/class for instantiation restriction. Whatever keeps it running fastest.
My attempts thus far result in either of the "don't want" cases. It seems to me there must be an approach that satisfies these conditions. I posted something regarding this before, but I've refined the problem now, and hopefully someone can point me in the right direction.
Design Patterns
Moderator: General Moderators
Re: Design Patterns
Continuing the idea from the other thread, I was subtly suggesting that you put the factory methods in the Widget class instead of in their own class.
Code: Select all
abstract class WidgetBase{
protected $myProperty1;
protected $myProperty2;
protected function myMethod(){ ... }
protected static $params = array();
public static function createWidget1($args){
return new Widget1($args);
}
public static function createWidget2($args){
return new Widget2($args);
}
}-
tomcatexodus
- Forum Newbie
- Posts: 9
- Joined: Thu Apr 08, 2010 9:42 pm
Re: Design Patterns
I've reconsidered my approach, and I've gone with a design similar to what you've suggested here tasairis. Now I have this question;
The design has objects that contain references to other objects.
Eg:
Would the best design approach be to have the constructor take an argument that is the parent widget? (This is what I'm doing now)
Eg:
Or should the widgets be responsible for creating the children widgets themselves?
Eg:
Which is considered a better design approach?
The design has objects that contain references to other objects.
Eg:
Code: Select all
class Widget{
protected $widgets = array(); //contains other widgets
}
Eg:
Code: Select all
class Widget{
protected $widgets = array(); //contains other widgets
public __construct($args, $parentWidget = NULL){
if(!is_null($parentWidget)){
$parentWidget->widgets[] = &$this;
}
.
.
.
}
}
$parentWidget = new Widget($args);
$childWidget = new Widget($args, $parenWidget);Eg:
Code: Select all
class Widget{
protected $widgets = array(); //contains other widgets
public __construct($args){
.
.
.
}
public newWidget($args){
$newWidget = new Widget($args);
$this->widgets[] = &$newWidget;
return $newWidget;
}
}
$parentWidget = new Widget($args);
$childWidget = $parentWidget->newWidget($args);Re: Design Patterns
Depends. Can Widgets be reassigned to a different parent? If so then make a separate method for that and have the parent (1) construct and (2) assign to itself. Otherwise have the factory do the construction, passing in the parent at that time.
Then there's the question of whether the parent takes a child or the child gains a parent - that is, $child->ownedBy($parent) versus $parent->own($child)...
Then there's the question of whether the parent takes a child or the child gains a parent - that is, $child->ownedBy($parent) versus $parent->own($child)...