> Enforcing that rule solves the problem of not knowing which arguments to > pass at create time but introduces the new problem of having to remember to > call certain sets right after creating – a strange dependency.
No, it doesn't, actually. The code that wants an instance of whatever object knows what it's doing, so it's going to do it. Either the set methods you refer to are tied to the specific task the calling code is doing, or they're not. If the former, they can't happen anywher except the calling code (and the calling code better remember to do them, or it's not going to be doing what it's supposed to). If it's the latter, then they should be set in the factory (by init(), most likely), because they'll be the same for all instances, no matter how they're going to be used. > This could > cause even more problems because how am I even supposed to know which sets > are mandatory right after create and which are just regular sets that can be > performed anytime. If they're mandatory for an instance to exist, then either the factory should be in charge of setting them, or the object needs to be built in such a way that it "fails fast" if the property isn't set. i.e. the propery defaults to an "unset" state that can be tested against, and it explictly throws an error if it's not set. In all the code I've written, I can't think of an example where I've needed to do this. cheers, barneyb -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/ Got Gmail? I have 100 invites.
