# PHP Aspect Oriented Design: Part 2 [closed]

This is a continuation of this post:

Review on design pattern

What was taken away from that post, and other aspect oriented design is it is hard to debug. To counter that, I implemented the ability to turn tracing of the design patterns on. Turning on the trace is at the bottom of the snippet:

//Turn on the logging to tracing adapters, filters and observers
//This can be added anywhere in the code and can also be turned off anywhere in the code
Run::setFilterTrace(true);
Run::setObserverTrace(true);

//Execute the method.
echo Run::goForARun(8);


In the actual log with the trace turned on, it outputs like so:

    adapter 2012-02-12 21:46:19 {"type":"closure","object":"static","call_class":"\/public_html\/examples\/design\/ClosureDesigns.php","class":"Run","method":"goForARun","call_method":"goForARun","trace":"Run::goForARun","start_line":68,"end_line":70}

filter 2012-02-12 22:05:15 {"type":"closure","event":"return","object":"static","class":"run_filter","method":"\/home\/prodigyview\/public_html\/examples\/design\/ClosureDesigns.php","trace":"Run::goForARun","start_line":51,"end_line":58}

observer 2012-02-12 22:05:15 {"type":"closure","object":"static","class":"run_observer","method":"\/home\/prodigyview\/public_html\/public\/examples\/design\/ClosureDesigns.php","trace":"Run::goForARun","start_line":61,"end_line":63}


When the information is broken down, the data translates to:

• Called by an adapter or filter or observer
• The function called was a closure
• The location of the closure
• Class:method the adapter was implemented on
• The Trace of where the method was called from
• Start Line and End Line

The code has been proven to work in production environments and features various examples of to implement, so the proof of concept is there. It is not DI and accomplishes things that DI cannot. I wouldn't call the code boilerplate but I would call it bloated. In summary, the weaknesses are bloated code and a learning curve in exchange for aspect oriented functionality.

Beyond the normal fear of something new and different, what are other weakness in this implementation of aspect oriented design, if any?

PS: More examples of AOP here: https://github.com/ProdigyView/ProdigyView/tree/master/examples/design

-

## closed as off-topic by Alex L, Simon André Forsberg, syb0rg, 200_success♦Jun 29 at 4:35

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. Such questions may be suitable for Stack Overflow or Programmers. After the question has been edited to contain working code, we will consider reopening it." – Alex L, Simon André Forsberg, syb0rg
If this question can be reworded to fit the rules in the help center, please edit the question.

I'm sorry, but since you haven't actually put code into this question its off topic for this site. This is code review, so you need to actually have code for us to review. If you don't remedy that I'm going to have to close your question. If you actually want to discuss the merits of DI vs AOP, I'd suggest asking on programmers.stackexchange.com. If you do that, post a link here, I'd be interested in seeing what other people have to say on it. –  Winston Ewert Feb 13 '12 at 17:38
The question is pretty marginal, because its still not really a code review. However, since I was critical of your previous version, I'm not going to take action as I've got a bit of a conflict of interest there. –  Winston Ewert Feb 13 '12 at 20:27
But I'd like to propose that we try an experiment. Can you provide your best example of a relatively simple project that makes effective use of AOP techniques in a language of your choosing. I'll take it and reimplement it using DI and related techniques. Then we'll post both our versions here on code review and get feedback on how well the two techniques worked. –  Winston Ewert Feb 13 '12 at 20:30
Sounds interesting, I will think of something and post it back here.Btw, I am not saying my design is necessarily better than DI, just like I don't consider MongoDB better than MySQL. I think everything has a situation in which one is better than the other. So my example will most likely be an instance where AOP is a better choice. –  Devin Dixon Feb 13 '12 at 20:58