Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!gatech!howland.reston.ans.net!agate!news.mindlink.net!vanbc.wimsey.com!fonorola!flexnet.com!news
From: hollings@flexnet.com (William Hollings)
Subject: Re: Factoring In Smalltalk
Organization: The Brenwill Workshop Ltd.
Date: Mon, 5 Jun 1995 02:29:51 GMT
Message-ID: <D9oHLs.DA6@flexnet.com>
X-Newsreader: WinVN 0.92.6
References: <3qj56f$eiv@mars.efn.org>
Sender: news@flexnet.com (News Admin User)
Lines: 56

In article <3qj56f$eiv@mars.efn.org>, Fred Warren <fwarren@gears.efn.org> says:
>
>I am very new to using smalltalk and am in the process of reading 
>several books on smalltalk to learn how to program.  So far most of
>the material is about making the shift from regular programming over
>to object orientated programming.
>
>In standard programming you try to factor out code into smaller
>subroutines because it is eaiser to follow and understand what is going
>on in 10 lines of code than in a 400 line subroutine.
>
>Does the same principle apply in Smalltalk?  If a method would be large
>and very complex, is there a way to factor it out into several
>methods.  I.e. a method that is only to be called by another medthod in
>the current object?
>
>How do you factor code in smalltalk?

In Smalltalk (and any other good OO environment) Factoring as you
describe it is the name of the game. In fact, the first order of factoring
your problem domain is to break it down into the domain Objects.
The idea is to neatly parcel your problem into object definitions
(ie-Classes) so that instances of each Class do one thing only, but
they do that one thing well. Furthermore, in a good OO design, that one
thing that the class does should be as general as possible (or realistic),
so that the class can be used in many aspects of your problem domain.
This is the essence of REUSE, where once a class is designed and
implemented, it can be reused over and over (in collaboration with other
classes) to solve a variety of problems. This is a direct result of
designing the classes to be as single-minded and general as possible.

(BTW, you may hear people discuss CODE reuse in the context of
inheritance and class hierarchies. This is a secondary form of reuse
which saves typing, memory and sometimes makes code maintenance easier.
Do not confuse the two uses of the word reuse in OO-speak).

Once the classes have been defined, the behaviour of that class is 
defined by the code in its methods. Just as you do with procedural code,
and just as we did above for classes, methods should be factored so that
each method is as simple (and hence reusable) as possible. This is also
important so that class hierarchies are as efficient as possible.

WRT how to do all this, that is the core question of OO Analysis and
Design. You can get an idea by simply browsing the methods in a Smalltalk
image. You will quickly notice that almost all methods are only a few
lines ong (and many are only a single line of code).

An excellent reference book that covers a lot of the above is:
"Design Patterns" by Erich Gamma, et al (Addison-Wesley).
In thre words: Get a copy. Also, the "Purple Book" by Goldberg and
Robson is the bible wrt the core concepts behind Smalltalk.

In addition, there are many fine intro books ("Discovering Smalltalk" by
Wilf Lalonde comes to mind).

Sorry for the long response everyone, I hope this helps...
