What is "aspect-oriented programming" and why should I care?

[ast3r3x]

...
Care to elaborate what you mean a little more? I think I disagree, but want to be sure before I reply :)

-------------------

Actually it would be kinda neat if we had a CMS that had a an app (I guess java since we can't assume everyone will use OS X) to control various aspects of our CMS.

[ShadowOfGed]

Care to elaborate what you mean a little more? I think I disagree, but want to be sure before I reply :)Sure, I'll give it a shot. Here's a pretty good explanation of what AOP is: linky (http://jroller.com/page/colyer/20040531).

When designing a CMS, you want every shred of information you're dealing with to be an object (well, at least in my mind); scalars really make things messy, and PHP doesn't do much for providing type safety, which is also very useful. Python treats everything as an Object, even primitives like strings, integers, floats, and so on. PHP, Perl, C++, and others treat primitives as something that's not quite an object, so you can't just specify that you want an "Object" parameter in a function where any type will do.

Aspect-oriented programming also requires the language to provide facilities for code to intercept calls to functions and methods elsewhere in the program, and I looked through the PHP docs and found nothing that can provide that low-level functionality to the programmer, whereas there are modules for Python, Ruby, and Java (specifically, AspectJ) that let you do this. If there's something similar for PHP, just point me in the right direction.

Also, the fact that classes must be loaded using include() and require() statements seems like a hack, if you ask me (even if you declare an __autoload() function). PHP is clearly a procedural scripting language with an attempt at OOP bolted on after the fact, and that bothers me, but I'm quite the purist at heart.

Anyway, why is AOP useful for a CMS? It's because for certain things, like logging, you want a module to be able to alter the functionality of every other object without changing the code itself. The most useful part, I think, is actually if an add-on module wants to add content or modify the appearance of a specific page, be it rendered content, or adding additional fields to an input form. It's very useful to have in a CMS, but it requires a language that can support it.

Does that clarify my point? If there's something that can provide good, solid AOP support for PHP, then point me to it. Anyway, hopefully that clears it up a bit... :)

[pmazer]

PHP is clearly a procedural scripting language with an attempt at OOP bolted on after the fact, and that bothers me, but I'm quite the purist at heart.

Not to get too off topic, but Python feels that way to me. Maybe that's why I like Ruby :lol:

[Gargoyle]

Interesting stuff ShadowOfGed. Brad, can we split this thread into the project posts and an OOP/AOP discussion?

[ShadowOfGed]

Not to get too off topic, but Python feels that way to me. Maybe that's why I like Ruby :lol:Well, I've never looked at python in much depth, but if you're right, it seems to at least have done a better job at truly integrating OOP. Ruby seems a bit obtuse in its language constructs, even if it is fully object-oriented. The only reason I've not investigated it too far is that it lacks tight integration with typical production software like Apache... there is mod_ruby, but it's not fully functional like mod_python and mod_perl.

We now return to your regularly scheduled discussion... ;)

[ShadowOfGed]

Can you think of any specific examples?Glad you asked! ;) :lol:

The best example I can come up with is the following scenario, but in time it would manifest itself in other ways.

It seems that the model-view-controller design is a good way to go about things, despite the fact that a web application can't communicate model changes to the browser, but it provides a good logical separation between data and presentation, which is a good thing.

Anyway, for every object's view class, you're going to have an edit and/or create method. Well, if the CMS provides security measures for all objects (this depends on the CMS treating all data types as distinct objects, but that's not the point), you're going to want a portion of the edit/create interface to allow editing the security properties of a given object. Well, the model and view for a data object obviously won't implement that, since it's not an integral part of that object. So you need a security "aspect" that will "cut" across all views, and add the security interface to every object's edit view, instead of having to implement that interface for each and every object view.

This way, you only have to make code changes to the class that houses the security view aspect, and everything changes, versus having to make sure you fix up all copies of the interface across all view classes. Designing it this way also allows a third party to drop in a new data type (object/class) and it will automagically have the security interface added, without ever touching the third-party code.

Aspect-oriented programming and object-oriented programming are complimentary, not exclusive... I hope I didn't confuse anyone on that point. Anyway, hopefully this rudimentary example shows how it's useful for a CMS.

Does that make sense? :confused:

Oh, and as an afterthought: all of our add-on text entry buttons here could also be an aspect, instead of requiring explicit code calls to render them on each page that has text entry boxes. :)

EDIT: Mods, if you want to copy these posts into another thread, that's fine, but I think some of the discussion could still use to be left here if we're actually going to put an effort behind designing a new CMS. Just a thought.

[Gargoyle]

Does that make sense? :confused:


