学习杂记 C# design pattern

Interface & Abstract class

• Abstract class can have method that has been implemented. Can’t create an instance of abstract class. One class can only inherited from one abstract class.
• Interface methods all must be abstract. Can’t have the implementation in the interface. A class can Inherit from multiple interface, but need to implement all its methods

UML

• For Class Diagram, the symbols in front of the names indicate that member’s visibility, where “+” means public, “- ” means private, and “#” means protected. Static methods are shown underlined. Abstract methods may be shown in italics or, with an “{abstract}” label. Note that UML does not require that you show all of the attributes of a class, and it is usual only to show the ones of interest to the discussion at hand.
• You represent inheritance using a solid line and a hollow triangular arrow. For the simple Employee class that is a subclass of Person,
• An interface looks much like inheritance, except that the arrow has a dotted line tail.

Design Pattern

The Adapter pattern is used to change the interface of one class to that of

another one.

The Bridge pattern is designed to separate a class’s interface from its

implementation so you can vary or replace the implementation without

changing the client code.

The Composite pattern is a collection of objects, any one of which may be

either itself a Composite or just a leaf object.

The Decorator pattern, a class that surrounds a given class, adds new

capabilities to it and passes all the unchanged methods to the underlying

class.

The Façade pattern groups a complex set of objects and provides a new,

simpler interface to access those data.

The Flyweight pattern provides a way to limit the proliferation of small,

similar instances by moving some of the class data outside the class and

passing it in during various execution methods.

The Proxy pattern provides a simple placeholder object for a more

complex object that is in some way time consuming or expensive to

instantiate

The Single-Responsibility Principle

A class should have only one reason to change.

The Open/Closed Principle (OCP)

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.