Code: Select all
abstract class Model {
public function save() {
/* Save data */
}
public function delete() {
/* Delete a record */
}
}Code: Select all
class ArticleModel extends Model {
...
}Moderator: General Moderators
Code: Select all
abstract class Model {
public function save() {
/* Save data */
}
public function delete() {
/* Delete a record */
}
}Code: Select all
class ArticleModel extends Model {
...
}Code: Select all
$old = new OldObject(); // Implements older functionality
$new = new NewObject($old); // Delegates older functionality as well as implementing newer functionalityThe decorator pattern may be suitable.PCSpectra wrote:Decorator pattern?
Code: Select all
$old = new OldObject(); // Implements older functionality $new = new NewObject($old); // Delegates older functionality as well as implementing newer functionality
Code: Select all
$article = Article::findOne( 3 );
$articles = Article::findAll();Code: Select all
public static function findOne {
// executing the database query
// creating the model instance
$model = Factory::create( get_class( self ) );
// ...
return $model;
}I think most 'finders' are typically factories or service locators, anyways. I would personally do with that approach, it results in more extensible code complying with OCPBut I use finders to create the model objets :
Languages that allow that are called prototypical based inheritance. That is possible with anonymous functions and __call()Neuromancer2 wrote:I would like to add functionalities to my models in a flexible manner and so that I would be able to reuse them (publication, trash bin, translation...). I already have a event system based on the observer pattern which allow me to attach listeners to an object. It's quite useful but I need the ability to add new operations to existing object. I am wondering what kind of approach/pattern would be more suitable.
Code: Select all
function __construct( Status $status )
{
$this->status = $status;
}
http://www.laputan.org/drc/drc.htmlInheritance vs. decomposition
Since inheritance is so powerful, it is often overused. Frequently a class is made a subclass of another when it should have had an instance variable of that class as a component. For example, some object-oriented user-interface systems make windows be a subclass of Rectangle, since they are rectangular in shape. However, it makes more sense to make the rectangle be an instance variable of the window. Windows are not necessarily rectangular, rectangles are better thought of as geometric values whose state cannot be changed, and operations like moving make more sense on a window than on a rectangle.
Behavior can be easier to reuse as a component than by inheriting it. There are at least two good examples of this in Smalltalk-80. The first is that a parser inherits the behavior of the lexical analyzer instead of having it as a component. This caused problems when we wanted to place a filter between the lexical analyzer and the parser without changing the standard compiler. The second example is that scrolling is an inherited characteristic, so it is difficult to convert a class with vertical scrolling into one with no scrolling or with both horizontal and vertical scrolling. While multiple inheritance might solve this problem, it has problems of its own. Moreover, this problem is easy to solve by making scrollbars be components of objects that need to be scrolled.
Most object-oriented applications have many kinds of hierarchies. In addition to class inheritance hierarchies, they usually have instance hierarchies made up of regular objects. For example, a user-interface in Smalltalk consists of a tree of views, with each subview being a child of its superview. Each component is an instance of a subclass of View, but the root of the tree of views is an instance of StandardSystemView. As another example, the Smalltalk compiler produces parse trees that are hierarchies of parse nodes. Although each node is an instance of a subclass of ParseNode, the root of the parse tree is an instance of MethodNode, which is a particular subclass. Thus, while View and ParseNode are the abstract classes at the top of the class hierarchy, the objects at the top of the instance hierarchy are instances of StandardSystemView and MethodNode.
This distinction seems to confuse many new Smalltalk programmers. There is often a phase when a student tries to make the class of the node at the top of the instance hierarchy be at the top of the class hierarchy. Once the disease is diagnosed, it can be easily cured by explaining the differences between the instance and class hierarchies.