Errm, nope. Not really.

You have just re-described your original statement with different words! :)

I understand how MVC works. You have your object - lets say a bike. You then have your view - lets say a textbox that tells you what gear the bike is in, along with change up and change down buttons. Finally, the controller handles the clicks from these buttons and calls the methods in the model. Then the view is updated! This final bit is the one that gets me sometimes... who or what updates the view!?


...for every object's view class...

This is something else that worries me. Are you saying every object has a view class too?

Can we expand on this example to demonstrate your point?

[ShadowOfGed]

Can we expand on this example to demonstrate your point?OK, I'll try to whip up some pseudocode or the like later on tonight once I'm home. I probably won't post it here, since it will probably be long, given my coding style.

You'll have to excuse me, because I'm fairly new to the AOP and MVC concepts, so I may not have a 100% grasp on how they work, but I think I understand somewhat.

You were right, though, about this thread getting way off. I'll leave the AOP discussion to something else. What we should be talking about here are project ideas and goals. For example, if we put together a CMS, what should it be capable of doing? As I said before, I've got my ideas, just not with me. I'll post those later. :D

[Brad]

Thread split. Carry on. :)

[Kickaha]

If you're familiar at all with design patterns, AOP is the Observer pattern injected into the runtime, so that any method entry or exit is a hook for a supplementary method to be called automatically.

[pmazer]

If you're familiar at all with design patterns, AOP is the Observer pattern injected into the runtime, so that any method entry or exit is a hook for a supplementary method to be called automatically.

Do you know of any good primers for design patterns? Basically, what you're saying is that aspect-oriented programming allows certain methods to be called when another method enters and exits?

I think I understand, but I'm trying to use less buzzwords to make sure I actually get it and maybe that'll help others, too.

[spotcatbug]

I would like to see some syntax for built-in AOP.

[Brad]

Do you know of any good primers for design patterns? My first real "official" exposure to design patterns was the Head First Design Patterns book. While the cover image (ftp://ftp.ora.com/pub/graphics/book_covers/hi-res/0596007124.jpg) makes everyone I've known throw up a little in their mouth the first time they see it, the content of the book is pretty good. Plus, the writers use Mac OS X!

More tangent: Yes, not until my senior year have any of my professors talked about design patterns. That's the sad shape my university's (NCSU) computer science program is in.

[Kickaha]

At its most basic, yes, AOP is a method entry/exit hook mechanism. An aspect method can request to be called when a certain class/method is invoked. Essentially, the runtime offers the ability for any method to be extended in this manner, the same way the Observer pattern has a mechanism for specific events that observers can request to be notified of.

Observer is usually used for things like "When this type of event (mouse click, file update, etc) occurs, let me know." AOP generalizes this out to "When the method I give you gets called, call me." The method requested can be 'any method', 'any method of class X', 'method foo of class X', 'method foo of class X or any subclass of class X', etc. It's a very useful and general tool.

Edit: Yeah, Head First is pretty good - I was surprised how good it was when I looked at it. The biggest problem is that most patterns tend to be quite 'high level' for new programmers. HF is a good start though. OTOH, if you want the grand-daddy and authoritative source for the 'core' design patterns, you can't beat the original Design Patterns by Gamma et al.

[thuh Freak]

Errm, nope. Not really.

You have just re-described your original statement with different words! :)

I understand how MVC works. You have your object - lets say a bike. You then have your view - lets say a textbox that tells you what gear the bike is in, along with change up and change down buttons. Finally, the controller handles the clicks from these buttons and calls the methods in the model. Then the view is updated! This final bit is the one that gets me sometimes... who or what updates the view!?
pretty much spot on, by my understanding. the model is often coupled with the view, so as to provide this, ie:
Controller::some_method() {
Model_instance.do_some_change();
}
...
Model::do_some_change() {
for_each( view in list_of_views ) {
view.hey_the_model_changed();
}
}
...
View::hey_the_model_changed() {
/*affect the UI*/
}

iirc it would be a bad practice, but you could give the controller a hook to the view directly. professor also mentioned polling (from the view to the model) as an ugly option (i believe another "to be avoided" idea). i think it was preferred to have the Controller know the Model, the View know the Model, and the Model know the View. C->M<->V

This is something else that worries me. Are you saying every object has a view class too?

Can we expand on this example to demonstrate your point?
every class does not need a view. only the ones you want to show in the UI, i think.

If you're familiar at all with design patterns, AOP is the Observer pattern injected into the runtime, so that any method entry or exit is a hook for a supplementary method to be called automatically.
well, i aint ne'er heard of the Observer pattern nor AOP {before today}, but that made sense to me.

