MI-DPO Návrhové vzory a OOP

S : Single Responsibility Principle
O : Open Closed Principle
L : Liskov Substitution Principle
I : Interface Segregation Principle
D : Dependency Inversion Principle

• SRP - single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.
• OCP - open/closed principle states “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” that is, such an entity can allow its behaviour to be modified without altering its source code.
• LSP - Liskov substitution principle. It states that, if S is a subtype of T, then objects of type T in a computer program may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T), without altering any of the desirable properties of that program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy.
• ISP - Interface Segregation Principle is a software development principle used for clean development and is intended to help a developer avoid making his software impossible to change. If followed, the ISP will help a system stay decoupled and thus easier to refactor, change, and redeploy. The ISP says that once an interface has gotten too 'fat' it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them.
• DIP - dependency inversion principle refers to a specific form of decoupling where conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are inverted (e.g. 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.

• 1 z: Facade, Mediator
  • FinancialCalculator
• 1 z: Abstract Factory, Factory Method, Singleton
  • Factory - FinancialCalculator » PaymentSchedule
  • Singleton - TaskManager » LinqDAO
• 1 z: Adapter, Proxy, Bridge, State, Command
  • Adapter - Radar » Ares » Request, Response, Query, Answer
  • Proxy - TakManager » Modeling agency
• 1 x: Strategy
  • FinancialCalculator » InterestCalculator » Percent_Interest
• 1 x: Observer
  • Worker
• +1 libovolný, který ještě nebyl použit