fredv/gist:2035960

## gistfile1.txt
Collected Ideas on OOP and Software Design as of now

Just One Idea (Jeff Casimir et. al.)
  Application - ONE value proposition (monolithic is crappy)
  Module - collection of ideas
  Class - one domain
  Method - one purpose
  Line - one thought

Clarity over brevity: (Jeff Casimir et. al.)
  - No more STI (Just rails)
  - Module self.included pattern harmful because of side effects => Delegation, Injection instead => clarify responsibility
  - Turn scopes into class methods
  - Brevity is side effect of refactoring, not goal.

Coupling and Cohesion (Kent Beck et. al.)
  - probability driven (what are the chances that i am going to change my database server architecture, YAGNI)
  - Just one idea can be rule of thumb for separation or merging of code
  - looser coupling eases testing
  - higher cohesion should make things more understandable

Tell, Don't Ask (e.g. Alec Sharp, Smalltalk by Example, 1997)
  - Don't ask objects about their state, make a decision and tell object what todo; rather move this code into the object, since it's probably the objects responsibility
  - Public getters only to gather information about state of object, but not to base decisions upon
  - Code smell or sign for lack of cohesion, too much coupling (between "asking" caller and "told" object)
  - feature envy, since functionality probably rather belongs to object for higher cohesion and clear responsibility
  - breaking law of demeter may be sign for this (a.k.a. reaching through to objects getters or even subobjects, "tree.apples.ripe.first.eat!")

Design patterns as Toolbox (Martin Fowler et. al.)
  - most problems have already been solved by someone
  - not just for the sake of the pattern, but as rule of thumb for better structure of the evolving code
  - timeframes for refactoring
  - early refactoring as practice of improving skills and to reduce technical debt, increase further flexibility, agility towards functional changes and adaptions

=> Make implementation fade away, closer to natural language / what you are doing.
=> Naturally readable code makes refactoring much easier. So first step: Try to explain by naming what the code is doing (or supposed to). Whenever this is hard or too general or implies ExtractMethod/ExtractClass one has a starting point for a refactoring.
	Collected Ideas on OOP and Software Design as of now

	Just One Idea (Jeff Casimir et. al.)
	Application - ONE value proposition (monolithic is crappy)
	Module - collection of ideas
	Class - one domain
	Method - one purpose
	Line - one thought

	Clarity over brevity: (Jeff Casimir et. al.)
	- No more STI (Just rails)
	- Module self.included pattern harmful because of side effects => Delegation, Injection instead => clarify responsibility
	- Turn scopes into class methods
	- Brevity is side effect of refactoring, not goal.

	Coupling and Cohesion (Kent Beck et. al.)
	- probability driven (what are the chances that i am going to change my database server architecture, YAGNI)
	- Just one idea can be rule of thumb for separation or merging of code
	- looser coupling eases testing
	- higher cohesion should make things more understandable

	Tell, Don't Ask (e.g. Alec Sharp, Smalltalk by Example, 1997)
	- Don't ask objects about their state, make a decision and tell object what todo; rather move this code into the object, since it's probably the objects responsibility
	- Public getters only to gather information about state of object, but not to base decisions upon
	- Code smell or sign for lack of cohesion, too much coupling (between "asking" caller and "told" object)
	- feature envy, since functionality probably rather belongs to object for higher cohesion and clear responsibility
	- breaking law of demeter may be sign for this (a.k.a. reaching through to objects getters or even subobjects, "tree.apples.ripe.first.eat!")

	Design patterns as Toolbox (Martin Fowler et. al.)
	- most problems have already been solved by someone
	- not just for the sake of the pattern, but as rule of thumb for better structure of the evolving code
	- timeframes for refactoring
	- early refactoring as practice of improving skills and to reduce technical debt, increase further flexibility, agility towards functional changes and adaptions

	=> Make implementation fade away, closer to natural language / what you are doing.
	=> Naturally readable code makes refactoring much easier. So first step: Try to explain by naming what the code is doing (or supposed to). Whenever this is hard or too general or implies ExtractMethod/ExtractClass one has a starting point for a refactoring.