Re: Separation of concerns


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.

Consider an abstract factory object that
never changes state. I certainly wouldn't describe it as a "little
state machine." Would you?

I never said it was a solid rule, but rather a generality. Objects can
be anything, and that is part of why OOP is such a shanty-town mess.


Anyway, I never said anything about "units of do-ness." "Do" is not a
technical term.

Dude, I didn't originally use it here. I was responding to the person
who did. Thus, your criticism is misdirected.

In short, I've been vindicated.

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.

(snip)

No, you may not. Get back in your box.

Is your rudeness necessary?




-T-

.

Relevant Pages

  • 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)
  • 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
    ... 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
    ... 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)