|
This message concerns the definition of the abstract base class G4VUserPhysicsList.
This class contains two pure virtual functions, ConstructProcess() and ConstructParticle()
that must be defined in derived classes such as Hans-Peter Wellisch's use-case physics lists
and custom user physics lists such as those in the examples. In the abstract base class, they
are declared as protected, although in derived classes, except G4VModularPhysicsList, which
itself is used as an abstract base class, they are always public. Here is the problem. By making
these protected, an important form of polymorphism is unnecessarily disallowed, since the
Construct() function cannot access them from a generic G4VModularPhysicsList pointer.
"So what?", you may say. Well, first it's poor object-oriented programming design to place
unnecessary limits on polymorphism. Polymorphism is one of the main reasons for having
c++, and it's short-sighted to restricte it without just cause. In this case, it should be trivial
to write a very simply user physics list that makes it possible to pick between any number of
concrete physics lists at run time, using one member function and a messenger.
Of course there are other ways to program this, but creating a pointer e.g. "theRealList" of
type G4VModularPhysicsList in the user physics list class "myPhysicsList" and defining e.g.
void myPhysicsList::ConstructProcess() {theRealList->ConstructProcess();} and similarly for
the other function, ConstructParticle(), is an especially simple and elegant approach that the
over-zealous applicated of "protected" in G4VModularPhysicsList makes impossible.
In my library that "protected" is now commented out. If someone has a good reason for it
being there, I'd appreciate knowing what it is. Otherwise, I strongly suggest that it disappear
in the next public release of Geant4, in the interest of good OOP design and user flexibility.
|
Feedback
]
icon
and there is no indentation. 
