Enable documentation for patterns

[augustohp]

Would be awesome to document Design Patterns as we talked earlier. Using an annotation on the method or class that is the key point of a pattern could work well. And if somehow we could trace the dependencies of that pattern and put them into the method/class section would be beautiful.

[alganet]

Anyone willing to research a little bit on popular PHP projects like PHPUnit and Symfony and put up a list of commonly used patterns that would benefit us?

[iannsp]

I'm confuse with this issue, please can someone clarify it?

[nickl-]

@iannsp it is really awesome idea.

We have a @pattern annotation for example

@pattern observer

That means the test case is testing an implemented observer pattern

We have a database of known pattern with descriptions in this case we might say something like:

Observer Pattern

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

We know this pattern has a Subject class and a bunch of Observer classes and we could link to them somehow maybe also through annotation described or by analyzing the test case.

The Subject has a subscribe/listen/register function (we can have a list of defaults as we do with folder names, and the observers have corresponding notify/trigger/update methods which we can list in the documentation.

Because the patterns are frequently similar we could in this example see that there exists a method that populates a parameter (usually single parameter but if more this is an indicator too) to a class referenced collection. This is the register function, then we follow that collection to see where it is used in a loop to get objects out and a function is called on each of these objects (or in the case where the register function had a 2nd argument these may be conditional). This is the notify method. Search all classes we can find with this method, do they reference our observer perhaps? There are many things we can try and we should try as many as we can to be more flexible. These will also grow over time as we try and solve more and more edge cases so just the basics is good enough for now to get the ball on the roll.

Does that make sense much? =)