object thinking. the philosophy of development formalism -vs- hermeneutics from philosophy to...
TRANSCRIPT
Object Thinking
The Philosophy of Developmentformalism -vs- hermeneutics
From Philosophy to Culturementoring, metaphor &
vocabulary
From Culture to Practiceobject discovery & thinking
Formalism/Determinism(software engineering)
uses traditional thinking
-vs-
Hermeneutics/Postmodernism(extreme programming)
uses object thinking
The Object Thinking Manifesto
Advocacy of behavioralismAntagonistic 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
Traditional thinking Object thinking
Data Structure
operationX
operationY
operationZ
Anthropomorphizationis 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
Entity UML
Customer
ID#dobgenderfname…
getID#setID#getDOB#setDOB#…
Customer
id#dobgenderfnamelnamemihonorificgenerational…
Object Depictions
Object (Class-Responsibility-Collaboration)
Customer
ID selfdescribe selfindicate desiresmake decisionsconfirm information
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 Objectspublic 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 hammerdoes not make everything a nail
Non-Self-Describing ObjectsPrimitives
bool, int, float, enum, etc.
Some Standardshtml elements, xpath predicates, industry,
etc.
Self-Describing Objects tend to be actors
Issues
Currently no standard supporting frameworkI am considering a CodePlex or SourceForge
project
Limited knowledge, few publications, no examples
Just try googling for the key terms…
Steep learning curveHard to ‘unlearn’ traditional thinking
Few practitioners or evangelists
