I have continually repeated in my ranting about employing sound design techniques that the use of good design transcends any technology. The use of patterns is just that kind of " transcendental experience" (apologies to Karl Rahner) you can utilize to enforce sound design principles in any technology, including .NET. Given enough time and experience, every developer, consultant, or similar professional vein has been through the gamut of providing a great solution they have known they have seen before. Maybe they've even provided the same solution but with different tools and technology. Those folks may now understand that when it comes to design, a good design is a good solution, despite the technology. No matter how good the technology may be, it is only as good as its design and specifically the implementation of it. In fact, a great design with older technology may still be good, but a bad design with good technology is usually just bad.
Table 1.2. An overview of .NET and its major selling features over other platforms
Many developers have used sample code or specific snippets of implementation to ease the pains of beginning development. The implementation of that code may or may not be generically repeatable but it provides you with a starting point. It provides a reference from which to remorph the existing code into something completely different. Patterns provide this aspect to an architecture or design and usually at the object level. But that does not mean they couldn't be deployed at other levels.
Patterns are repeatable and named ideas that that can be applied to a design, architecture, or implementation. This means more than just traditional design patterns of repeating a set of prearranged classes forming an object hierarchy. It can apply to any elements, some of which may be technology-specific . This doesn't mean that patterns should not be technology- agnostic . In fact, those that do transcend technology are considerably more useful in a designer's career. However, there may be elements of the pattern that leverage a particular technology's strong suit. As already mentioned, I will be presenting this form of technology leveraging when we get into some implementation and architecture patterns later on. Hopefully, I will provide you with all of the above ”design patterns that transcend .NET, implementation patterns that predicate themselves on technology, and architectural patterns that do both.
Later, I will delve deeper into what patterns are, how they can be categorized, and how they are presented in this book. Along the way, I also give brief primers of the essential elements of object orientation so that this book can stand on its own without sifting through other references. How do you make tangible a design that is intangible yet very repeatable? How do you come up with something you've done before or even what others have done before but maybe in a new way (hint: or with a new technology)? If you are thinking to yourself, UML, you are close but not quite. UML helps but it really only contains the hieroglyphics (or language) you may need to convey your design. It is the standardized and fossilized assemblage of those UML symbols we need. Enter design patterns.