Free Download Object Thinking By David West Pdf Free ((TOP))
Penelope Belkowski
According to West, OOP can reap in order-of-magnitude improvements over traditional structured design methods. However, just jotting your code into classes doesn't make it "real OOP". It takes a very special mindset - "object thinking" - to utilize OOP effectively. We are given guidance as to how to do object thinking. These come in the form of metaphors. One of them being the "object as a person", which amongst other things state:
I'm being told to do "object thinking" but there are very few concrete techniques (other than CRC cards) to show for. I'm brought back to ancient Greece, to Socrates and even advice from a Taoist butcher about carving meat from a bone, only in the places where there are no meat. Droning on and on. It tires me and it annoys me. Because I really am in agreement with much of what is being said, but the 330 odd pages are strenuous on the mind. To focus. To remember and to distil what is actually being said. Its unavoidable for the mind to drift and circle in on the word "snake oil" - an expression that originally referred to fraudulent health products or unproven medicine, but which today has come to refer to any product with questionable or unverifiable quality or benefit. When there is so little concrete. Not a single code example, and when the argumentation so vague, it is hard not to think of snake oil.
The LEGO Block metaphor; (sidebar: how many objects); object as person metaphor; software as theater, programmers as directors; ants, not autocrats; inheritance and responsibility; and thinking like an object.
@Ben,
It really comes down to a sound design. As I'm sure you're aware, a huge part of the development process is actually consumed, not by the original development, but by the maintenance of that code and the expansion of it. This is why it is really critical to spend time thinking about the delegation of work and outlining of interactions between objects.
... and, if you didn't design it well, from what I hear, you get all of the *overhead* off OOP and none of the benefits. I think for me, the biggest hurdle is just thinking about multiple objects coordinate. This conversation about the TaskList / TaskItem has been hugely beneficial. It's just a small, simple context; but it sheds light on how different my "procedural" mind may really see things.
The author then extends this discussion to define and differentiate computer thinking and object thinking. Computer thinking is limiting your design of the software to how you think the computer is going to perform. I found this way of thinking analogous to premature optimization, and we all know what Donald Knuth has says about that; "Premature optimization is the root of all evil (or at least most of it) in programming."
Object thinkers strive to understand and model the domain fully, and letting their designs reflect the real world without respect to implementation. This may seem similar to use-cases, but I think there are important differences. Use-cases are a way to capture requirements, while object thinkers attempt to capture the behavior and responsibilities. Here is what the author has to say about thinking about object design:
In OBJECT THINKING, esteemed object technologist David West contends that the mindset makes the programmer--not the tools and techniques. Delving into the history, philosophy, and even politics of object-oriented programming, West reveals how the best programmers rely on analysis and conceptualization--on thinking--rather than formal process and methods. Both provocative and pragmatic, this book gives form to what's primarily been an oral tradition among the field's revolutionary thinkers--and it illustrates specific object-behavior practices that you can adopt for true object design and superior results.
The book describes ways to counter this method using a different style of thinking called "object thinking". When I know more about it, I'll share it with you. For now, I just wanted to note that this "computer thinking" we do, leads to many issues that make the overall design of our application worse. I described one situation in a previous article about read models, where I realized that we often try to answer many different questions by querying one and the same model (which is also the write model). By splitting write from read, we end up with a more flexible design.
In projects that don't apply dependency injection and context passing (everywhere), you will find that there are issues with the number of call sites for certain methods. In particular: ServiceLocator::get() or things like Context::getRequest(). If we apply "computer think", we use these static methods to fetch all the things we need, instead of receiving them as constructor or method arguments. If we use "object thinking", we get rid of these static calls, and so we drastically reduce the number of call sites for them. This in turn allows us to prepare the project for the future. Because today's ServiceLocator is yesterday's façade, last week's Zend_Registry, and last month's sfContext. Instead of using whatever convenient utility your favorite framework uses for fetching things, just make sure you always inject your dependencies and pass along your context. If you always do this, you can easily migrate your project once the framework you use isn't maintained anymore (or when you just want to try out something better).
Domain-Driven Design (DDD) helped me solve software architecture problems. I really like the methods and patterns from there. Now David West tells me that the fundamental advantage I saw in DDD is actually fundamental object thinking.
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.
a) The presence of a problem. -- A problem can be most generally described asthe checking or inhibition of some more or less habitual form of conduct, way of thinking,or feeling. We meet an obstacle in overt action, or an exception to an accepted rule ormanner of thought, or some object that calls out opposing emotions.
dd2b598166