I agree with Berin. A simple:
This is how Avalon solves common problems: Problem: <antipattern 1> Example: <example of antipattern 1> Solution: <solution 1> <solution 1, concrete> Problem: <antipattern 2> Example: <example of antipattern 2> Solution: <solution 2> <solution 2, concrete> Problem: <antipattern 3> Example: <example of antipattern 3> Solution: <solution 3, abstract> <solution 3, concrete> . . . /LS > -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > Sent: den 27 juni 2002 15:35 > To: 'Avalon Developers List' > Subject: RE: AntiPattern Genius > > > > From: Leo Simons [mailto:[EMAIL PROTECTED]] > > > > > > Berin, > > > > > > > > > > > > I follow the Anti-Pattern thing since 4 years ago. I > like it. It > > > > is a great argument. > > > > > > > > What I disagree is about making the > central/introductory argument > > > > for Avalon. > > > > > > > > First show how it is great, THEN show how it avoids bad things. > > > > > > > > > :) How do you propose to show it is great without showing how to > > > avoid bad things? > > > > simple enough. Show current well-designed piece of OOP > > software. Then show how refactoring it to be avalonized is > > easy and has many advantages. > > Ho hum. > > It's just not compelling enough. :) > > > -- > To unsubscribe, e-mail: > <mailto:avalon-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
