.NET Best Practices and Design Patterns Flashcards
Decorator Pattern
Increases complexity setting up the chain of decorators.
Supports the Open/Close Principle.
Decorated object is not the object.
Decorator in the .NET Framework
Stream classes use decorators.
BufferedStream and CryptoStream classes decorate a Stream.
Adapter Pattern
Translates one interface for a class into a compatible interface.
An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface. The adapter translates calls to its interface into calls to the original interface, and the amount of code necessary to do this is typically small. The adapter is also responsible for transforming data into appropriate forms.
Adapter Pattern Implementation
Find Commonality: Commonality is extracted to an interface
Encapsulate Differences: Incompatible classes are wrapped by an adapter
Client works with the adapter class
Adapter Pattern in the .NET Framework
DataAdapter classes convert the interfaces of ventor-specific database classes into an interface that works with the general DataSet class: SqlDataAdapter, OdbcDataAdapter, etc.
DataSet class in namespace System.Data.
Template Method Pattern
Defines the program skeleton of an algorithm in a method, called template method, which defers some steps to subclasses.
It lets one redefine certain steps of an algorithm without changing the algorith’s structure.
Template Method Pattern Implementation
Find Commonality: Common parts of the algorithm are factored into a base class.
Encapsulate Differences: Differences (customization points) are encapsulated in derived classes.
Allows the customization points to be seamlessly integrated.
Template Method Pattern in the .NET Framework
The sequence of events for a form is fixed. The details of the steps are customizable.
SOLID Principles
Single Responsibility Principle: A class should have only one reason to change
Open/Closed Principle: Classes should be open to extension and closed to modification
Liskov Substitution Principle: Derived classes should honor the base class’ contract Interface
Segregation Principle:
Dependency Inversion Principle:
Single Responsibility
Class should have a single responsibility, and that responsibility should be entirely encapsulated by the class.
All its services should be narrowly aligned with that responsibility.
Open/Closed Principle (OCP)
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
Entities can allow their behaviour to be modified without altering its source code. This is especially valuable in a production environment, where changes to source code may necessitate code reviews, unit tests, and other such procedures to qualify it for use in a product: code obeying the principle doesn’t change when it is extended, and therefore needs no such effort.
Liskov Substitution
Derived classes must be substitutable for their base classes.
Derived classes must be consistent with the promises made by the base class’ contract. Derived classes add data, add behavir, but do not remove behavior.
Interface Segregation Principal (ISP)
Interfaces are owned by clients, not implementors.
No client should be forced to depend on methods it does not use. ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. Such shrunken interfaces are also called role interfaces. ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.
Dependency Inversion Principal
Details depend on abstraction.
Isolates business logic from data access logic. Allows us to write a strategy for data access, so it can be faked. Specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (i.e. reversed) for the purpose of rendering high-level modules independent of the low-level module implementation details. The principle states: A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend upon details. Details should depend upon abstractions.
Role Object Pattern
Adapt an object to different client’s needs through transparently attached role objects, each one representing a role the object has to play in that client’s context.
The object manages its role set dynamically. By representing roles as individual objects, different contexts are kept separate and system configuration is simplified. Uses delegation to solve the problem of roles.
Which gives more run-time flexibility: composition or inheritance?
Composition
What tests can help determine correctness of inheritance?
N/A
Is it better to depent on wider or narrower interfaces?
Narrower
Repository Pattern
Separates the querying from the filtering.
Matches method -Returns Ienumerable -Passed a filter object Icriteria -Can handle the three standard return cases: None, One, Lots Add method Remove method SaveChanges method
Mock Object Pattern
TestInitialize attibute
N/A
ClassInitialize attribute
N/A
Domain Model
An object model of the domain that incorporates both behavior and data.
At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it’s this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.
Table Module
A single instance that handles the business logic for all rows in a database table or view.
- An object that encapsulates an SQL query and related objects.
- A kind of middle ground.
- More use of objects than transaction script.
- Supplied in .NET by the DataSet/TableAdapter combination.
Pros:
- Many IDEs have direct support this pattern.
Cons:
- DataSet cannot express custom logic as part of the class.
- Serious logic must be external to the DataSet (i.e., separate classes and stored procedures)
- Weak support for navigating relationships.
- No support for inheritance/polymorphic behavior.
- Much duplication of queries and parameter-setting code.
One of the key messages of object orientation is bundling the data with the behavior that uses it. The traditional object-oriented approach is based on objects with identity, along the lines of Domain Model (116). Thus, if we have an Employee class, any instance of it corresponds to a particular employee. This scheme works well because once we have a reference to an employee, we can execute operations, follow relationships, and gather data on him.
One of the problems with Domain Model (116) is the interface with relational databases. In many ways this approach treats the relational database like a crazy aunt who’s shut up in an attic and whom nobody wants to talk about. As a result you often need considerable programmatic gymnastics to pull data in and out of the database, transforming between two different representations of the data.
A Table Module organizes domain logic with one class per table in the data-base, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model (116) is that, if you have many orders, a Domain Model (116) will have one order object per order while a Table Module will have one object to handle all orders.
Data Mapper
Mappers move data between objects and a database while keeping them independent of each other and the mapper itself.
Objects and relational databases have different mechanisms for structuring data. Many parts of an object, such as collections and inheritance, aren’t present in relational databases. When you build an object model with a lot of business logic it’s valuable to use these mechanisms to better organize the data and the behavior that goes with it. Doing so leads to variant schemas; that is, the object schema and the relational schema don’t match up.
You still need to transfer data between the two schemas, and this data transfer becomes a complexity in its own right. If the in-memory objects know about the relational database structure, changes in one tend to ripple to the other.
The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn’t know even that there’s a database present; they need no SQL interface code, and certainly no knowledge of the database schema. (The database schema is always ignorant of the objects that use it.) Since it’s a form of Mapper (473), Data Mapper itself is even unknown to the domain layer.
Class Table Inheritance
Represents an inheritance hierarchy of classes with one table for each class.
A very visible aspect of the object-relational mismatch is the fact that relational databases don’t support inheritance. You want database structures that map clearly to the objects and allow links anywhere in the inheritance structure. Class Table Inheritance supports this by using one database table per class in the inheritance structure.
Concrete Table Inheritance
Represents an inheritance hierarchy of classes with one table per concrete class in the hierarchy.
As any object purist will tell you, relational databases don’t support inherit-ance - a fact that complicates object-relational mapping. Thinking of tables from an object instance point of view, a sensible route is to take each object in memory and map it to a single database row. This implies Concrete Table Inher-itance, where there’s a table for each concrete class in the inheritance hierarchy.
I’ll confess to having had some difficulty naming this pattern. Most people think of it as leaf oriented since you usually have one table per leaf class in a hierarchy. Following that logic, I could call this pattern leaf table inheritance, and the term “leaf” is often used for this pattern. Strictly, however, a concrete class that isn’t a leaf usually gets a table as well, so I decided to go with the more correct, if less intuitive term.
Single Table Inheritance
Represents an inheritance hierarchy of classes as a single table that has columns for all the fields of the various classes.
Relational databases don’t support inheritance, so when mapping from objects to databases we have to consider how to represent our nice inheritance struc-tures in relational tables. When mapping to a relational database, we try to minimize the joins that can quickly mount up when processing an inheritance structure in multiple tables. Single Table Inheritance maps all fields of all classes of an inheritance structure into a single table.
Data Transfer Object Pattern
An object that carries data between processes in order to reduce the number of method calls.
When you’re working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program - indeed, it’s often impossible with languages such as Java that return only a single value.
The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects.
Many people in the Sun community use the term “Value Object” for this pattern. I use it to mean something else. See the discussion on page 487.
MVC
An uncoupling pattern where the state of the presentation is maintained in a separate control class.
Splits user interface interaction into three distinct roles.
Controller classes typically contain complex control logic.
- Complexity can be managed by implementing State and Observer patterns.
