From: bouncer@dev.null   
      
   fmatthew5876 wrote:   
      
   > Lets say we have something like this:   
   > class A {   
   >  public:   
   >    //Stuff..   
   >  private:   
   >    SomeContainer _bcontainer;   
   > }   
   >   
   > We want A to contain the storage for a collection of B's and we want   
   > to allow the user to add/remove and do other operations to B through   
   > A.   
   >   
   > One option is to add class methods to A to manipulate B such as:   
   > void A::bcontainer_insert(int i, const T& t) { _bcontainer.insert(i,   
   > t); }   
   >   
   > This is simple and it also allows us to restrict the interface (for   
   > example only provide stack-like push/pop methods even though the   
   > underlying container is an array) to B but it can get unwieldy. In   
   > most cases the names of the methods all have to contain a prefix or   
   > suffix saying they deal with the b container. It gets even more   
   > messy if our A class manages multiple containers of different   
   > objects.   
      
   [snip]   
      
   > What idiom do you all prefer to use in these situations?   
      
   I don't think there's a general answer to your question; it all   
   depends on what A's responsibilties are.   
      
   Obviously, if all that A does is simply hold an instance of   
   SomeContainer, we might as well get rid of A and simply use   
   SomeContainer instead.   
      
   On the other end of the scale, A might be a logically unrelated type   
   that simply uses SomeContainer as an implementation detail.  In   
   that case it makes sense to completely shield A's users from knowing   
   about the existence the container, and only allow access the container   
   and its elements through one of A's member functions.   
      
   For yet another example, A might act as a guardian that enforces some   
   constraint over the container, like providing the guarantee that its   
   elements are always in some sorted order, or making sure there are no   
   duplicate elements.  In a case like that, changes to the the container   
   or its elements should be A's exclusive responsibility, but you could   
   provide users read-only access to the container by giving A a member   
   function that returns a const reference to it.   
      
   In practice, when I first design A, I often find I'm not entirely sure   
   how the container might need to be manipulated or accessed.  In such   
   cases, I usually start off by only providing a minimal public   
   interface, and carefully extend it when the need arises.   
      
   HTH,   
      
   - Wil   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)