2025 Public Training Schedule
January 14 – 17, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- December 16, 2015
- Bits and Pieces
I have had the good fortune of working on two dolphin research projects in my life so far. Dolphins are highly intelligent and their brains are, on average, larger than ours. I like to say that I have the privilege of working with the two most intelligent species on the planet, dolphins and developers.
When studying animal behavior, we have to be very careful not to project our own interpretations on our subjects. This is called anthropomorphization, which is seeing others in terms of ourselves. In some sense, it can’t be helped because the only way we can understand anything is in terms of ourselves. But in academics, anthropomorphization is considered a bad thing because it leads to projections and false understandings.
In software, however, anthropomorphization is a good thing! It is impossible for us to visualize the flow of electrons through circuitry millions of times a second and so instead we visualize the problem we’re solving in software to help us understand the code we’re writing.
I think of my programs as a little world and the objects as people in that world. Like people, objects have purpose in life. They have goals and aspirations, as well as challenges. Like any good parent, I want to see my objects reach fulfillment by giving them the capabilities to achieve their purpose.
This has an impact on how I treat my objects. For example, I try to avoid getters and setters when I can because I’d rather an object change its internal state as the result of doing something useful. If I wanted your driver’s license number I wouldn’t put my hand in your pocket, remove your wallet, and take your driver’s license. This would be inappropriate—and could get me into trouble. Shouldn’t the same be true for the objects we use?
If I want an object’s ID, rather than take it I should *request* it. This is more than just good object citizenship, it protects me as well because perhaps the way the ID is stored will change and if I was intimately involved in the implementation for getting the ID, when it changes it would break my code. But if one of the responsibilities of the object is to return its ID upon request and it changes the way the ID is stored, as long as the interface for retrieving the ID doesn’t change then none of its dependencies will need to change.
Previous Post: « How Open-Closed are you?
Next Post: Just Telling Teams to Self-Organize Doesn’t Work »