...
Unfortunately, common object-oriented programming techniques often
make a mess in this regard, because you must spread the logic for a
use-case over several classes and methods. Conversely, traditional object-oriented
programming must lump together bits and pieces of several (often
unrelated) use-cases in methods and classes. This clutters the logic. In extreme
cases, "infrastructure" or "bureaucratic" code like logging
and persistence, distracts from the actual meat of the software,
the actual domain logic:
Ivar Jacobson uses aspects as the principal unit of organization
in an aspect-oriented program, to modularize the facets of an
application. We use (re-motion) mixins for the same purpose, and we
believe that those are at least as well-suited for that purpose as
AOP. Mixins make this modularization possible, because
with (re-motion) mixins you can spread the logic for a class across
multiple projects and recombine them (drawn as little smiling squares in
the illustration above) at run-time:
The sample code discussed here explains
how to do this. (The page Hotel mixinology builds on what
you can learn here about the sample, discusses the finer
points of re-motion mixins and gives additional background.)