OOP Guidelines

related:

SOLID Object-Oriented Design by Sandi Metz [] extract points from Kent Beck books, SBPP and Implementation patterns book [] from discussion here: https://stackoverflow.com/questions/1866794/naming-classes-how-to-avoid-calling-everything-a-whatevermanager

Summary

guidelines

TDD –> emergent features OOP –> emergent design

Tests

• Without tests refactoring cannot be done to create right abstractions,  OOP design, to create maintainable code.
• There should be tests.
• Tests are prerequisites.

Classes

1. Right level of abstraction
   1.  not too general, not too specific
2. Should represent important  concept of problem domain
3. Don’t use “er” names
   1. * they dilute meaning, being very general; managed are plain old data structures and manager is smart procedure.*
   2. good OOP requires respectable objects with equal partnership, not dumb and smart combo.
4. Name class after what they are - not what they do
   1. https://www.yegor256.com/2014/11/20/seven-virtues-of-good-object.html#6-his-name-is-not-a-job-title
   2. Naming classes: 99 bottles of OOP
      1. Creating right abstractions are more important than DRY
      2. Build good abstraction from concrete examples of code - use triangulation - and then make it DRY.

Methods

1. name them after WHAT they do, not after HOW.
2. commands -> verb
3. queries -> noun
   1. use name “result” for variable that gets returned; Martin Fowler
   2. use being verbs with boolean returning names
      1. is_finished() -> True or False [Kent Beck]
4. name of method should be at one higher level of abstraction that its implementation
   1. not at equal level; not at more than 1 level; just 1 level higher
   2. much higher level of abstraction will not capture important concept
   3. equal level does not let any benefit of creating abstraction
5. Do not mix levels of abstractions in a method
   1. things at similar level of abstraction are read easily

Temporary Variables:

1. name then after ROLE
   1. type can be inferred from context
      1. Smalltalk best practice patterns

Parameters

1. name then after TYPE, esp in dynamic typed languages like python

def salary(anEmployee):
  ...