Transcript Object Thinking

Object Thinking
The Philosophy of Development
formalism -vs- hermeneutics
From Philosophy to Culture
mentoring, metaphor & vocabulary
From Culture to Practice
object discovery & thinking
Formalism/Determinism
(software engineering)
uses traditional thinking
-vsHermeneutics/Postmodernism
(extreme programming)
uses object thinking
The Object Thinking Manifesto
Advocacy of behavioralism
Antagonistic towards formalism
Emphasis on analysis and conceptualization
Philosophy of extreme programming
Prefers the autonomous to the autocratic
The Object Thinking Manifesto
Better people write better code
- not better tools
“Let there be no doubt that object-oriented design
is fundamentally different than traditional
structured design approaches:
it requires different ways of thinking about
decomposition, and it produces software
architectures that are largely outside the realm
of the structured design culture.”
Grady Booch, 1991
“Let there be no doubt that object-oriented design
is fundamentally different than traditional
structured design approaches:
it requires different ways of thinking about
decomposition, and it produces software
architectures that are largely outside the realm
of the structured design culture.”
Grady Booch, 1991
Observing the Object Difference
operationX
operationY
Data
Structure
operationZ
Traditional thinking
Object thinking
Anthropomorphization
is the attribution of human characteristics
to inanimate objects, animals, forces of
nature, the unseen author of things, and
others.
“… if the diagram is an accurate depiction
of an object, what is the difference
between an object and a COBOL
program?”
“There is none. A COBOL program
encapsulates data and operations and
allows communication among programs.
Object development – using this model –
will have a tough time being anything more
than the creation of lots of tiny COBOL
programs.”
Object Depictions
Customer
Customer
id#
dob
gender
fname
lname
mi
honorific
generational
…
ID#
dob
gender
fname
…
Entity
getID#
setID#
getDOB#
setDOB#
…
UML
Object Depictions
Customer
ID self
describe self
indicate desires
make decisions
confirm information
Object (Class-Responsibility-Collaboration)
Encapsulation via Properties
public class Customer
{
public string Name
{
get { return _name; }
set
{
// validate here
_name = value;
}
}
private string _name;
}
• Known as information hiding
• Traditionally taught as a key
precept of OO
• But many XP advocates say
they should not be tested
… why?
• Why do objects keep trying
to change type?
• Is there a better way?
Self-Describing Objects
public class Customer
: Dictionary<Uri, Object>
{ }
• Provides a property bucket
• Looks alien to traditional
thinking
• Violates traditional
encapsulation principles
• How is validation carried
out?
Self-Evaluating Rules
Evaluate self-describing objects at runtime
Promote type re-use via separation of concerns
Embody data validation rules, business rules, or
any other constraint
Demo
Self-Describing Objects & Self-Evaluating Rules
So all my objects should be self-describing?
Having a hammer
does not make everything a nail
Non-Self-Describing Objects
Primitives
bool, int, float, enum, etc.
Some Standards
html elements, xpath predicates, industry, etc.
Self-Describing Objects tend to be actors
Issues
Currently no standard supporting framework
I am considering a CodePlex or SourceForge project
Limited knowledge, few publications, no examples
Just try googling for the key terms…
Steep learning curve
Hard to ‘unlearn’ traditional thinking
Few practitioners or evangelists
Links
http://thoughtpad.net/alan-dean/object-thinking
Email
[email protected]
© MMVII