Disciplined Inheritance, M. Sakkinen

"You can also extract some roles from the Website class. Some candidates in an e-commerce could be ProductRepository, OrderDepartment, NewsletterManager, Blog etc.

This logic is then injected runtime, at the object level, in the context of a specific use case. In my opinion contexts or use case fits very well with the rails thin controllers rule."

"Object-orientation is better for the higher levels of a system, and functional programming is better for the lower levels."

"This method of turning your code inside out is the secret to solving what appear to be hopelessly state-oriented problems in a purely functional style. Push the statefulness to a higher level and let the caller worry about it. Keep doing that as much as you can, and you'll end up with the bulk of the code being purely functional. "

"In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. We make class hierarchies in order to simplify the code by allowing different
parts of it to be changed independently of each other, and to eliminate duplication (which comes to the same thing). Without any context as to what the code needs to accomplish, you can’t make a judgment about whether a particular design decision is good or bad… A simple interactive graphical environment is a better alternative."

"Object schizophrenia or self schizophrenia is a complication arising from delegation and related techniques in object-oriented programming.
An object can be defined as a computing concept combining data and behavior, and having an identity. Objects are typically built on class systems. A base class provides the fundamental or default behavior of an object, and acts as a template for creating objects. A derived class can be used to override behaviors of a base class, and can be used as a template for objects whose behaviors refine those of the base class. As an alternative to inheritance — which is a relatively static concept — some programming languages use delegation, which is semantically equivalent.[1][dubious – discuss] Instead of using one class to refine another, delegation allows one object to override the behavior of another. The original object a (analogous to the base class behaviors) can delegate some of its methods to another object b (analogous to the derived class behaviors). If a delegates its foo method to the bar method of b, then any invocation of foo on a will cause b's bar method to execute. However, bar executes in the context of the a object — for example, its self identifier refers to a rather than to b.
When delegation is used, the question arises: What is the identity of the object a? The identity is split. There are two potentially meaningful self values when executing a method of a. This problem does not arise in most class-based languages, because an object has a single physical identity. With delegation, the object has two identities."

That article about agentive nouns.

"The Lisp historical archive web site just got reorganized. I have made a quick check of the contents, and found out that Howard I. Cannon's original technical report about Flavors - A non-hierarchical approach to object-oriented programming was finally made available as part of that archive. The report was originally written in 1979, was circulated around Lispers, but was never ever published as an actual technical report, although it is cited as such in several later papers by other authors. It describes the original object-oriented extension to the MIT Lisp Machine, heavily influenced by Smalltalk, but with multiple inheritance and method combinations added (but no multiple dispatch yet, which got only introduced in CommonLoops, a direct predecessor of CLOS). Although unpublished and clearly in an unfinished state, this report itself influenced a lot of other subsequent experiments with object-oriented extensions to Lisp dialects."

"This dilemma is the basis for the oft-cited impedance mismatch between relational databases and object oriented languages. Tables are data structures, not classes. Objects are encapsulated behavior, not database rows... So applications built around ActiveRecord are applications built around data structures. And applications that are built around data structures are procedural—they are not object oriented. The opportunity we miss when we structure our applications around Active Record is the opportunity to use object oriented design."