Overwrite Default Constructor ?

[Oliver Wong]

How is there a "this" if the superconstructor hasn't been called?

I think what Jeroen is saying to put the above code in the
superconstructor so that when it is called from within the subclasses, the
condition will return false, and so the constructor code won't get executed,
and thus no exception will be thrown.

It's a possible solution, but I think the protected do-nothing
constructor paired along with the factory methods is a cleaner one.

- Oliver

 

[James McGill]

It's a possible solution, but I think the protected do-nothing
constructor paired along with the factory methods is a cleaner one.

Yeah, I was going to ask what's wrong with Factory that makes such
"solutions" seem attactive to people. I suspect that's just because
there are people who haven't read GoF or its derivatives, and who are
struggling to find an approach to a common problem on their own.

 

[Jeroen V.]

I think what Jeroen is saying to put the above code in the
superconstructor so that when it is called from within the subclasses,
the condition will return false, and so the constructor code won't get
executed, and thus no exception will be thrown.

That's what I mean

 

[Jeroen V.]

Yeah, I was going to ask what's wrong with Factory that makes such

"solutions" seem attactive to people. I suspect that's just because
there are people who haven't read GoF or its derivatives, and who are
struggling to find an approach to a common problem on their own.

I'm impressed you've read GoF.

I'm wondering why you're substituting my name with "there are people
who". I suspect there are people who think they have a superior mind
because they've read some book. Still impressed.

I didn't say that anything was wrong with the factory design pattern.
I didn't say that my solution was more or less attractive, neither did I
say my solution was attractive at all.

From your post I derive that alternatives to a solution may not be
considered. Why is that? (don't answer this one)
Instead of insulting me of doing useless thinking, you'd better give me
a reason why my solution is not a solution (or how should I interpret
your quotes?)

I will tell you why my solution is a solution:
1. I'm allowed to define in the contract of the superclass that all
childclasses are responsible themselves for initializing the instance
fields.
2. Childclasses must obey the contract

Yours sincerely,

Jeroen

 

[Andrew McDonagh]

Jeroen V. wrote:

snipped

I will tell you why my solution is a solution:

1. I'm allowed to define in the contract of the superclass that all
childclasses are responsible themselves for initializing the instance
fields.

Is that the instance variables of the base class?

if so - How do the derived classes do this without using the base class
constructor?

if not - then aren't derived classes usually responsible for
initializing their own instance fields?

2. Childclasses must obey the contract

I didn't see anything from the code snipped that would 'force' derived
classes from doing so.

I did see the potential for a 'convention' that derived class designers
should follow.

Yours sincerely,

Jeroen

Cheers

Andrew

 

[James McGill]

On Tue, 2006-04-18 at 22:35 +0200, Jeroen V. wrote:

You seem to have taken my comments very personally.

I don't know of a single undergrad CS curriculum that does not have at
least one course on object design using patterns. I assume everyone is
familiar with the basic design patterns, just as I assume they are
familiar with the relative complexity among various discrete structures.

From your post I derive that alternatives to a solution may not be
considered. Why is that? (don't answer this one)

You're taking my comments as a personal attack on your coding style.
I'm fully aware there are many ways to solve a problem. But the one on
the table really looks like it's abusing the language, and trying to
make it do something that it's more or less trying to prevent you from
doing.

Instead of insulting me of doing useless thinking

Whoa there. Who is insulting whom?

, you'd better give me
a reason why my solution is not a solution (or how should I interpret
your quotes?)

I will tell you why my solution is a solution:
1. I'm allowed to define in the contract of the superclass that all
childclasses are responsible themselves for initializing the instance
fields.
2. Childclasses must obey the contract

Fair enough. But you're doing something that I could never make myself
do: Designing an Exception handler into normal behavior.

 

[Jeroen V.]

Is that the instance variables of the base class?
yes

if so - How do the derived classes do this without using the base class
constructor?

I mean initializing to non-default values. The super constructor is
called anyway, just not the if-then part. Public or protected setters in
the baseclass can be used for this.

I didn't see anything from the code snipped that would 'force' derived
classes from doing so.

I didn't say that. I did say that in the contract between the baseclass
and its derived classes, there is a clause saying that the derived class
is responsible for initing the superclass instance fields. This must not
be reflected in code.

I did see the potential for a 'convention' that derived class designers
should follow.

That's what I mean.