What alternatives are there for cross cutting concerns other than aspect oriented programming?

Question

Aspect oriented programming promises to deal with cross cutting concerns, but I'm not completely sold on it yet. Have there been any other attempts to deal with this problem?

Answer 1

When possible, you can encapsulate cross-cutting concerns into separate modules that are then used throughout the app via dependency injection. This allows you to somewhat decouple the cross-cutting concern implementation from it's use throughout the code.

This doesn't always work elegantly, though. That's the reason people are trying to address the issue with things like AOP.

Answer 2

Two other options that I haven't seen explored yet:

Functional Programming with Monads and Arrows

In FP you represent a cross-cutting concern like anything else: as something you pass in on a function call. Since doing that explicitly gets tedious, you can use Monads (or maybe Arrows) to hide away the extra information being passed along.

The most common AOP example is logging. With Monads, you would create a "Logger" monad that keeps a list of messages. Any functions you perform through the LoggerMonad have the ability to post a log message. With Arrows, you would model the entire data flow of the application, and would work a logging routine into the model where appropriate. I think. Arrows are pretty complex.

Entity/Component-Based Programming

Something I've been researching and experimenting with for a game engine. Instead of "objects" like in OOP, you decompose everything into packets of data (components) and services that operate over a type of component. Components are grouped together by common IDs, like in a relational database, and groups of linked components are the Entities. To add logging in such a system, you would add a new logging service the triggers based on which components are passed through it.

Both methods allows for one to easily work a cross-cutting change in very easily, but both are high-level architectural models. So you would probably need to be using them from the beginning. The Component model can, theoretically, be worked into an existing OOP system. I guess monads could be too if your language is powerful enough.

Answer 3

There are several ways to tackle the problems of crosscutting concerns:

• Use Better Design Patterns, Idioms, or Abstraction Mechanisms: Code may be crosscutting even though it can be modularized. In order to maintain the code, you will need to refactor to use the design technique that can modularize it. Such refactoring may introduce crosscutting of a different kind, but hopefully what crosscuts is stable, and not likely to change.

• Develop Richer Language Features: Many manifestations of crosscutting can be solved through better abstraction mechanisms, and sometimes new language features are necessary. For instance, more advanced languages that include functional and object-oriented features often don't employ as many design patterns, because they aren't necessary. Note that design patterns themselves can be crosscutting in nature, because they describe the roles of several different objects and classes. In Java, reflection can often be used instead of an aspect, although at a higher runtime cost. For example, using reflection, you can support the visitor pattern over hundreds of classes with just a couple lines of code. The DJ library from Northeastern is one reflective solution that does just that. Mixins are a powerful technique available in C++ (but not Java) and can give you some of the same uses cases as an aspect.

• Provide Better Tool Support: Techniques such as using grep and performing refactoring operations can deal with problems related to crosscutting code. For example, the name of a method declared in an interface can cut across the program. (Note the technical difference here: It is the name of the method, not the method's implementation, that crosscuts.) This usually isn't a problem in an IDE like Eclipse, where you can use the "rename refactoring" to change all of the places in your code that use the name. In this way, it's possible to not need language features when the programming environment is expressive enough for you.

• Use Domain-Specific Languages: The early aspect languages, which came before AspectJ, were domain-specific and applied to only certain problems, such as thread synchronization or data-flow analysis for efficiently combining function compositions. These languages were experimental, but seemed highly successful at modularizing concerns that otherwise were crosscutting.

• Use Generative Programming Techniques: Stepping up to the meta level might be considered an implementation technique for aspect-oriented programming, but it's a big enough area that it transcends simple aspects. Generative techniques (where a program generates source code for another program) are also related to domain-specific languages.

For all of these, I think studying AOP is appropriate. AOP can help you expand your conceptions of code, even if you don't use an AOP language.

Answer 4

In general tagging code elements with a declarative feature, but specifically the Attribute system in the C#/.NET/Mono world.

Answer 5

I'm no expert on AOP, but from reading about it over the years, it has always seemed like a weaker form of the metaprogramming offered by Lisp, especially parts like its metaobject protocol.

This should come as no surprise, I suppose: Gregor Kiczales was one of the authors of AMOP, and later wrote AspectJ for Java!

Answer 6

Traits and Grafts

http://en.wikipedia.org/wiki/Trait_(computer_science)