Unsure about how realistic decoupling is.

[Michael Judge]

Hello,

I'm having trouble with decoupling. I agree that information hiding /
decoupling is a universally good thing, but in practice I'm having
trouble actually keeping classes isolated from each other.

Say you're programming a survey application. When a respondent submits
a question, the data needs to be validated. Where does the validation
method (validates?) go?

* Class Questionnaire
* Class Question
* Class Interview

Logically, if the interview's answers are more central to your idea of
validation, it goes in Interview:

class Interview
def validates?(pass in a question)
...
end
end

Alternately, if the question structure is more central to your idea of
validation then it goes in Question:

class Question
def validates?(pass in a hash from interview.answers)
...
end
end

In either case, a bridge is being built between the two objects because
the method doesn't fit cleanly within one or the other. Isn't that
obnoxious? I find myself agonizing over this kind of problem all the
time. As a consequence, my classes are never reuseable unless they're
trivial things that aren't worth reusing.

Does most object-oriented code look like this? Is decoupled classes an
exception in actual applications rather than the rule? I'm afraid I
don't get how something like validation in a Question could possibly be
isolated from the Interview data.

(Thanks for your input.)

 

[Robert Klemme]

Hello,

I'm having trouble with decoupling. I agree that information hiding /
decoupling is a universally good thing, but in practice I'm having
trouble actually keeping classes isolated from each other.

Having classes coupled isn't a bad thing in itself. In fact, OO is
mostly about how to distribute responsibilities across several
collaborating classes.

Say you're programming a survey application. When a respondent submits
a question, the data needs to be validated. Where does the validation
method (validates?) go?

It depends on what you mean by "validate". Do you mean test validity of
input? Or checking answers for correctness? Maybe you tell a bot more
about the relationship between questionnaire, interview and question and
we can come up with more suggestions.

In either case, a bridge is being built between the two objects because
the method doesn't fit cleanly within one or the other. Isn't that
obnoxious?

Double dispatch isn't too unusual - just think of the visitor pattern or
CLOS, i.e. Lisps implementation of OO which allows method dispatch based
not only on a single instance as most other OO languages but on several
instances / their types.

I find myself agonizing over this kind of problem all the
time. As a consequence, my classes are never reuseable unless they're
trivial things that aren't worth reusing.

Don't say that. A library built of "trivial" things can be a time
saver, too.

Kind regards

robert

 

[Neil Wilson]

You are trying to hard.

We are human beings, not omniscient superstars. Write what works for
now. Forget about reusability, because you have absolutely no idea
whether this class is a one off.

IMHO it is only at the refactor stage where you eliminate duplication
and look for commonality that you can truly discover what is worth
putting into a more complex, but more reusable, pattern and what is
simply best left as it is. Until you find yourself writing the same
code for a second time then there is no need for reuse.

Accept that you can't see the future. Write your software for today and
let tomorrow look after itself. But make sure that tomorrow has time
put aside for refactoring and structural readjustment otherwise you end
up in spaghetti code hell.

Dealing with the two competing forces of 'write it now' and 'dont write
things twice' is just another of those Programming Paradoxes (TM) that
you have to learn to deal with in this game.

Best

NeilW