Re: Separation of concerns

On Mar 30, 1:43 pm, "topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
On Mar 30, 1:15 pm, "throatslasher"





<implicit_differentiat...@xxxxxxxxxxx> wrote:
On Mar 30, 12:44 pm, "topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:

throatslasher wrote:
On Mar 30, 11:23 am, "topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
throatslasher wrote:
On Mar 29, 2:58 pm, "topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
throatslasher wrote:
On Mar 29, 11:13 am, "topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
Daniel T. wrote:
"Thomas Kowalski" <t...@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.

That is a precedural-oriented definition because objects are not
necessarily about tasks and task divisions.

-T-

You're so emotionally invested in proving the inferiority of OO that
you are incapable of parsing a simple message without prejudice. You
read the verb "do" and you extrapolate some crazy meaning from the
guy's post. An object that simply holds data still "does" something,
and that has nothing to do with tasks nor procedual programming, so
your post is absurd.

Why would someone treat programming styles like sports teams? Who are
these weird people who actually waste their time pumping up their pet
programming languages or styles and putting down others'?

No, objects *as generally described* are NOT units of "do-ness" (for
lack of a better term). Objects are generally considered as little
state machines that carry behaviors (note plural) related to
themselves.

I've never heard that definition before; it's one that flies in the
face of reality. Frankly, it shows how little you actually know about
object-oriented programming.

To paraphrase the author C. J. Date, no matter what definition or
description of OOP one offers or uses, somebody can and will criticize
it because NOBODY AGREES ON WHAT OOP REALLY IS. It is a non-rigorous
concept.

I don't pretend to disagree with that statement. Separation of
concerns, the topic of this thread, is also a "non-rigorous concept."
What's the problem?

I was merely addressing the accusation that my statement was alleged
evidence that I don't know anything about OOP. The "state machine"
concept came from OO proponents actually, not me. Anyhow, using fuzz
to criticize fuzz will not get you anywhere.

It doesn't matter where the concept came from, it's clearly wrong.
You criticized my post, told me I was using a bad definition of
objects,

I don't remember you offering a definition of OOP. It would be nice to
see the right definition from such a lofty, smart person such as
yourself.

and then provided a definition that is obviously incorrect.
These are the actions of a fool.

Calling someone a fool without offering solid evidence are the actions
of a ______.





When someone asks what a C struct "does," the answer
is it combines data into a single unit (please, if you have any qualms
with the particulars of this definition, keep them to yourself; it's
beside the point). The same question can be asked of any software
component, and a reasonable answer should be expected. Daniel T's
response was not a procedural-oriented definition, it was a general
definition, which is all that should be expected. It strikes me as
bizarre that you could actually read his response and come away with
the interpretation that you did.

Well, he seemed to agree and changed his statement (and it made more
sense after he did). Perhaps you missed it.

I don't think it made any more sense after he changed it, and frankly,
I don't think you do either. It's irrelevant anyway; I'm not
defending the guy, I'm talking about his original definition. That he
later says something stupid doesn't invalidate my point.

So everybody is stupid except you. Hmmmm.

Anyhow, lets get back to technology instead of he-said-she-said
fights.

No need. All that needs to be said on the subject has already been
said.

If it is still a fuzzy notion, then there is probably room for
improvement.

A general definition of separation of concerns is all that can
be provided, something which can only guide one's thinking in the
right direction; the rest must be left up to experience. In these
posts, I've had very little to say on the subject, and quite a bit to
say about your foolish remarks.

Functions can also provide separation of concerns. Thus, it is not
something that OOP has a monopoly on.

I already said that in my first post, even linked to the Dijkstra
paper. I said it in response to your assertion that separation of
concerns is just a "buzzword." You can sure switch gears fast when
(you think) it suits your purposes!

-T-




.

Relevant Pages

  • Re: Separation of concerns
    ... it because NOBODY AGREES ON WHAT OOP REALLY IS. ... The "state machine" ... to criticize fuzz will not get you anywhere. ... response was not a procedural-oriented definition, ...
    (comp.object)
  • Re: Separation of concerns
    ... and that has nothing to do with tasks nor procedual programming, ... state machines that carry behaviors related to ... it because NOBODY AGREES ON WHAT OOP REALLY IS. ... response was not a procedural-oriented definition, ...
    (comp.object)
  • Re: Separation of concerns
    ... it because NOBODY AGREES ON WHAT OOP REALLY IS. ... The "state machine" ... to criticize fuzz will not get you anywhere. ... response was not a procedural-oriented definition, ...
    (comp.object)
  • Re: Separation of concerns
    ... and that has nothing to do with tasks nor procedual programming, ... it because NOBODY AGREES ON WHAT OOP REALLY IS. ... to criticize fuzz will not get you anywhere. ... response was not a procedural-oriented definition, ...
    (comp.object)
  • Re: Separation of concerns
    ... state machines that carry behaviors related to ... description of OOP one offers or uses, somebody can and will criticize ... it because NOBODY AGREES ON WHAT OOP REALLY IS. ... response was not a procedural-oriented definition, ...
    (comp.object)