Dear Rene
Thank you this comprehensive review, which clarifies things
for me. Your comments encourage me to employ the use of
TFolders further, since this is exactly what I want, to
“have a standard way to navigate/browse in your class network”.
Best regards
Christian
Rene Brun wrote:
> Hi Christian,
>
> TFolders are not a replacement for normal C++ pointers.
> In a C++ program, I will consider the following cases:
> -A: very strong coupling. You put together all items
> that have to be used together. This is the class level.
>
> -B: A logical structures (a tree/graph) of classes that must
> always be used together.
>
> -C: A large network of classes
>
> In a large system, you can imagine all possible combinations
> - everything in one single class ::)
> - the other extreme: too many classes
> - the most usual case: something between the two extreme cases
>
> When the system grows, it is important to minimize class dependencies
> for many reasons:
> - a practical reason. If you make a change to one class, you do not
> want to recompile too many classes.
> - you want to structure your super large system into sub systems
> that could be used independently or maintained independently.
> - you want to minimize the side effects of a change in some class
> design.
>
> Your particular example is clearly in category B above. You will
> still benefit in posting your Tlist objects in some folder. This has the
> big advantage that you have a standard way to navigate/browse in your
> class network. This is important in large collaborations and it helps
> in documentating a system.
>
> The big advantage of TFolders come only when the system grows.
> The main objects like Collections, Geometry, MagFields can be reached
> via the TFolder naming scheme instead of getting a pointer to some class
> that you know holds in turn a pointer to one of these objects.
>
> My message is the following: Do not abuse of TFolder as a replacement
> for something that is better implemented by a class or standard
> collections.
> When your system grows, minimize the coupling by obtaining your pointers
> from the naming scheme ("a/b/c/..") of folders instead of getting a
> pointer from some super manager class.
>
> Rene Brun
>
> On Wed, 24 Oct 2001, cstrato@EUnet.at wrote:
>
> > Dear Rene
> >
> > Thank you for your reply. At the moment I am just testing different
> > approaches to see what I could use.
> >
> > Probably, I do not quite understand the concept of TFolder helping
> > to minimize the coupling between classes. Suppose, I have the
> > following classes:
> >
> > ClassA
> > TList fListClassA //list of ClassA!
> > TList fListClassB
> >
> > ClassB
> > TList fListClassA
> > TList fListClassC
> >
> > ClassC
> > TList fListClassB
> >
> > How can TFolder help me to minimize the coupling between these
> > classes?
> >
> > Thank you in advance
> > Christian
> >
> >
> > Rene Brun wrote:
> >
> > > Hi Christian,
> > >
> > > The primary role of TFolder is to facilitate the description of the
> > > transient data structures, minimizing strong coupling between classes.
> > > Your folder structure is correct. However, your structure mimics a Unix
> > > directory structure. It is not what a TFolder is designed for.
> > > Why don't you use directly the OS file system to do this?
> > >
> > > Anyhow, assuming your existing folder structure, you can automatically
> > > generate a Root Tree from this structure by doing for example:
> > >
> > > TFile *vFile = new TFile("folders.root","recreate");
> > > TTree T("T","/MyRoot");
> > > T.Fill();
> > > T.Print();
> > > T.Write();
> > >
> > > instead of the last 3 statements of your function MyFolders.
> > > The T.Print() will show you the automatic generation of the Tree branches
> > > from the folder structure. There is no need to specify branch addresses.
> > >
> > > Currently, Root is not capable of rebuilding the folder structure automatically
> > > when reading back a Tree. This is on my todo list since a few months now.
> > >
> > > Rene Brun
> > >
> > >
> > > > ----------------------------------
> > > > C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a
> > > > V.i.e.n.n.a, A.u.s.t.r.i.a
> > > >
> >
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET