Aspect-oriented programming (AOP) gives the programmer facilities
for slicing and dicing logic that go beyond class hierarchy and
composition. This article introduces (re-motion)
mixins as an alternative to AOP. We decompose
a toy domain into use-case slices and use re-motion mixins to
separate those slices in code. This domain - a concierge
system for a hotel - is inspired by Ivar Jacobson's
Aspect-oriented Software Development with Use Cases.
Slicing of applications with mixins takes practice (just like AOP),
but the benefits are worth it – even for modestly sized applications.
What application programmers aim for in domain-driven design
is to organize code along and around domain phenomena, not restrictions or
technical details of the implementation language and platform
(wikipedia).
The common practice of specifying use-cases is older than the
names for aspect-oriented programming or domain-driven design,
but usually play a prominent role in both. A use-case explains
how the software is used for a single, small and well-defined activity,
and how the user interacts with the program in a certain role.
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.)