*********************************************************** *** Structuring packages to minimize 'bad' dependencies *** *********************************************************** ############ 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@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