Re: Separation of concerns

throatslasher wrote:
On Mar 28, 7:20 am, "topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
On Mar 28, 8:01 am, "Thomas Kowalski" <t...@xxxxxx> wrote:

Hi everyone,
I am currently quite confused about the separation of concerns things
and search here for enlightenment.
I have some classes. lets say A and B that shall implement a certain
interface (e.g. Drawable).
Now it would not be very nice if A and B would implement then directly
Should I subclass like A_Draw and B_Draw or what is the current
pattern to solve this?

Thanks a lot in advance,
Thomas Kowalski

"Separation of concerns" is a buzz-word that so far has very little
consistency and rigor. Plus, in reality it is hard to separate
everything because real-world apps have to model real-world
relationships, which are often intertangled by their nature. Often
there is a tradeoff between separating one factor at the expense of
another. It is rarely a free lunch.

I think you're very confused. Separation of concerns is certainly not
a "buzz-word;" Dijkstra himself used the term (possible coined it) in
the '70s (see
Just about any time you use any form of abstraction you are separating
concerns. If you want to quibble over the one true rigorous meaning
of the term, then you are a fool. Such hard and fast definitions are
worse than worthless in a craft like computer programming.

Well, fuzzy ones are marginally better. Almost any software that at
least uses modules and/or subroutines is separating stuff. The hard
part is selecting which factor to separate by because it is physically
*impossible* to isolate all potential factors projected onto 2-
dimensional text (code). Thus, separation is almost a given.

(I think "isolatable" factors would be a better, more scalable goal,
because it would allow us to 'query' by desired factors as needed
rather than having to hard-partition by one factor at the expense of
others. This is one reason why I would like to see RDBMS replace file
systems for code management. RDBMS are the best "relativity engines"
out right now.)

Further, sometimes heavy separation creates beurocratic software. You
have to weigh tradeoffs using experience. It is relatively easy to get
software to work without experience, but experience is necessary to
future-proof software (or at least make it reasonably maintainable).

You appear to be arguing with yourself. What you've described is a
reason why good practices such as separation of concerns don't have
the rigorous definitions you asked for. Obviously, separation of
concerns should not take precedence over common sense; these are rules
of thumb, not Laws of Computer Science.

Too many people treat them as laws, and go overboard.

The experience to which you
refer produces good judgment for when and to what degree these rules
of thumb should be applied.

My advice is to keep an eye on potential future change, but keep it
simple. If you don't keep it simple and a future change comes along
that you failed to anticipate (you guessed the wrong kinds of
changes), then software is often harder to change than if you didn't
do any future-proofing but kept it simple. Thus, it is ofter more
benefitial to ponder how to obtain simplicity than to ponder what to
isolate for estimated future changes. Isolation is like a rifle, where
simplicity is like a shot-gun: you don't have to aim at the future as
accurately to get benefits from simplicity.


with a quack-quack here, and an oink oink there....