Structuring packages to minimize 'bad' dependencies

Stephan Rudlof stephan.rudlof at ipk.fhg.de
Fri Nov 19 00:36:32 UTC 1999


############
Introduction
############

In the following there are some thoughts regarding semantics and
structuring of different package types to minimize 'bad' dependencies.

It's very important to minimize the number of dependencies between
packages and to ensure a high quality of the dependencies left by a
good classification and structuring of them.
Only then the code is good
- understandable,
- maintainable,
- reusable.


###########
Definitions
###########

'Interface' means the public usable methods, classes and objects
exported
from a package.

- The System Package (SP) has an almost unchangeable interface. It
  consists of the standardized (ANSI?) Smalltalk classes.
- Basic Packages (BP) are thought as proven packages with a stable
  interface, which normally has to be downwards compatible to earlier
  versions. Then other packages could use them and trust in, that the
  interface won't be broken in later versions. But there is also the
  flexibility to extend the interface.
- Normal Packages (P) are unsafe: No other package can be sure, that
  the interface won't be changed in the future. The interface is
'changeable'.


SP : System Package
BP : Basic Package
P  : Package


##########
Properties
##########

   |interface flexibility   | uses   | used by
---+------------------------+--------+--------------+    
SP |very frozen (e.g. ANSI) |  SP    | all          |
---+------------------------+--------+--------------+
BP |downwards compatible *) |  SP    | P            |
---+------------------------+--------+--------------+
P  |medium, can change      | SP,BPs | applications |
---+------------------------+--------+--------------+

*) to earlier versions


#############
Design issues
#############

Good design: Changeable packages P1, P2, P3, P4, P5 and P6 depend only
from stable packages SP, BPa, BPb, BPc, BPd.


    +<-BPa<-+<----------P1
    |       |           |
    |       +<-+        |
    |          +<--P2   |
    |       +<-+   |    |
    |       |      |    |
    +<-BPb<-+      |    |
    |       |      |    |
    |       +<-P3  |    |
    |          |   |    |
    |          V   V    V
SP<-+<---------+---+----+
    |          ^   ^    ^
    |          |   |    |
    |       +<-P4  |    |
    |       |      |    |
    +<-BPc<-+      |    |
    |       |      |    |
    |       +<-+   |    |
    |          +<--P5   |
    |       +<-+        |
    |       |           |
    +<-BPd<-+           |
            |           |
            +<----------P6



Bad design I:

P1<--->P2

P1 depends on P2 and vice versa:
In this case P1 and P2 can be treated as _one_ package P_12 with a
common interface, because P1 makes no sense without P2 and vice versa.



Bad design II: P3 depends on two changeable packages.

    +<-BPa<-+<---------------+
    |       |                |
    |       +<-+             |
    |          +<--P2<--P3-->P1
    |       +<-+   |         |
    |       |      |         |
    +<-BPb<-+      |         |
    |              |         |
    |              |         |
    |              |         |
    |              V         V
SP<-+<-------------+----+----+



Bad design III: There are only changeable packages  (except SP),
  and P3 depends on changeable package P1, and P4 on P2.

    +<-P1<-+<----------P3
    |                  |
    |                  |
    |                  |
    |                  |
    |                  |
    +<-P2<-+           |
    |      |           |
    |      +<-P4       |
    |         |        |
    |         V        V
SP<-+<--------+--------+



#####################
Conclusions and Hints
#####################

- Avoid too much dependencies between packages, as less as better;
- prefer a flat structuring of packages (not a deep nesting);
- be very conservative and careful regarding changes of existing Basic
  Packages which are the mother of an unknown number of other packages.


Stephan

sr (stephan.rudlof at ipk.fhg.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3





More information about the Squeak-dev mailing list