NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/mac/oop/misc/144

Text File | 1992-12-29 | 8.0 KB | 142 lines

Newsgroups: comp.sys.mac.oop.misc
Path: sparky!uunet!news.mentorg.com!scherzo!bcohen
From: [e-mail] (Bruce Cohen)
Subject: Re: Learning App Frameworks (was Re: THINK Class Library learning..)
Sender: [e-mail] (News User)
Message-ID: <[e-mail]>
Date: Tue, 29 Dec 1992 21:30:57 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: scherzo.mentorg.com
Organization: Mentor Graphics Corporation
Keywords:
Followup-To:
Lines: 127

Damn! He hit one of my hot buttons!
In article <[e-mail]>, [e-mail] (P. Hawthorne) writes:
|> ...
|> I feel that the programming language alone cannot make a framework
|> understandable any more than you can pick your friends out of a
|> metropolitan phone book. It can help make the code clear, but the framework
|> is not the code that it is composed of. The framework is also knowing the
|> mechanisms used and how to insert code into the works to get the job done
|> in less time with less effort.

In fact, you can (or at least should be able to) understand a framework
without knowing the details of the implementation, or even the syntax of
the implementing language.  A framework is an organization of parts and
a description of how they work together; in other words, it's a design
entity, not an implementation entity.  Note that I can read a Structured
Design description of a system without even knowing what language is
used to code it; understanding a framework should be the same.

|> The language can obviously be used to reveal points of interest to the
|> programmer. Mechanisms such as scheduling, event passing, dialog handling,
|> and this sort of thing should include plenty of calls to methods that the
|> programmer can simply override in the subclasses. Like, when the focus of a
|> dialog switches from one doohickey to another, there should be calls
|> before, between and after the focus is changed. In this way, the service
|> panels can be clearly marked, so to speak.

Here I think you're mostly talking about interface rather than
implementation; knowing what function is called to produce some effect
is not the same as knowing how it does the job.  In many situations all
you really *need* (as opoposed to what you might want to have) to write
an overriding method in a subclass is the signature of the method and
a set of assertions which describe the pre- and post-conditions for the
method.  Sure it's easier if you have some code to look at and maybe
reuse, but you could do without that.

|> Still, you should be able to look at the framework from much higher up than
|> the class and the method. In the framework I am working on, a programmer
|> can tell the framework that when class A asks for an instance of class B,
|> that it should instead return an instance of class C. The intent of this
|> was to make it so that the programmer could replace, say, the document
|> class without even knowing that class A even exists.

Yes, this is the buddha-nature of frameworks :-).

|>
|> Measures like that, though, would in vain if the documentation didn't
|> describe the highest order mechanisms of the framework. One of many
|> examples is that there should be ample discussion of how a window, the
|> document and the contents of the document can share in the interaction with
|> the user. It is at this level of abstraction that the elegance of a
|> framework can be honestly appreciated. Somehow the developers manage to
|> keep from bragging about it!

Unfortunately, sometimes they don't have a lot to brag about :-(.  I do
wish that documentation wasn't a swear word to so many software people.
There are some examples of doing it right: the overview documentation
for InterViews for instance.  That's worth reading even if you don't
want to work with user interface software and don't write C++ code
because it shows the benefits of describing how the system fits
together.

I think the practice of not documenting framworks properly comes from a
general lack of understanding of what a framework is, even among people
who implement them.  In the last decade or so, software designers have
gotten used to building large subsystems with narrow interfaces, most of
whose details are (rightfully) hidden from the user, and so are not
documented.  A framework is a new sort of animal, a design and a
skeleton implementation of that design which is *intended* to be reused
by others who were not privy to the original implementation.  This
requires that the user be at least as knowledgable about the internals
of design, if not the implementation, as a maintainer would be.  And
we're typically not very good about giving maintainers adequate
documentation.

|> ...
|> I love the browser concept. It's a shame that, at least in my development
|> environment, I cannot browse through anything but the class hierarchy.
|> Wouldn't it be nice to be able to browse through the things I have been
|> calling mechanisms? Imagine browsing through a little graphical
|> representation of how objects send messages to their instance variable
|> acquaintances as they go through the paces of scrolling or something like
|> that. You wouldn't need to see distracting details, only those variables
|> containing the objects and the methods that are invoked. I wouldn't even
|> mind defining these browser packets within the code. The clarity of vision
|> and freedom from distraction would be worth plenty of keyboarding.
|>
|> I can always tell that I'm bashing my head against a wall whenever I begin
|> to think of ways to better my development environment, however. Anything
|> that would require changes to the language just isn't going to happen.
|> Symantec is priming Bedrock to be the end all, be all of application
|> frameworks. Why should they be concerned with these secondary issues when
|> they've got their next masterpiece to fret over? Ultimately, I've just
|> returned to the recurring theme that we are bombarded with specifics
|> because our interfaces don't know jack about our goals in general.

Actually, I think that the new generation of integrated development
environments based on databases (HP Softbench, CenterLine ObjectCenter,
ParcPlace ObjectWorks, etc., etc.) has the power to provide what you
want; though you might have to write your own user interface, at least
you won't have to rewrite the compiler or the database manager.  The
trick is add some additional information (perhaps using a front-end
preprocessor to the compiler or whatever the language uses) which
describes the relationships you are interested in (the "isA" and "contains"
relationships are already handled by most languages).  For instance, if
I have a framework for graphic layout, I might want to annotate objects
which are in the "constrains translation" relation to other objects.

My own frustration comes from not having tools which help me design the
frameworks in the first place.  Obviously (to me, anyway), Structured
Design and it's sisters and cousins and aunts just don't help with
this sort of problem, and CRC, while useful and fun, doesn't scale the
way I would like it to, nor does it deal well with the idea of a
framework as a template for a design rather than a complete design in
itself, something I think is needed for high reuse frameworks.

|> ....
|> I've been told that Ralph Johnson expounded on the subject in the OOPSLA
|> '92 proceedings. I'll have to check that out. Thanks for the pointer, Dan.

Definitely, read Ralph's paper.  He talks about documenting frameworks
by describing patterns formed by the relationships and interworking of
parts of the framework.  I'm hoping that extensions of this idea can
result in pattern languages for both initial design and documentation.
------------------------------------------------------------------------
Bruce Cohen, Mentor Graphics Corpooration | email: [e-mail]
8005 SW Boeckman Road                     | phone: [phone]
Wilsonville, OR 97070-7777                |