Re: Aspect Modelling and wide interfaces

> Martin Fowler wrote:
> > A class with that many attributes is a bad smell. Often such classes
> > should be split into smaller classes.
>
> Sometimes I come across such classes, where the attributes and behaviours
> can easily be partitioned into functional groups. An example: in a library,
> the class "Book" has a number of separate facets (logical groups of features
> of a class, each supporting a set of related interactions. It has interactions
> with Asset management (purchase records, condition), with Borrowing, and with
> some other mostly orthogonal aspects. Existing languages allow these groups to
> be separated into different interfaces, which can reduce complexity in a
> meaningful way.
>
> I use this insight as the underlying driver behind my thoughts
>about aspect orientation. The class exposes a facet to more than one
>aspect of the system,
> an aspect here being the group of facets that support some system role. I'm
> designing a data definition language called ADL (Aspect Definition Language)
> which properly supports facet isolation at a data modelling level.
>
> However, to map that to procedural constructs requires a complete rework of
> lifecycle concepts from typical O-O languages. I don't know of a language
> which provides support for isolating the implementation of facets of a single
> class though. An object may be constructed without all of its facets being
> "realised". A facet may then later be realised to an existing object. As I
> see it currently, this requires the RDB notion of key (attributes that form a
> unique identifier), but I'm still working with that.
>
> In any case, I'd like to know if anyone else is thinking down these lines.
> (Yes, I'm aware of www.aosd.net - not much of the work indexed there seems to
> attempt the things I'm after).

What about something like a RDB "view"?

Generally, the "grouping" that one needs tends to be task-specific in my observation. Thus, making "global views" sometimes just increases clutter. I would suggest making them local first, and them factor them global only if there is a pattern of repetition that can safely be factored together.

The general problem with partitioning just about *anything* leads to relativism problems if you do it globally.

Some things *must* partitioned for quantity-of-relationship issues (one-to-many, etc.). Beyond that, I recommend against just about *any* global partitioning. I know this is controversial, but the only way to solve the relativism view issues in many cases without creating a mess.

Thus, "wide interfaces" are unavoidable in many cases. You just don't know ahead of time how to narrow it down for future needs. What task X needs may be different from what task Y needs. Plus, it changes over time.

One thing about business rules, is that any given rule can potentially have it's finger in just about any other entity. Thus, you want to be careful about shutting off certain doors.

Life is a big graph, with changing connections.

>
> --
> Clifford Heath
>

-T- Received on Mon Jun 17 2002 - 06:43:50 CEST