c2.com/cgi/wiki/wiki?DesignPatterns
Design Patterns Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
ChristopherAlexander A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.
Maybe because it is easier to look at something one has done and say "Oh, I shouldn't have done that" than it is to look at something one has done and say "My, that was successful. " I think it's the same reason it's easier to tell somebody what not to do than what to do.
Isn't the definition or existence of a problem a preceeding step to finding a solution? So to find a successful pattern you have to have first determined some failed approaches which offer needed contrast. Also, it is intuitively persuading to think that there are more ways to fail than to succeed.
ScottWalters This is an old, old argument in the Software patterns community. This subject has been brought up and rehashed at every single PLoP (and probably EuroPLoP) conference since the very first one.
DesignPatternsBook will tend to see new patterns in terms of their relationship to the 23. Someone will always be able to say "actually that's just a grey-green-blue."
AdewaleOshineye One can argue that many of the GoF patterns are not fundamental to OO design, but rather work around limitations in particular implementations of OO. For example, several patterns in the GoF book that work well in Java or C++ are unneeded in languages with a more powerful OO approach; That's an old, weak argument usually put forward by those who either don't understand the patterns much or haven't thought deeply about the capabilities of those languages.
did not invent those patterns, I would like to see a variation from the already well known patterns, which IMHO, would be more educative. As the 23 patterns are well known, it is easier to grasp related patterns. After several years of being around patterns, these 23 patterns seem low level -- at the level of two or three objects interacting with each other. For higher-level patterns, I dug out Plop and Plop 2 My favorite pattern from Plop is #2: A Pattern Language for Tool Construction and Integration Based on the Tools and Materials Metaphor.
PatternLanguage is supposed to include patterns for all levels of granularity. You select one that is fairly general to handle a general problem, then use progressively finer grained patterns as you get to more detailed levels of design. So what you say indicates that these software design patterns are in fact patterns in the Alexander sense.
Gamma et al does have an Interpreter which you can use to parse a simple grammar, but doesn't seem to have other parser or state machine patterns. But I have never coded a parser or state machine with objects, except by using the Interpreter approach.
ShieldPattern, which I would call a fundamental programming pattern. Just curious: any chance that patterns could come with example unit tests? I don't expect cookie-cutter unit tests in all available languages that would work 100% of the time for everyone, but I am thinking that, given a pattern, perhaps a suite of unit tests written in Java that could be used as a basis for creating your own unit tests?
that would describe the different types of unit tests you should expect to use when developing a solution using a particular pattern. The most obvious to me would be for instance in the Singleton pattern, you would have a unit test to ensure that only one instance of the object is ever created, etc. As a further note, the more I'm exploring unit tests, the more fun I'm having. I'd like to get into patterns more, but I also think that if a particular problem can have a particular architectural solution (a pattern), then that pattern can have a particular set of unit tests. Essentially think of it as a litmus test -- if your architecture can pass the unit tests for ABC, then it can be considered ABC pattern. In fact, I'd prefer them to be in prose form, so that we can then convert them into code ourselves for our particular testing frameworks. Then individuals could look at the pattern, see that there is a prose description of test X but no code in language Y for test X, so they implement the test in language Y and submit it back to the archive for inclusion. Then when you or I come along and want to test we already have the code available. Of course we customize patterns for our own internal use, but given a standard set of unit tests for a pattern, as long as your code passes those tests you are still considered to be using that pattern. OK I'm rambling quite a bit here, but hopefully you get the idea... I think that automated JUnit tests for at least the most obvious and well-known patterns would be a great idea but I also do think that the patterns themselves may serve as the "prose" of a unit test as they fairly well do describe / specify the pattern. Automated JUnit test creation however is quite difficult, given that a pattern can be occluded by other patterns also implemented in one unit, unless you require certain base classes or interfaces to be present. However, with UML and J2SE 15 and other languages that support attributed methods, fields and classes, it could be made possible and likewise be automated by some generic test tool - that would at least require some additional configuration or perhaps user-implemented callbacks - call it a framework. Developers trying to adopt XP practices find writing the unit tests as hard (or harder) than writing the objects under test. Finding ways to automate testing with things like JUnit requires some pretty good lateral thinking (and patience). I'd be interested to hear about anyone that has done a lot of unit testing and accumulated common patterns that crop up again and again;
If the reader is not conscious, that we are surrounded by patterns, if we, for example, do not point that the nature is build up from lots of patterns, then we will not convince him that easily about the importance of using them.
It must be discovered (determined by somebody) that it is general enough to be useful and applicable to lots of situations in systems design and development. A few brilliant guys identified the first ones, that were, in retrospective, the easiest to get. As time went by, the ones left were more and more difficult to discover, so what has been said about patterns and time is correct, but the inference produced does not stand. As time passes by, it takes much more effort to discover new patterns.
com/, which on this topic shows only the slashdot story so far): "ACM's Special Interest Group on Programming Languages (SIGPLAN) recently awarded the 2005 Programming Languages Achievement Award to Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the 'Gang of Four') for their creation of 'Design Patterns' (the computer science book and the subfield at the intersection of programming languages and software engineering). The annual award recognizes an individual (or individuals) who has (have) made a significant and lasting contribution to the field of programming languages."
sid=05/07/31/0046223&ti d=185&tid=14 * Credit for what appears to be first news report goes to Brent Hailpern, "a researcher at the IBM Thomas J Watson Research Center, in Hawthorne, New York."
|
http://csua.com/feed/