Collection of Ideas on OOP and Software Design by various minds I stumbled upon

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 (locality of things)

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.