Actually, you will find that most/all frameworks used by
commercial software developers achieve both 1 and 2 - and in fact,
those are the two most important goals.
For example, in a former life, I used to maintain one of the
frameworks used by Adobe Systems for their software. As such, I was
one of the only people on the team (and we're talking multiple teams
of 10+ people per team) who ever touched platform-centric code. All
of the platform-centricity, from file I/O and memory management all
the way up to windows, dialogs & widgets had been abstracted out.
And if you look at any Adobe product, it looks and feels like a
native application, because it is!
>The significance of item [3] should not be overlooked -- whenever possible,
>all business-logic should be in XP code
No argument there!
>My goals in building abi framework, were [1], [4], [3], and [2], and in that
>order. That is, we were able to minimize platform code as a side-effect of
>[3] and [4], but not eliminate it.
IMO, the problem with the current abisource framework is that
it doesn't go far enough in the XP abstraction, in terms of the
GUI-related issues. You now have enough experience and example
dialogs & widgets to sit down and design higher level "wrapper"
classes for all this stuff. Do it NOW before you get further and
further down the platform-centric path...
>Part of this is an artifact of the naming scheme we chose for the class
>hierarchies. We put the platform name in the class -- this gives us unique
>function names in LXR and makes it easy to see the line between platform
>and XP code, but does force an explicit branch to platform code. For example,
>we have an abstract GR_Graphics class, from which the GR_Win32Graphics and
>GR_UnixGraphics classes are derrived. All the methods are virtual, but
>because of the naming, platform code has to call the constructor even though
>all the drawing happens in XP code using the base class definition and the
>virtual methods.
The way to solve this is to use a higher level object
(GR_Graphics) which knows which platforms it's been compiled for and
"shims" to the appropriate platform-centric class. Using inlines
for many/most of the methods will also help avoid speed issues with
the extra level of indirection.
>Often you'll see nearly identical blocks of platform code,
>with platform class names being the only difference.
And that's just (IMO) silly! It's easy to fix - so do it!
Leonard
----------------------------------------------------------------------------
You've got a SmartFriend in Pennsylvania
----------------------------------------------------------------------------
Leonard Rosenthol Internet: leonardr@lazerware.com
America Online: MACgician
Web Site: <http://www.lazerware.com/>
FTP Site: <ftp://ftp.lazerware.com/>
PGP Fingerprint: C76E 0497 C459 182D 0C6B AB6B CA10 B4DF 8067 5E65