[spotcatbug]

The model updates the view? I always envisioned the controller sitting in the middle. Shows how often I've used that pattern. :\ I better sit down and read this Design Patterns book.

[Enki]

No, the view should update itself. Either by querying the model at specified intervals, or by listening to model events (if you also overlay a listener/observer pattern). The biggest key is that the model knows nothing about the view, or the controller for that matter. It's the model that sits in the middle and is poked by the controller and examined by both the controller and view. That way no matter what you do to the code in the view or the controller, you don't have to change the model. And since the model is the most vital part to validate for proper operation you get to worry less about simple (or not so simple) I/O changing how it operates in unexpected and improper ways.

[709]

I love this board.

[pmazer]

I've always thought it should be: V <-> C <-> M

The view sends changes to the controller; the controller takes in those changes, queries the models, and edits the models and views based on those attributes. That's what's always worked and made the most sense to me.

No, the view should update itself. Either by querying the model at specified intervals, or by listening to model events (if you also overlay a listener/observer pattern). The biggest key is that the model knows nothing about the view, or the controller for that matter. It's the model that sits in the middle and is poked by the controller and examined by both the controller and view. That way no matter what you do to the code in the view or the controller, you don't have to change the model. And since the model is the most vital part to validate for proper operation you get to worry less about simple (or not so simple) I/O changing how it operates in unexpected and improper ways

This makes no sense. Neither the model nor view should have to know anything about the controller. This enables you to reuse code much easier. The only thing that should be specific to your application should be the controller. Imagine trying to change a desktop application into a voice controlled application. In my MVC, all I would have to do would be to change the view objects. In your example, you would have to change the controller and view.

The biggest problem, though, is that the view has to know about the model. That means that you have to write custom view classes for every program. Seems like a huge headache to me when you can just write much of that code in the controller.

Perhaps I misunderstood you.

[Enki]

You did misunderstand.

The view and controller are separate and don't need to know about each other, I never said they did.

Model is the heart of the program.
View is pretty much just the O in I/O.
Controller pretty much just the I in I/O.

The view and controller will always depend on the interface to the model, never on the models implementation. The model should never depend on the view or controller implementations in any way, but it does need to have the appropriate interfaces to allow the view and controller to properly service it. And the best design would not have the view and controller talk at all, but unless you are using multiple windows, you cannot avoid some overlap at owner of the single window.

It also gets philosophical as to whether some form of indirect feedback is part of the view or the controller. Think the speedo in the car, it is duplicating the information you are taking in via the view through the windscreen, just in a more precise way tailored for precise control of speed. But that readout of speed is really just a secondary part of the view, or is it? So should the view or controller have the speedo code? If you say the view, then the view is making it's display dependent on the requirements of the controller, but if you say the controller, then it is subsuming part of the job of the view.

So despite the pure goals of MVC, we can never really get all the way there. Just make the most reasonable choices about what code goes where and couple the modules in the loosest reasonable way.

[pmazer]

Ah, okay, I see now. The difference was mine is using view for input and output and the controller is the bridge between the model and view. So, does your view not take in any input, such as buttons and forms? I see the view of an application as basically encompassing the entire user interface.

[Kickaha]

This might help: http://en.wikipedia.org/wiki/Model_view_controller

[pmazer]

I think we're all on the same page now. Once I realized that it's the controller which is taking the input, that made it all better :)

[spotcatbug]

Model is the heart of the program.
View is pretty much just the O in I/O.
Controller pretty much just the I in I/O.

Ah ha! (lightbulb moment)

I had always thought of the view as the entire UI. It's the View + Controller that's the UI. Now it all makes sense. Although, that doesn't really fit with most frameworks, does it? All the little widgety bits you might put in a window seem to do both the I and the O. Are you supposed to make your own framework, just to use the MVC pattern?

[thuh Freak]

I love this board.
me too. its pretty cool to come to my favorite bb and talk about se design patterns. i never thought that'd happen. or that i'd be such a geek so as to enjoy it. :)

[Kickaha]

Ah ha! (lightbulb moment)

I had always thought of the view as the entire UI. It's the View + Controller that's the UI. Now it all makes sense. Although, that doesn't really fit with most frameworks, does it? All the little widgety bits you might put in a window seem to do both the I and the O. Are you supposed to make your own framework, just to use the MVC pattern?

Hence, CoreData and Cocoa Bindings. ;)

You're right, many frameworks blur the lines between the V&C, for a number of reasons. Many controllers are not just input, but also feedback, like a slider. Conceptually, as long as you think of that widget as a V + C, but keep the V and the C separate in your head, you'll be much better off.