Re: Separation of concerns
- From: "Daniel T." <daniel_t@xxxxxxxxxxxxx>
- Date: Thu, 29 Mar 2007 12:26:45 GMT
"Thomas Kowalski" <th-ko@xxxxxx> wrote:
It means to keep variables, functions, objects, abstractions as
focused as possible.
And how do you trade off with cohesion?
There is no trade off. Separating concerns means that an abstraction
should do no more than one thing, cohesion means that an abstraction
should do no less than one thing.
The best pattern depends on the context. How different are A and
B's draw method? How alike are they? Chances are you should have a
separate class that serves as a drawing helper.
The core drawing methods are extremely different. But I agree there
is an initialization part that is done in another class (View),
that's what I need the interface for. I have one class (View) that
implements a method onDraw() that draws all drawable Elements
passing the "right" parameters.
The question on hand is, shall the drawable interface be implement
in the class containing the business logic (means A and B) or
rather in an composed object (A_drawable and B_drawable) that just
implement the drawable interface and inherit the business logic.
Views should not inherit models. Have A_drawable contain the A that it
draws.
.
- Follow-Ups:
- Re: Separation of concerns
- From: topmind
- Re: Separation of concerns
- References:
- Separation of concerns
- From: Thomas Kowalski
- Re: Separation of concerns
- From: Daniel T.
- Re: Separation of concerns
- From: Thomas Kowalski
- Separation of concerns
- Prev by Date: Re: Separation of concerns
- Next by Date: Re: Double Dispatch Problem: Mobile Creatures and Projectiles in a Game World
- Previous by thread: Re: Separation of concerns
- Next by thread: Re: Separation of concerns
- Index(es):
Relevant Pages
|