Oo-Design

often used interchangeably but actually refer to two separate, and largely orthogonal, qualities Encapsulation behavior of an object can only be affected through its API reduces dependencies Information hiding Conceals how an object implements its functionality work at higher level abstraction Aliasing break encapsulation by sharing references to mutable objects increases dependencies accidental aliasing can couple unrelated parts of a system (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

Tell, don’t ask Model: Law of Demeter Objects make their decisions based only on the information they hold internally or that which came with the triggering message; they avoid navigating to other objects to make things happen. this style produces more flexible code because it’s easy to swap objects that play the same role. why? information hiding flexible code forces us to name the interactions between objects But Sometimes Ask...

Always design a thing by considering it in its next larger context—a chair in a room, a room in a house, a house in an environment, an environment in a city plan. -- Eliel Saarinen (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)

The big idea is “messaging” [...] The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. -- Alan Kay [Kay98] (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce) (origin: [Kay98])

Roles, Responsibilities, Collaborators An object is an implementation of one or more roles; a role is a set of relatedresponsibilities; and a responsibility is an obligation to perform a task or know information. A collaboration is an interaction of objects or roles (or both). (origin: Wirfs-Brock and McKean in [Wirfs-Brock03]) (src: Book_ Growing Object Oriented Software, Guided By Tests - Steve Freeman & Nat Pryce)