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:
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)
Multiple inheritance:
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:
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)
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:
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:
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
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.
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 ?
