Uncle Bob lecture sources:

• https://www.youtube.com/watch?v=oar-T2KovwE&feature=youtu.be&t=1419
• https://www.youtube.com/watch?v=TMuno5RZNeE
• these lectures stopped at the L
  • but these notes cover a subset of material covered in Clean Code and Solid Principles For CSharp Developers
  • the lectures were interesting and had some cool moments

S - ingle Responsibility

O - pen-closed

L - iskov substitution

I - nterface segregation

D - ependency Inversion

---

Uncle Bob Talk

• C# came from Java
• Java came from C++

What is OO?

• what is object orientation?
• behavior resides with data in a class
• polymorphism is key to OO

• polymorphism gives you absolute control over your dependency structure

  • polymorphism allows making the compile-time dependency point against the flow of control

  M calls F via interface (I)
  
                       compile-time dependency
                      <------
  -----                      -----
  | M |    -->    I   <--    | F |
  -----                      -----
         ----------------->
          flow of control
  
  

• OO is the ability to decide
• can avoid writing fragile rigid non-reusable modules
• can get around what goes wrong with software
• by carefully deciding which direction the arrows between modules should point
• that's what OO is

OO is about managing dependencies by selectively inverting certain key dependencies in your architecture so that you can prevent rigidity, fragility, non-reusable code

rigidity: "snaking dependencies"; code is rigid if it is difficult to make a change in one place without triggering the need for a change in other areas of the code

• a strong indicator of rigidity is the need for many modules to compile whenever a change in one place is made
• rigid code eventually causes managers to not allow fixing minor bugs due to fear that the seemingly simple fix will take an unpredictably long amount of time
• code is at the opposite end of the spectrum from rigidity if nothing has to recompile after a change (other than one one place the change was made)

fragility: surprise dependencies; code is fragile, if it breaks in unexpected places that aren't even related conceptually to the code that was changed

• a result of fragility is production code failing in an area of the program seemingly unrelated to the code that was changed
  • emphasis on production code
• fragile code causes customers to lose faith in the quality of the software and in the engineers ability to maintain it

rigidity and fragility (and other terms) defined by uncle bob:

• http://www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/materials_adicionals/principles_and_patterns.pdf

... now getting to SOLID ...

• what's a reason to change?
• answer: a person or group of people who will ask you to
  • e.g. Employee object with save method, pay method, and report method
  • DBA or CTO (save method)
  • Payroll or CFO (pay method)
  • HR or COO (report method)
  • this example is not following the single responsibility principle
• another way to put it: gather together the things that change for the same reasons; separate the things that change for different reasons

A class should be open for extension but closed for modification

• you should be able to change what a class does without changing the source code of the class
• deploy polymorphic interfaces at the change points
  • guessing where these change points are is difficult

1966: 1st object oriented language was written (20 years after 1st computer built)

Derived classes must be usable through the base class interface, without the need for the user to know the difference.

- Barbara Liskov

This is polymorphism.

Square/Rectangle problem

• a square is a rectangle by definition in geometry
• however in programming, square has one field--height; rectangle has 2 fields--height, width

The representatives of things do not share the relationships of the things that they represent.

To have square inherit from rectangle would violate the LSP.