This is a good use of the decorator pattern. Let's say you don't like the
way Zend_Form_Element filters form names. You can decorate it with a Your
own class which overrides this, and whenever you add a new element to your
form, decorate it with this class.

On Sat, Mar 13, 2010 at 10:10 AM, Richard Quadling <rquadl...@googlemail.com
> wrote:

> On 13 March 2010 01:50, Chris Trahey <christra...@gmail.com> wrote:
> > Perhaps a new concept in class-based OO programming, I'm not sure.
> >
> > Depending on your perspective you could call it ancestor overloading (or
> > upstream overloading) or class underloading.
> >
> >
> > We are increasingly developing with the aid of frameworks & libraries. In
> > fact, this idea came from my current project using the Zend Framework.
> >
> > These libraries, while greatly extensible, are also fairly
> self-extending.
> > That is, they include many classes that extend many classes, which is
> great.
> >
> > As consumers of these libraries, we can extend the classes and consume
> the
> > API however we please, but there is one sticking point.
> >
> > We cannot change classes that many other classes extend without extending
> or
> > changing each child class and then making sure that our code uses the new
> > class.
> >
> >
> > For a concrete example, I was working with the Zend_Form_Element
> subclasses,
> > and I realized that I wanted to change some of the default behavior (in
> > Zend_Form_Element).
> >
> > - at this point I will assume the reader understands why I wouldn't want
> to
> > just start changing the Zend library files -
> >
> > There are many subclasses of Zend_Form_Element. If you want to change the
> > default behavior for all of them, you have 3 choices currently:
> >
> > 1. Directly edit the Zend_Form_Element file in the library, -bad for
> updates
> > & other projects that use the library
> >
> > 2. subclass Zend_Form_Element and change declaration of the descendants
> to
> > extend new class - same problems
> >
> > 3. extend each child class and implement those subclasses in your app
> code
> > -very tedious and TONS of repeated code, breaks consistency of API for
> > developers.
> >
> >
> > There could be a better way, if we could insert a class into the family
> > tree.
> >
> > And that's the heart of this idea, so I'll repeat it:
> >
> > * insert a class into the family tree *
> >
> >
> > Image we do it using an alternative keyword to "extends", such as
> > "overloads".
> >
> >
> > Example:
> >
> >
> > class Library_Class { }
> >
> > class Library_Subclass extends Library_Class {}
> >
> > and then:
> >
> > class My_LibClass_Overload overloads Library_Class{}
> >
> >
> > Now new instances of Library_Subclass actually extend
> My_LibClass_Overload,
> > which "extends" Library_Class. The developer would then code
> > My_LibClass_Overload as if it were declared like this:
> >
> > class Library_Class {}
> >
> > class My_LibClass_Overload extends Library_Class {}
> >
> > class Library_Subclass extends My_LibClass_Overload {}
> >
> >
> > But indeed the declaration of Library_Subclass would *not* have to
> change.
> >
> >
> > This way developers could "extend" default functionality and have
> *existing*
> > library classes pick up the new functionality without redeclaring
> anything
> > in the library.
> >
> > Downstream classes would still override any methods that they redeclare.
> If
> > you wanted to have end-point classes in the library have different
> behavior,
> > you would overload them instead, such as
> >
> > class My_LibSubclass_Overload overloads Lib_Subclass {}
> >
> >
> > The benefit is that the application code can still consume "standard"
> > classes, such as Library_Subclass and not need to know or care about the
> > extended functionality.
> >
> >
> > Going back to my concrete example, my code could then still use
> > Zend_Form_Element_Text, but benefit from the modifications I added,
> without
> > me having to touch the library code.
> >
> >
> > I hope I've explained clearly what this could look like. I'm a younger
> > developer, so forgive me if I'm rough on the terminology -perhaps
> > overload/underload is not the best word for this functionality. Also, I'm
> > not sure if there are other class-based OO languages that allow this kind
> of
> > behavior... Prototypal languages perhaps, as is the case with javascript
> and
> > the Obj.prototype which (combined with anonymous functions) allows you to
> > extend the "base" functionality of other objects that "extend" it.
> >
> >
> > Thank you for your comments and thoughts!
> >
> >
> > Chris Trahey
>
>
>
> I had exactly the same issue with Zend_Soap_AutoDiscover. This class
> uses Zend_Soap_Wsdl to create the WSDL file for a SOAP service.
>
> The class was hard coded. The AutoDiscover class allowed you to supply
> a class name to handle complex types, but not in conjunction with xsd
> scalar types. The Zend_Soap_Wsdl class handled php -> xsd types and
> read docblocks for that.
>
> But if the docblock had an xsd type (xsd:datetime, xsd:token, etc.)
> which are used to tell the consumer what the type is, then there was
> no way to get these in.
>
> So, I created this patch
> http://framework.zend.com/code/changelog/Zend_Framework?cs=21379 (diff
>
> http://framework.zend.com/code/browse/Zend_Framework/standard/trunk/library/Zend/Soap/AutoDiscover.php?r1=20096&r2=21379
> )
> which allows me to supply an alternative class name in a similar
> fashion to being able to supply a complex type handler class name.
>
> This was the easiest route I could find and the least impacting (full
> BC exists).
>
> The amendment I made to allow a subclass to be used as an alternative
> is a one off hit, so maybe this technique could be used for Zend_Form
> (I assume this is the class you are needing to amend).
>
> Regards,
>
> Richard.
>
> --
> -----
> Richard Quadling
> "Standing on the shoulders of some very clever giants!"
> EE : http://www.experts-exchange.com/M_248814.html
> EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp
> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
> ZOPA : http://uk.zopa.com/member/RQuadling
>
>

Reply via email to