Modules instead of Behaviors (was: Generalized Object Modules Design)

Richard A. O'Keefe ok at cs.otago.ac.nz
Wed Mar 6 22:23:15 UTC 2002


Anthony Hannan <ajh18 at cornell.edu> wrote:
	We are thinking of two different definitions for "module".  I was
	thinking of a module as an object that implements an interface [JIGSAW]*.
	 A class is a type of module, so is a "functionality" which is what I described. 
	You, Richard, Henrik, and many others define a module as a loadable
	unit, ie a changeset.

Well, no.  I was at some pains to point out that code can be chopped up
in several ways.  Because many languages (e.g., Erlang) _do_ identify
modules and load units, I assumed that _you_ meant modules to be that.
I don't have a precise definition of "module", except the old Parnas
sense:  a "module" is a chunk of program that hides something.

One thing I am sure about:
    Modules should be cohesive and should be loosely coupled.
("Should", not "must".)

	To avoid this confusion in the future I will not
	use the term module and instead use terms like behavior, functionality,
	changeset, layer. or loadable unit.  All of which have been called
	modules before but actually have different meaning.  So in my original
	post under the "Modules instead of Behaviors" thread please substitute
	"functionality" for "module" (including in the subject).
	
The traditional argument for abstract data types and OOP was that
a "module" based on "functionality" was not cohesive.  The only example
we've been given so far is "printing", and while my criticism talked about
loading, the fundamental problem is cohesion ("printing" in the sense of
#printOn: just isn't all that cohesive) and coupling (it would have to
know about several sorts of Morphs with their fullPrintOn:, Object and
ExternalObject with longPrintOn:, AppleScript, 3D graphics, and a lot of
other things with printOn:, ...).  Whatever a Module is, I want it to be
something that improves the structure of my code.  Slicing it _that_ way
doesn't seem to do the job.

Clearly I don't understand yet whatever it is you have in mind.
Can you provide some examples of exactly what kind of slice you are
thinking of and how it improves structure?

	Footnote [JIGSAW]:
	Gilad Bracha, "The Programming Language Jigsaw: Mixins, Modularity and
	Multiple Inheritance", Ph.D. thesis, Dept of Computer Science,
	University of Utah, March 1992.
	<http://citeseer.nj.nec.com/bracha92programming.html>
	
Thank you for this most interesting reference.
	



More information about the Squeak-dev mailing list