Part I RI AL Introducing Patterns and Principles TE ⊲⊲ Chapter 1: The Pattern for Successful Applications CO PY RI GH TE D MA ⊲⊲ Chapter 2: Dissecting the Pattern’s Pattern
1 The Pattern for Successful Applications What’s In This Chapter? ➤➤ An introduction to the Gang of Four Design Patterns ➤➤ An overview of some common design principles and the SOLID design principles ➤➤ A description of Fowlers Enterprise Patterns John Lennon once wrote, “There are no problems, only solutions.” Now, Mr. Lennon never, to my mind, did much in the way of ASP.
❘ Chapter 1 The Pattern for Successful Applications Design Patterns Explained Design patterns are high-level abstract solution templates. Think of them as blueprints for solutions rather than the solutions themselves. You won’t find a framework that you can simply apply to your application; instead, you will typically arrive at design patterns through refactoring your code and generalizing your problem.
Design Patterns Explained ❘ 5 Patterns are an effective way to describe solutions to complex problems. With solid knowledge of design patterns, you can communicate quickly and easily with other members of a team without having to be concerned with the low-level implementation details. Patterns are language agnostic; therefore, they are transferable over other object-oriented languages.
❘ Chapter 1 The Pattern for Successful Applications Design Principles Design principles form the foundations that design patterns are built upon. They are more fundamental than design patterns. When you follow proven design principles, your code base becomes infinitely more flexible and adaptable to change, as well as more maintainable. I will briefly introduce you to some of the more widely known design principles and a series of principles known as the S.O.L.I.D. principles.
Design Principles ❘ 7 a class. The act of separating a program into discrete responsibilities significantly increases code reuse, maintenance, and testability. The remainder of this book refers back to these principles so you can see how they are implemented and help form clean and maintainable object-oriented systems. The next group of design principles you will look at were collected together under the grouping of the S.O.L.I.D. design principles. The S.O.L.I.D. Design Principles The S.O.L.I.D.
❘ Chapter 1 The Pattern for Successful Applications Dependency Injection (DI) and Inversion of Control (IoC) Closely linked to the DIP are the DI principle and the IOC principle. DI is the act of supplying a low level or dependent class via a constructor, method, or property. Used in conjunction with DI, these dependent classes can be inverted to interfaces or abstract classes that will lead to loosely coupled systems that are highly testable and easy to change.
Fowler’s Enterprise Design Patterns ❘ 9 Domain Model The Domain Model pattern is an abstraction of real domain objects. Both data and behavior are modeled. Complex relationships between objects can exist that match the real domain. You will look at how to use each of these patterns in ASP.NET and when it is appropriate to choose one pattern over another.
❘ Chapter 1 The Pattern for Successful Applications properties and classes rather than real tables and columns. Typically, you will also have a translator object to generate the native SQL to query the database. Web Presentation Patterns In Chapter 8, you will turn your attention to the presentation needs of enterprise-level ASP.NET applications. The chapter focuses on patterns designed to keep business logic separate from presentation logic.
Other Design Practices of Note ❘ 11 Other Design Practices of Note In addition to the design patterns, principles, and enterprise patterns that have been covered so far, I would like to introduce you to a few design methodologies: test-driven development, behavior-driven development, and domain-driven development. This section won’t cover these topics deeply because they are out of the scope of this book.
❘ Chapter 1 The Pattern for Successful Applications Behavior-driven Design (BDD) You can think of BDD as an evolution of TDD merged with DDD. BDD focuses on the behavior of a system rather than just testing it. The specifications created when using BDD use the same ubiquitous language as seen in the real domain, which can be beneficial for both technical and business users.
