Re: Separation of concerns

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?


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.

It is not a correct generality. I provided an example showing that it
is far too restrictive. I don't know where you came up with that
definition, but it is clearly a bad one. You come here criticizing
something despite an obvious lack of familiarity with the subject, a
sure sign of a fool.

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.

That's irrelevant, "dude." You *interpreted* it as being strictly
task-oriented in your response; even told the poster that his
definition was wrong based on your interpretation of the word.


In short, I've been vindicated.

What a relief.


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.


(snip)

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

Is your rudeness necessary?



-T-- Hide quoted text -

- Show quoted text -


.

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