Daniel Jackson (firstname.lastname@example.org)
Fri, 22 Jun 2001 11:16:16 -0400
gonzalo, yes, that's one of the key points i make. i'm afraid i still don't understand your point of view though -- i don't see what you say that A is dependent on B! Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley 1995. /daniel At 07:29 AM 6/19/2001, Gonzalo Génova wrote: >Daniel, > >I have read and enjoyed your excellent lecture notes. You explain there how >a good design achieves navigability without incurring dependencies. Let me >simplify your reasoning and adapt it to UML: class A has a navigable >association to class B, and class C is a subclass of class B. At compile >time, A depends on B, but it does not depend on C. At run time, you can have >instances of A linked to instances of C, therefore you can navigate from >instances of A towards instances of C. You have achieved navigability from A >to C without dependency from A to C. > >But I think this is not in contradiction with what I had argued. At run-time >you have links, at compile-time you have associations. I said "navigability >creates a dependency", where I really meant "navigable associations create a >dependency". And this is true in the example: A has a navigable association >towards B that makes A dependent on B. > >BTW, I don't know the GoF book, could you give the full reference? > >Gonzalo > >-----Mensaje original----- >De: Daniel Jackson [mailto:email@example.com] >Enviado el: Friday, June 08, 2001 7:17 PM >Para: firstname.lastname@example.org; email@example.com >Asunto: RE: Dependencies and associations > > >gonzalo, > >At 12:20 PM 6/8/2001, Gonzalo Génova wrote: > >Daniel Jackson> associations and dependencies are completely different > >things. > > > Since navigability means knowing ... > > Second consequence, navigability creates a dependency > >no! navigability does not mean knowing, and it does not create a >dependency. that is arguably the central insight of most of the patterns in >the GoF book. an important part of design is figuring out how to achieve >navigability without incurring dependences. my lecture notes explain this >in detail (see below). > >/daniel > > >from intro to lecture 5 in >http://www.mit.edu/~6.170/Old-Fall00/handouts/lectures/lecture-notes.pdf > >... >The notion of dependence is essential for doing good software design. We’ll >define dependences, and see how the coupling they bring about causes >problems by making a program less flexible and harder to reason about. >We’ll examine three language constructs that can be used to reduce >dependences: procedures, global variables and Java interfaces. Interfaces >will be the most interesting and important of the three. > >We’ll see how, in an object-oriented language such as Java, the control >flow at runtime does not necessarily match the compile-time structure. This >will be exposed as mismatches between the object model and the module >dependence diagram. It’s a tricky notion, but a useful one, since it let’s >you use dynamic configuration to obtain flexibility. Java interfaces are >crucial support for this. Also, many of the design patterns we’ll see later >rely on this. >... > > > > >To remove yourself from this list please mail >firstname.lastname@example.org >with a message containing the word "unsubscribe". > > > > >To remove yourself from this list please mail email@example.com >with a message containing the word "unsubscribe".