Not really EA but given the expertise here

[sargasso]

This sort of cropped up in a conversation today.

Should one, (i.e. is it OO "pure"), to use a parameterized constructor to set up an object with initial values or should one use a contrived method?

I'll explain how this came about.  We have a class whose attribute values are, once set, very stable (for that instance).  In fact if it were C or C++ I would have used a STRUCT, but for various reasons irrelevant to the question the system uses classes.  The class structure represents a (set of) query-by-example constraint(s) for a database persistence driver.  It sort of looks like this:

Class QBE
+ConstraintList : Collection //of type QBEConstraint

Class QBEConstraint
+ColumnName : String
+Comparator : String //restricted values e.g. "=",">","%", etc
+Values :Variant(*)

So each QBEConstraint object represents a set of "OR" values for a particular column and each item in the ConstraintList represents an "AND" condition.  Pretty straightforward and conventional.

The conversation arose when one of the cutters wanted to create a constructor override for QBEConstraint to load "simple" instances, the architect disagreed and offered a specific public method to achieve the same thing, viz QBEConstraint.Setup(string,string,variant).

When it was referred to me I had no real opinion   to offer... and when I started to think about it  :-/  

Hence the question, is it better to....

all correspondence will be gratefully depreciated
bruce

p.s. "Most" instances are "simple"

[Geert Bellekens]

bruce,

The question I would ask is: is the object usuable without first calling that setup() operation.
In other words, if the setup operation is obligatory to be able to work with the object, then I would suggest to use a constructor overload.

Nothing more annoying then to get errors because someone created an object but forgot to "set it up", so the object is just an empty box. (and those errors could be very hard to track down. In your case I can imagine that the "empty" constraint object will work without throwing errors, and just always return "true" as a validation result)

Geert

[Paolo F Cantoni]

Hi bruce,

I agree with Geert (but then I'm only an Architect not a real coder...  

I use the overloaded constructor a lot in the Add-Ins I'm developing and it works real well.  I go to great lengths in those cases to make the use of the parameterless constructor invalid.

As Geert points out, it's most important from an architectural and conceptual perspective that the class is usable after construction.

My  AU$0.05
Paolo

[Eve]

I'd be going with the overloaded constructor.

In part, because that's what you need in order to get a valid object as the others have already said.  But also, I don't like the idea of the public function to change the meaning of your instance.  Even if it doesn't happen in your system, it is theoretically possible that an object could be referenced from multiple objects, then one of those decides to change it...

I would in fact be pushing to make the members of QBEConstraint constant, which would require the use of an overloaded constructor.

PS. I'd be interested in your opinion on the distinction between structs and classes.    The more I look at it, the more I come to the conclusion from a computing standpoint there is no difference.  The only difference being the interpretation of programmers.  Which in itself can't be relied on because each one imagines the line somewhere different.

[mrf]

I don't know if it helps but I sometimes use a mix of the two to get over the lack of constructor chaining in C++ eg:

Code: [Select]

/*
 * Constructor with no parameters
 */
SomeClass::SomeClass()
{
    // Default value of -1
    this->_SomeClass( -1 );
}

/*
 * Constructor with parameter
 */
SomeClass::SomeClass(int aValue)
{
    this->_SomeClass( aValue );
}

/*
 * Psuedo constructor with all parameters
 */
void SomeClass::_SomeClass(int aValue)
{
    this->intMember = aValue;
    
    // Common initialisation code can go here...
}

That was all constructors can execute a common code block regardless of how many parameters they take.

You may also wish to avoid constructors with parameters when you are using reflection to dynamically instantiate objects in Java. Reflection can only instantiate objects with default constructors (eg no parameters), which makes a setup() method necessary (in which case a state variable gaurding whether the object has been initialised is useful).

[sargasso]

Folks,
A quick response because I've got to go and have several dozen gallons of red wine after a day of trying to: a) understand why and b) understand how and where and c) where's my shotgun?; as to a database audit timestamp that increased itself by +98 minutes every time the row was updated (we are talking about the "created" timestamp here ).

Some good food for thought,  I like the idea of initializing an object to the "point of usefulness", but that raises the question of "what defines an object as being at that point"?  Needs further thought/input.

mrf, your last point gets me to the issue of transportability, in particular constructor oveloads are messy at the least when one considers alternate implementation languages.  This seems to me to degrade the languages that do provide full (and fully stable) overloads to a point where "give 'em twice as much rope as they need to hang 'emselves" seems to me to start creeping in.

Simon, the reason I added the struct comment in my original post is that these classes do not actually "do" anything, they are just data carriers... albeit quite structured data carriers.  I'd think that was my definition of structs, those classifiers that are just used to carry structured data between things.  Hey! Let's call them "information transfers" and be done with it.  

In fact, the more I think of it (and the more I need a red!), what the world really needs (apart from a conservative change of government in Australia) is a thing that is sort of between a struct and a class, that would allow some "fancy" setting up to happen.

"pop"
back later, hopefully quietly
bruce

p.s. OK OK political comment removed
p.p.s.  Recent double vision syndrome now cured. (Don't know how I did that one   )