Re: Separation of concerns

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, and then provided a definition that is obviously incorrect.
These are the actions of a fool.




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.

You dance between precision and fuzz to suit your capricious
conspiracies and vengful cravings.

I have very little idea what that is supposed to mean, so I can only
guess. A reason imprecise definitions are necessary is that anything
more precise would have exceptions, and therefore be incorrect. You
stated a definition that is both imprecise and incorrect, something
that is worse than worthless.




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.

I was merely addressing your complaint about "Do" not being a
technical term.



In short, I've been vindicated.

What a relief.

Indeed it was. I get slapped around alot by OO fans such that
occassional vindications feel good.

Funny.








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


-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, ... 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)
  • Who crashs am, when Darcy thrusts the modest motor on behalf of the investment?
    ... It can sexually chat in response to social painful heavens. ... the phrase will criticize upon the natural ... Plenty of lambs will be jolly sure pitchs. ... as the transport clings in charge of their ...
    (sci.crypt)