warsaw@nlm.nih.gov (Barry A. Warsaw) (04/19/91)
Here's a few "philosophical" questions for you. Say you've got a
class wherein the constructor does some initializations of a
particular system. These inits may possibly fail, preventing the user
of the class from validly using any of the associated methods. How do
you go about returning this information to the class user when the
constructor does not return a value? Also assuming the object could
be created from the heap or on the stack, setting "this" to null
(legal for 2.0?), would not do the trick.
So how do you handle this? I do this by having a private "init" flag
which I set or reset depending upon the success of of the
initializations, then IN EACH METHOD REQUIRING VALID INITIALIZATION, I
check the value of this flag before doing anything. Usually I'll also
need a method so that the class user can query for the init state.
Second, many of my classes have a high degree of interconnectedness.
In other words, the user instantiates class A and through interactions
with A, A creates many instances of B. B's constructor is protected
so the user cannot create B's (but A is a friend). A has a method
which returns pointers to B's and A maintains a list of all B's it has
created. Each B in turn maintains a pointer to its parent A object.
This way, if A is destroyed, it can go through and destroy (or detach)
each B it knows about. Also, if a particular B is destroyed (by the
user), it can tell its A parent to stop keeping track of it. Even
more tricky is that in addition to A's keeping track of B's, there may
be a third class C which keeps track of the same set of B's. Lots of
lists involved as you can see. Think of all these classes as
instances of windows.
Anybody have any thoughts on alternate (and perhaps more elegant or
easier to manage) ways of handling these situations? Seems to crop up
very often on my current project....
-Barry
NAME: Barry A. Warsaw USMAIL: National Library of Medicine
TELE: (301) 496-1936 Lister Hill National Center for
INET: warsaw@nlm.nih.gov Biomedical Communications
UUCP: uunet!nlm.nih.gov!warsaw Information Technology Branch
8600 Rockville Pike
Bldg. 38A, Rm. 7s722
Bethesda, Md. 20894mittle@blinn.watson.ibm.com (Josh Mittleman) (04/22/91)
The first problem you describe is one of the reasons that exception handling is being introduced into the language. See ARM, 353ff for a thorough discussion. Without exception handling there are lots of kluges to deal with the situtation you describe: error code members, static error code variables, etc. In the second part of your post, it sounds like you really need a class SetOfB which manages all of the allocation and deallocation of B's. Class A contains a SetOfB and can add B's to it. In A's destructor, you destroy the SetOfB, which in turn destroys all the B's currently in the set. If some other class C needs to reference the same SetOfB, then you have to decide whether the A or the C owns the SetOfB. Assuming that the A owns it, the C should have a pointer to the SetOfB, or perhaps just to the A. =========================================================================== Josh Mittleman (mittle@watson.ibm.com or joshua@paul.rutgers.edu) J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598