bebop.code

Dependency inversion principle In object-oriented design, the dependency inversion principle is a specific form of decoupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states: High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces). Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions. By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming. The idea behind points A and B of this principle is that when designing the interaction between a high-level module and a low-level one, the interaction shou...

Interface segregation principle In the field of software engineering, the interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces that 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. using   System ; namespace   interfacesegregation {      public   class   Document       {     }      public   interface   IMachine       {          void   Print ( Document   d );          void   Scan ( Document   d );     ...

  SOLID (3/5) - Liskov substitution principle Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of the program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping. It is a semantic rather than merely syntactic relation, because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular. using   System ; namespace   Liskov {      public   class   Rectangle     {          //public int Width { get; set; }   ...

Specification Pattern In computer programming, the specification pattern is a particular software design pattern, whereby business rules can be recombined by chaining the business rules together using boolean logic. The pattern is frequently used in the context of domain-driven design. using   System ; using   System . Collections . Generic ; namespace   opencloseprinciple {      public   enum   Color  {  Red ,  Green ,  Blue  }           public   enum   Size  {  Small ,  Medium ,  Large  }      public   class   Product     {          public   string   Name  {  get ;  set ; }          public   Color   Color  {  get ;  set ; }      ...

  SOLID (2/5) - Open Close Principle In object-oriented programming, the 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 extended without modifying its source code. using   System ; namespace   Invoice {      public   abstract   class   Invoice     {          public   virtual   double   GetInvoiceDiscount ( double   amount )         {              return   amount  -  10 ;         }     }           public   class   FinalInvoice  :  Invoice     {  ...

 SOLID (1/5) - Single Resposibility Principle The single-responsibility principle (SRP) is a computer-programming principle that states that every class in a computer program should have responsibility over a single part of that program's functionality, which it should encapsulate. All of that module, class or function's services should be narrowly aligned with that responsibility. In the following example we have a TodoList class which only handles it's own functionality logic, and then we have a Persistance class which handles the saving logic, hence keeping the concerns separeted. using   System ; using   System . Collections . Generic ; namespace   Journal {      public   class   TodoList     {          private   readonly   List < string >  _entries  =  new   List < string >();          private...