Object Thinking : David West

Book based on assumptions:

• Agility/XP essential for profession/industry to improve
• XP offers way to create better developers
• Can't do XP without understanding object thinking
• Won't appreciate the benefits of XP if don't fully understand 'object thinking'

Simplicity:

• OT based on problem domain, not potential program
• OT leads to smallest number of things (classes) possible
• Objects doing the least amount of work, in the most direct and simplest way
• Focus on coordination of autonomous objects - not mgmt of unruly modules and passive data structures

Simple design:

• Fewest no. of classes
• Fewest number of methods per class
• Simplest coding of methods
• Avoidance of control, centralization & mgmt classes
• Simple scripts to simulate simple stories

Refactoring:

• Allow 'lazy' objects to give work to other objects

The true differences between programming languages are those that reflect philosophical ideals and values

If you think about design using a language - your design will be enhanced or severely restricted by that language

Object culture:

• Collaboration rather than mgmt
• Coordination and cooperation, rather than control
• Rapid prototyping instead of structured development

Prerequisites to OT:

• Everything is an object
• Simulation of problem drives object discovery and definition
• Objects must be composable
• Distributed coordination and communication must replace hierarchical centralized control as an organizational paradigm

Programs may be thought of as data and functions - but the real world isn't

Assuming data and functions:

• Programs are more complicated than need be
• Complex code is difficult to understand and test
• Complex code is brittle and difficult to modify when requirements change
• Resultant code lacks composability - not reusable outside original context

Object principals - software principles:

• Solve complex problems by solving a series of intermediate, simpler problems
• Appreciate human cognitive limitations
• Correctness is unaffected by movement between equivalent contexts
• Correctness is unaffected by replacement with equivalent components
• Modular design
• Portable design
• Provides compositional flexibility
• Appropriate use of abstractions
• Limited set of conceptual forms

Brooks' 4 essential difficulties of software development

• Complexity
• Conformity (to the world, rather than the other way round)
• Changeability (to the world, which changes frequently)
• Invisibility

Metaphors:

• Help discovery
• Help make design decisions
• Provide handy ways to remember principles of object thinking
• Help avoid non object thinking

It is convenient to build something large from smaller (but not the smallest possible) components

The complexity of object-oriented programs is in the scripting, not the objects themselves

Hierarchical and centralized control is anathema in the object paradigm.

Ants, not autocrats: - do your thing and react to messages from those around you.

Behaviour is the abstraction to use to differentiate between objects and is the criteria to base taxonomy on.

Creating taxonomies based on internal structure leads to numerous problems

The programming language used does not mean that doing object programming

Object vocabulary is first and foremost a technique to help developers avoid the mistake of thinking about solutions using old mental habits

Essential terms:

• Object
• Responsibility (task)
• Message
• Protocol

Computations must be by an object on itself: (e.g. number adds another to itself. rather than an object and two other number objects together)

• Helps enforce simplicity

Multiple inheritance:

• Is unnecessary
• There are alternative
• Adds needless complication

Methods and model must:

• Support natural decomposition
• Recognize 2 complementary processes: domain modeling; application assembly
• Aid discovery and evaluation
• Enable measuring progress and 'goodness'

Formal methods do have their value

Blending methods and approaches is hard

Using ideas from both approaches is equally difficult

Need criteria to evaluate:

• Self
• Progress
• Products

Need to understand the domain - how computers work is not part of the domain

Starting a journey with one step in the wrong direction can have an enormous impact on the end result

Mistakes at the beginning of a process are more costly:

• Have less knowledge, so more likely to make mistakes
• More tempted to think about what do know (the computer) rather than the domain

Never: think about what the code will look like and then create objects to support that code.

Set aside your own culture when attempting to understand users and user domains

To understand users: (their domain and their tasks)

• Go and spend time with them
• Observe them
• Talk to them

Can't define everything up front - do one thing (story) at a time

Object definition:

• Most critical aspect of discovery
• Define in terms of actual or intended use
• Define within domain, not just application space
• Not the same as object specification
• Specification will involve making design decisions

OT suggests you should generalize responsibilities so that they can be used in any context

Let objects assume responsibility for tasks that are wholly or completely delegated to other objects in cases in which responsibility reflects natural communication patterns in the domain.

Delegate responsibilities to get a better distribution and increase reusability.

Delegation can lead to the temptation of management. - If you delegate, delegate:

• Don't try and control
• Don't guess what the result will be
• Don't do own error checking or evaluation

Responsibilities should be distributed among the community of objects in a balanced manner

Avoid responsibilities that are characteristic specific, that focus on providing a potential user with the value of a single characteristic of the object.

Beware the dangers of GUI-in design!

The two kinds of relationship of interest between objects:

• is a kind of
• collaborates with

Single line of descent based only on the behavior of the object

Collaborations are almost always hard coded - due to complexity of relationship between objects

OT: data is information or knowledge that objects need to complete a task

Traditional data modeling: all the data that a system must remember about objects

Model: - comprises objects engaged in the objectives of the application

View: - hierarchically organized collection of objects

Coordinator: - tasks involved in sending messages to other objects, and notifying subscribed objects of a state change

Objects are not and should not be aware of their clients, even when their clients are not other software objects

Scripts as first class objects:

• Ordered collection of messages

Events as cues to object interaction

Constraints and rules are objects themselves

Rules should not be complex (coz they're objects)

Objects will often have a collection of 'self evaluating rules'

Rules:

• Evaluate
• Error handling/recovery

XP maturity levels:

• Out of the box
• Adaptation
• Transcendence

Objects are not something you do - objects are something you think

There are circumstances in which it is difficult, if not impossible to apply object thinking

• e.g. RDBMS, GUI

Database philosophy is almost totally inconsistent with the philosophy behind object thinking

Need to remember the functional advantage of databases as well as their persistence services

XP created users who don’t want large monolithic software but a collection of small, targeted applications which do specific tasks.

• In contrast to 80/20 law

Object cube:

Side 1: Responsibilities

Side 2: Description and stereotype

Side 4: Knowledge required

Side 5: Message protocol (methods)

Side 3: Contracts (public or private methods)

Side 6: Events

objectionary ?