Re: [Alephmodular-devel] File organization and multiple platforms?
Status: Pre-Alpha
Brought to you by:
brefin
From: Woody Z. I. <woo...@sb...> - 2003-01-29 16:27:18
|
On Monday, January 27, 2003, at 07:59 PM, Br'fin wrote: > <class file>.h > <class file>.cpp > <class file>_<platform>.cpp > Don't forget <class file>_<platform>.h; different platforms could provide different interfaces (probably extended in one way or another) and various bits of code may want to get at those extensions (after checking their availability, perhaps with dynamic_cast<> e.g.). Naturally the 'main interface' should cover as much as possible, but that doesn't necessarily mean it would be wise to restrict all uses to only that interface. Actually hmm, how exactly should this work out? // Class.h class IClass { all pure virtual, virtual destructor }; // Class.cpp (do-nothing destructor) // Class_Shared.h class CClass_Shared : public IClass { methods that most folks will be able to use regardless of platform }; // Class_Shared.cpp (implementations for those) // Class_Carbon.h class CClass_Carbon : public CClass_Shared { platform-specific methods, including perhaps overrides of some in CClass_Shared }; // Class_Carbon.cpp (implementations for those) This way a platform that does things radically different or something can use only the interface, and not inherit any of the default behavior of the shared class. OTOH platforms that have a lot in common can share that common code. ("Template Method", anyone?) Perhaps Class_Shared should have a more descriptive identifier than "Shared", that indicates something about its implementation approach - so that there can be other shared superclasses later that take a different approach. Of course whenever practical, CClass_Shared should target a platform-neutral interface, and accept one or more platform-specific helper objects that implement that interface (perhaps requested from a Factory) to do its work, to help avoid 'combinatorial explosion'. But I probably didn't need to state that. Woody |