What do you think?
Rate this book
Object Thinking
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.
Gain an in-depth understanding of:
Prerequisites and principles of object thinking. Object knowledge implicit in eXtreme Programming (XP) and Agile software development. Object conceptualization and modeling. Metaphors, vocabulary, and design for object development.Learn viable techniques for:
Decomposing complex domains in terms of objects. Identifying object relationships, interactions, and constraints. Relating object behavior to internal structure and implementation design. Incorporating object thinking into XP and Agile practice.574 pages, Kindle Edition
First published February 1, 2004
72 people are currently reading
803 people want to read
About the author
David West
3 books8 followersLibrarian Note: There is more than one author in the Goodreads database with this name.
David West, °1948
David West, °1948
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 27 of 27 reviews
September 27, 2019
If you are serious about object-oriented programming, you need to read this book. I was writing Java and C++ code for more than 15 years and I hated what I was producing. This book flipped my mind. I didn't become a better coder after reading it since there is no code inside. I became a much better designer. I even wrote a few books of my own after reading the work of David West.
I highly recommend you spend some time to think about what you will find in this book. Don't take it as a yet another book about programming. This book must become a turning point in your professional life. Otherwise, just throw it away, you are not yet ready for it.
I highly recommend you spend some time to think about what you will find in this book. Don't take it as a yet another book about programming. This book must become a turning point in your professional life. Otherwise, just throw it away, you are not yet ready for it.
June 6, 2012
There were two things I really enjoyed about this book. The first was the discussion of different schools of thought in philosophy and how those ideas appear in software. The second was the history sidebars that introduced different computer scientists and explained their contributions to the field.
The basic thrust of the book was simply that you should write your applications as a a bunch of objects whose intercommunication results in the emergent behavior of your application. And further, that your models should attempt to model the real world objects and concepts of your domain.
That's great and all, but the book provides no examples. None. And it makes a huge number of assertions about how much better this approach is and how everything else is inferior, but with nothing to back those statements up. Nothing.
So in the end, I'm left feeling like there are probably some good ideas in there, but I'm totally unconvinced that the author has ever written a real business application. And further, I think he might be just a grumpy old dude who's sad that Small Talk lost out to more mature and practical languages like C++ and Java.
The basic thrust of the book was simply that you should write your applications as a a bunch of objects whose intercommunication results in the emergent behavior of your application. And further, that your models should attempt to model the real world objects and concepts of your domain.
That's great and all, but the book provides no examples. None. And it makes a huge number of assertions about how much better this approach is and how everything else is inferior, but with nothing to back those statements up. Nothing.
So in the end, I'm left feeling like there are probably some good ideas in there, but I'm totally unconvinced that the author has ever written a real business application. And further, I think he might be just a grumpy old dude who's sad that Small Talk lost out to more mature and practical languages like C++ and Java.
March 12, 2018
این کتاب بهترین کتاب تخصصی هست که من خوندم. واقعا دید من رو به دنیای توسعه نرم‌افزار و شی‌گرایی تغییر داد. اصلا یک سبک نگاه دیگه‌ای رو پیشنهاد میکنه که با توجه به تجربیاتم دید ثمربخش‌تر و درست‌تریه که جاش در بین شاغلین این حوزه خالیه. قسمت عمده‌ی این کتاب فلسفه و تاریخچه‌ی شی‌گرایی رو توضیح میده. الان که تلقی رایج از شی‌گرایی ارتباط زیادی با اصول و دلایل ابتداییش نداره خوندن این کتاب میتونه خیلی مفید باشه. به قول نویسنده‌اش این کتاب ده سال دیر نوشته شده. چیز خاصی درباره مفاهیم نابی که توش گفته شده نمیگم که با خوندنش غافلگیر بشید. این کتاب رو باید یکی دوبار دیگه به نیت حفظ کردن بخونم.
از این لینک باهاش آشنا شدم:
http://www.yegor256.com/2015/04/22/fa...
اگه خواستید این ویدیوی مصاحبه با دیوید وست رو ببینید:
https://www.youtube.com/watch?v=s-hdZ...
از این لینک باهاش آشنا شدم:
http://www.yegor256.com/2015/04/22/fa...
اگه خواستید این ویدیوی مصاحبه با دیوید وست رو ببینید:
https://www.youtube.com/watch?v=s-hdZ...
May 10, 2017
# Object Thinking
This is a nice book that presents several interesting and non-obvious ideas about software development philosophy. For instance, the connection with hermeneutics and postmodernism, although not necessarily new, is not usually considered. So, definitely props for looking into the non-formalist direction for inspiration regarding SWE.
But I have some objections to the book and I believe them to be pretty grave ones.
First of all, regarding the aforementioned literary approach to the software development—programming is not literature. While in the terms of creating it this well may be true that the issue of communication is of the utmost importance, and we should concentrate on it instead of formal methods. It is not literature in the sense that we actually do have clear objective metrics to measure the success of a software development project. The cost, the amount of errors discovered post-release, length of development—these are completely measurable and are very important. We do not create software for the sake of art (while we may have to approach the process itself as an art project and not an engineering project, sure, this what the book tries to argue, and I have no real objections to the idea), we create it for purely pragmatic purposes, and hence it can be measured to be a success or a failure objectively. The fact that it can be supplied with explicit numerical metrics makes a perfect case for randomised control trials. We can check whether the formalist approach (even differentiating methods) is worse or better than the literary approach, with experiments. And there is no room for interpretation of such experiments because they fall within the scientific method. The difficult part is that these kinds of experiments to be rigorous would be extremely difficult to perform and incredibly expensive. My point is not that we must abandon the literary approach in favour of the formalist one but only that we do not have proof for either while the proof is actually possible to find (which seems not to be the case for literature and some other language related / semiotic problems in general).
Another critique I have of the text is that it mostly builds its argument by the way of, one, appeal to authority, and, two, by sheer repetition of the claim that the OOP paradigm is the best. It repeats again and again, without any backing up, that this is the way to do stuff, that it will make your software better, that it will make developers better people, that it will make software easier to change, reason about, whatever have you. And then it repeats it again. And then just one more time. And one more. This is supposed to convince me, I guess. Well, it doesn’t. Actually, this doing just the opposite. It rings so many bells, I am now more sceptical of the idea than before reading this book.
Maybe I am too deeply set in my ways but when the book pushes unityped approach I have a kind of a knee-jerk reaction and want to stop reading it immediately. When it continues with the idea of putting all data rich objects in unityped dictionaries (e.g. Map in Java terms), well at this point it becomes really difficult to try to value its advices.
And the ultimate thing, that completely ruined the message for me is that this book, I kid you not, has within it a gem of a very poorly written fan-fiction. There is this “example” of how the development of a project can go within the OOP/XP modality which is in actuality just a story (not an XP story, but a literary one) that tells us about the magical world of OOP/XP in a weird pastoral tone, full of recounts of how everything is good in the OOP kingdom of love. The XP developers in the story program like happy little elves, they know that through the refactoring process they will reach the blissful result of better maintainable software which makes everything in a way it is supposed to, they always nicely refactor their XP stories, and then go smiling to their computers and communicate with them in a rather hermeneutic fashion (they do not even create artefacts of documentation, because the intent of the developer is not transferrable through such means). And, oh my, oh my, the software does well in their hands. It’s now so easy to maintain, so easy to extend and they all hold hands and dance their happy little dance. Moreover, the guys who worked with objects more than the others create something that is even better, and everyone immediately sees that. And this is all BS. Really, it’s nothing more than a fantasy disguised as an “example” text, that has a purpose of staying in my mind as a real historical account of success of OOP/XP. This is a subversion (not the VCS).
Some quotes from these “Forward Thinking” inserts:
> “Developers separate in pairs, select a story, and begin development. Everyone is confident that we can begin development with such sparse definition of requirements and in the absence of any kind of formal modelling. \[…\] No one feels the need to create syntactically precise models, but it is surprising how much gets jotted down and drawn in the process of discussing and writing code. Interestingly enough, those that have been doing objects longer tend to make fewer notes as they proceed \[…\]” (p. 50)
> “One Friday afternoon the team is getting ready to leave, when Sally looks around the room as if seeing it for the first time. ‘You know,’ she says almost to herself, ‘this place is a pretty good visual metaphor.’ (p. 167)
> “Everyone here has confidence—we all have internalised a lot of knowledge \[…\] about object thinking and XP practices.” \[…\] “Somehow we have learned a new way to think about problems, a new vocabulary to think with, and a new way to perform—to work.” “And joy and serenity along with the confidence.” “Hah, sounds like we are all enlightened somehow”. (p. 168)
There is one more or less worked out example with the mortgage application, but it still left me disappointed. Not enough detail, too many weasel words.
All in all, I would recommend this book, there seem to be some deep ideas lurking inside (many of which I believe I have not uncovered, probably due to my lack of mental capacities), but please turn on your sceptic to at least 8 before reading. And always think, “is this claim substantiated by evidence”? If not, you can accept it still, do your own experiments (even of one), but be aware, in the very much postmodern tradition, that this is an act of faith.
Actually all these books about methodology and approaches to software are somewhat tiring. What a software engineer needs to see to actually become convinced or at least to start to think in the direction the proponent of an ideology wants him to? Yet another book, full of words, essays and promises? No, I think what we want now is actually just code. Give us the code, give us big, complex projects open sourced on Github or whatever which we can study, from which we can learn, and decide for ourselves the merits of the approach you want us to subscribe to. It’s hard to write a book, so maybe don’t. Write public code instead, that would be awesome, not lamentations and fan-fiction.
This is a nice book that presents several interesting and non-obvious ideas about software development philosophy. For instance, the connection with hermeneutics and postmodernism, although not necessarily new, is not usually considered. So, definitely props for looking into the non-formalist direction for inspiration regarding SWE.
But I have some objections to the book and I believe them to be pretty grave ones.
First of all, regarding the aforementioned literary approach to the software development—programming is not literature. While in the terms of creating it this well may be true that the issue of communication is of the utmost importance, and we should concentrate on it instead of formal methods. It is not literature in the sense that we actually do have clear objective metrics to measure the success of a software development project. The cost, the amount of errors discovered post-release, length of development—these are completely measurable and are very important. We do not create software for the sake of art (while we may have to approach the process itself as an art project and not an engineering project, sure, this what the book tries to argue, and I have no real objections to the idea), we create it for purely pragmatic purposes, and hence it can be measured to be a success or a failure objectively. The fact that it can be supplied with explicit numerical metrics makes a perfect case for randomised control trials. We can check whether the formalist approach (even differentiating methods) is worse or better than the literary approach, with experiments. And there is no room for interpretation of such experiments because they fall within the scientific method. The difficult part is that these kinds of experiments to be rigorous would be extremely difficult to perform and incredibly expensive. My point is not that we must abandon the literary approach in favour of the formalist one but only that we do not have proof for either while the proof is actually possible to find (which seems not to be the case for literature and some other language related / semiotic problems in general).
Another critique I have of the text is that it mostly builds its argument by the way of, one, appeal to authority, and, two, by sheer repetition of the claim that the OOP paradigm is the best. It repeats again and again, without any backing up, that this is the way to do stuff, that it will make your software better, that it will make developers better people, that it will make software easier to change, reason about, whatever have you. And then it repeats it again. And then just one more time. And one more. This is supposed to convince me, I guess. Well, it doesn’t. Actually, this doing just the opposite. It rings so many bells, I am now more sceptical of the idea than before reading this book.
Maybe I am too deeply set in my ways but when the book pushes unityped approach I have a kind of a knee-jerk reaction and want to stop reading it immediately. When it continues with the idea of putting all data rich objects in unityped dictionaries (e.g. Map in Java terms), well at this point it becomes really difficult to try to value its advices.
And the ultimate thing, that completely ruined the message for me is that this book, I kid you not, has within it a gem of a very poorly written fan-fiction. There is this “example” of how the development of a project can go within the OOP/XP modality which is in actuality just a story (not an XP story, but a literary one) that tells us about the magical world of OOP/XP in a weird pastoral tone, full of recounts of how everything is good in the OOP kingdom of love. The XP developers in the story program like happy little elves, they know that through the refactoring process they will reach the blissful result of better maintainable software which makes everything in a way it is supposed to, they always nicely refactor their XP stories, and then go smiling to their computers and communicate with them in a rather hermeneutic fashion (they do not even create artefacts of documentation, because the intent of the developer is not transferrable through such means). And, oh my, oh my, the software does well in their hands. It’s now so easy to maintain, so easy to extend and they all hold hands and dance their happy little dance. Moreover, the guys who worked with objects more than the others create something that is even better, and everyone immediately sees that. And this is all BS. Really, it’s nothing more than a fantasy disguised as an “example” text, that has a purpose of staying in my mind as a real historical account of success of OOP/XP. This is a subversion (not the VCS).
Some quotes from these “Forward Thinking” inserts:
> “Developers separate in pairs, select a story, and begin development. Everyone is confident that we can begin development with such sparse definition of requirements and in the absence of any kind of formal modelling. \[…\] No one feels the need to create syntactically precise models, but it is surprising how much gets jotted down and drawn in the process of discussing and writing code. Interestingly enough, those that have been doing objects longer tend to make fewer notes as they proceed \[…\]” (p. 50)
> “One Friday afternoon the team is getting ready to leave, when Sally looks around the room as if seeing it for the first time. ‘You know,’ she says almost to herself, ‘this place is a pretty good visual metaphor.’ (p. 167)
> “Everyone here has confidence—we all have internalised a lot of knowledge \[…\] about object thinking and XP practices.” \[…\] “Somehow we have learned a new way to think about problems, a new vocabulary to think with, and a new way to perform—to work.” “And joy and serenity along with the confidence.” “Hah, sounds like we are all enlightened somehow”. (p. 168)
There is one more or less worked out example with the mortgage application, but it still left me disappointed. Not enough detail, too many weasel words.
All in all, I would recommend this book, there seem to be some deep ideas lurking inside (many of which I believe I have not uncovered, probably due to my lack of mental capacities), but please turn on your sceptic to at least 8 before reading. And always think, “is this claim substantiated by evidence”? If not, you can accept it still, do your own experiments (even of one), but be aware, in the very much postmodern tradition, that this is an act of faith.
Actually all these books about methodology and approaches to software are somewhat tiring. What a software engineer needs to see to actually become convinced or at least to start to think in the direction the proponent of an ideology wants him to? Yet another book, full of words, essays and promises? No, I think what we want now is actually just code. Give us the code, give us big, complex projects open sourced on Github or whatever which we can study, from which we can learn, and decide for ourselves the merits of the approach you want us to subscribe to. It’s hard to write a book, so maybe don’t. Write public code instead, that would be awesome, not lamentations and fan-fiction.
November 2, 2016
If you are a programmer this book is a must read! Why? It reminds you why programming isn't just writing a code in a style you have accepted and which emerged from yourself. It is a whole world consisting of object interactions, just like the world we live in. It reminds you of good principles, communication ideas and methodologies to find the object interactions within a given domain. It lays down the principles of XP and how to really be agile in software development. It is a great read, really!
November 22, 2010
Phenominal. On my second read through. This time without having to have a dictionary in hand. The concepts put forth in this book are vital for all Businesss App developer to understand. It will be set as required reading for my dev group.
March 17, 2019
Interesante, aunque con sentimientos encontrados. Bastante abstracto por momentos, difícil de seguir por otros. A pesar sus deficiencias y argumentación por momentos débil, es el único libro que conozco que habla en profundidad sobre cómo debe pensar alguien que desarrolla software de gran escala. Cómo pensar en objetos es el primer paso, necesario, fundamental, para poder desarrollar un sistema que sea mantenible. Por ese motivo encuentro este libro de gran valor. Posiblemente una segunda lectura venga bien.
November 7, 2020
This book really got me thinking about how I look at the software that I write and hopefully I can use the information to improve my code.
Read
May 12, 2024Best served with The Pain of OOP by Yegor
https://www.youtube.com/watch?v=aLaDD...
https://www.youtube.com/watch?v=aLaDD...
Read
April 15, 2016Fundamentally worthwhile.
Dated, but not horribly, and the historical perspective on UI code allowed me to construct an interesting parallax view of the ways I approach it today as a web developer.
Occasionally the ideas are crotchety, weird, or both: his dismissal of type systems is the dismissal one makes when one assumes that "strong typing" is synonymous with Java, and as a long-time Ruby programmer I call thorough bullshit on his notion that type errors are rare in professional, test-backed code. His love of vast seas of objects all emitting events willy-nilly often reads like he's placing pet theories above practical debuggability concerns. And, while his hate-on for relational databases is well-reasoned (enough so that I now understand why some developers I otherwise respect have a bizarre affection for Mongo) his dismissal of data modeling as a useful process goes a bit far.
Ultimately, though, the biggest flaw in the book is the one I always see in "classical" XP writing. Many of the practices and pronouncements of Agile bear a striking resemblance to old-school feminist ideas, often *particularly* the ideas of intersectional feminists and/or womanists. Very little Agile writing acknowledges this convergent evolution, or -- heaven forfend -- reads feminist work, incorporates it, cites those sources. This issue is *particularly* glaring in _Object Thinking_ as West devotes so much time to the philosophical underpinnings of object-oriented design, and to notions of object autonomy, embracing bottom-up or non-hierarchical product models, education as a process of enculturation rather than knowledge transfer, etc. (The bit about effective software development being a culturally transmitted practice was particularly egregious; West did not seem to realize that that passage also read as a celebration of "culture fit" homogenity in engineering.)
Ironically I think that if West had internalized Black feminist ideas about how people's praxis must be analyzed in the context of their lived experience.... the things he said about type systems and relational databases might have held together better? But that's me being snotty.
Dated, but not horribly, and the historical perspective on UI code allowed me to construct an interesting parallax view of the ways I approach it today as a web developer.
Occasionally the ideas are crotchety, weird, or both: his dismissal of type systems is the dismissal one makes when one assumes that "strong typing" is synonymous with Java, and as a long-time Ruby programmer I call thorough bullshit on his notion that type errors are rare in professional, test-backed code. His love of vast seas of objects all emitting events willy-nilly often reads like he's placing pet theories above practical debuggability concerns. And, while his hate-on for relational databases is well-reasoned (enough so that I now understand why some developers I otherwise respect have a bizarre affection for Mongo) his dismissal of data modeling as a useful process goes a bit far.
Ultimately, though, the biggest flaw in the book is the one I always see in "classical" XP writing. Many of the practices and pronouncements of Agile bear a striking resemblance to old-school feminist ideas, often *particularly* the ideas of intersectional feminists and/or womanists. Very little Agile writing acknowledges this convergent evolution, or -- heaven forfend -- reads feminist work, incorporates it, cites those sources. This issue is *particularly* glaring in _Object Thinking_ as West devotes so much time to the philosophical underpinnings of object-oriented design, and to notions of object autonomy, embracing bottom-up or non-hierarchical product models, education as a process of enculturation rather than knowledge transfer, etc. (The bit about effective software development being a culturally transmitted practice was particularly egregious; West did not seem to realize that that passage also read as a celebration of "culture fit" homogenity in engineering.)
Ironically I think that if West had internalized Black feminist ideas about how people's praxis must be analyzed in the context of their lived experience.... the things he said about type systems and relational databases might have held together better? But that's me being snotty.
January 10, 2019
Mixed feelings. Could have been better (or maybe I need to read it again)
I liked the background behind object philosophy and some ideas on how to identify and design objects. It changed my way of thinking slightly, which is good. I also liked the ideas of self-evaluating rules and several common object designs (called frameworks here).
What I did not like was that the material is presented in a matter-of-fact style (as if everything was undoubtedly true), without discussing (or even mentioning) alternative ideas. Also, the book would have been tremendously more valuable if it had at least some implementation examples (especially so in the self-evaluating rules chapter, where the author says something along the lines of "We have implemented such rules with my colleague, yet we never published the paper. But trust me, this is possible.").
I also got the feeling that David West was trying to relate his ideas to XP (agile) - maybe as a marketing move - as if object thinking was not sufficient to stand on its own.
As the book is quite theoretical, I think I'll have to read (parts of) it again.
I liked the background behind object philosophy and some ideas on how to identify and design objects. It changed my way of thinking slightly, which is good. I also liked the ideas of self-evaluating rules and several common object designs (called frameworks here).
What I did not like was that the material is presented in a matter-of-fact style (as if everything was undoubtedly true), without discussing (or even mentioning) alternative ideas. Also, the book would have been tremendously more valuable if it had at least some implementation examples (especially so in the self-evaluating rules chapter, where the author says something along the lines of "We have implemented such rules with my colleague, yet we never published the paper. But trust me, this is possible.").
I also got the feeling that David West was trying to relate his ideas to XP (agile) - maybe as a marketing move - as if object thinking was not sufficient to stand on its own.
As the book is quite theoretical, I think I'll have to read (parts of) it again.
April 8, 2020
Great read!
This is not a programming textbook and it won't teach you how write better code. It will present you an object-thinking approach to problems that are solved with software development. It doesn't claim that this is the only approach to find solutions to such problems, but it will broaden your understanding of OOP and software design.
The book starts with an interesting discussion about formalist and hermeutic philosophies, their implication in the software development field and some historical context. The author arrives at the conclusion, that the formalist methodology impairs the software design process, which is a human-centered, creative and domain-driven activity. From then on, this conclusion is used to build an understanding of objects, which does not limit them to a mere combination of data and methods.
Thankfully, the author has provided a rich list of references, both to philosophical and to software design books, so every reader can engage in whatever topic interests him most.
This is not a programming textbook and it won't teach you how write better code. It will present you an object-thinking approach to problems that are solved with software development. It doesn't claim that this is the only approach to find solutions to such problems, but it will broaden your understanding of OOP and software design.
The book starts with an interesting discussion about formalist and hermeutic philosophies, their implication in the software development field and some historical context. The author arrives at the conclusion, that the formalist methodology impairs the software design process, which is a human-centered, creative and domain-driven activity. From then on, this conclusion is used to build an understanding of objects, which does not limit them to a mere combination of data and methods.
Thankfully, the author has provided a rich list of references, both to philosophical and to software design books, so every reader can engage in whatever topic interests him most.
February 2, 2011
I'm finding this to be a tough book. There are some very necessary ideas in this book, but they are not "facts and equations" as much as perspectives and paradigms. It's the kind of thing you keep reading and considering until you "get it". You may read it and find you're already on board, or need to hit it 5 times.
To give you an example of what I mean - most Java, C++, and C# programmers probably consider themselves Object Oriented developers. In fact, most are "Data Object"-oriented developers, Class oriented developers, or Module oriented developers. These aren't terms used in the book but, if you feel there's a distinction to be made between these and Object oriented approaches, then you're probably ready for the level of thinking of this book.
To give you an example of what I mean - most Java, C++, and C# programmers probably consider themselves Object Oriented developers. In fact, most are "Data Object"-oriented developers, Class oriented developers, or Module oriented developers. These aren't terms used in the book but, if you feel there's a distinction to be made between these and Object oriented approaches, then you're probably ready for the level of thinking of this book.
September 19, 2023
Наконец дошли руки до очередного долгожителя моего ридлиста.
Довольно трудно формализовать такую тему как развитие определенного образа мышления, поэтому Уэст решил начать с истории ООП, а потом перейти основным понятиям и примерам.
Это в большей степени не техническая, а философская книга: в первых главах на читателя вываливаются горы всевозможных работ - начиная от Платона и его идей, и заканчивая исследованиями интеллекта и сложных систем. Перед читателем предстает история противостояния формального (традиционного, рационального) и герменевтического (эвристического, свойственного ООП) подходов к разработке ПО. Объектно-ориентированный подход еще с момента своего появления в 60х годах подвергался критике со стороны тех, кто видел в программировании математическую точность и строгость. Развитие неформального ОО-подхода в итоге вылилось в появление agile и экстремального программирования, и автор особенно активно топит за последнее.
Как обычно бывает в таких книгах, основные идеи можно сформулировать достаточно кратко, а большая часть книги сообщает контекст, примеры, метафоры, терминологию и т.п. Объект - самостоятельная единица, симулирующая что-то из реальности и предоставляющая свои сервисы. По Уэсту, формулировать интерфейс объекта в виде предоставляемых сервисов - принципиальный момент. Например, "содержать в себе информацию о клиенте" - это не сервис. А вот "предоставить описание" клиента - уже сервис. В целом, сервисы нужно формулировать в активном залоге. Все на свете является объектом, предоставляющим какие-то сервисы (даже символ, который предоставляет сервисы в своем узком домене, вроде "дай свое байтовое представление" или "нарисуй себя"). Объектами являются и всевозможные ограничения, которые, по мнению автора, стоит выносить в настраиваемые Правила (SelfEvaluatingRule). Мотивация для отделения Правил такова, что объект автономен и обладает каким-то базовым поведением, а ограничения на это поведение зачастую специфичны для конкретного приложения. Сами же приложения представляются в качестве Сценариев, координирующих общение между объектами. (Здесь я заметил интересное различие в понимании "уровня приложения" между этой книгой и Domain Driven Design, прочтенной перед ней: у Уэста уровень приложения - это специфические сценарии, ограничивающие поведение доменных объектов. У Эванса - это инфраструктурные вещи, не связанные напрямую с доменом, вроде HTTP-контроллеров или скедулеров). Объекты кооперируются между собой, организуются в структуры (composability - одна из важнейших черт ОО-подхода), отсылают друг другу сообщения (в которых просят предоставить какую-то услугу), подписываются на изменения состояния своих соседей. Объектом является и пользователь приложения, и довольно необычно было видеть "перевернутую" sequence-диаграмму - не когда пользователь заполняет пассивную форму с данными, а когда форма с данными просит пользователя предоставить ей инфу (просит, например, в виде пустого текстбокса или надоедливо мигающего курсора). Кусочек функциональности приложения - это скрипт с коллаборацией объектов, и когда программисты анализируют эту функциональность перед разработкой, они пытаются "рассказать историю общения объектов" (что хорошо ложится на термин Story из Agile). Централизованного контроля следует избегать, распределяя сложное поведение между объектами.
У книги довольно много пересечений с Domain Driven Design Эрика Эванса касательно фокуса на предметной области, но книга Эванса мне показалась более содержательной и конкретной. Возможно, потому что в ней больше внимания уделено паттернам, в то время как Уэст прямо говорит, что его главы с примерами не стоит воспринимать как "книгу рецептов". Цель его книги - научить думать в терминах объектов. Уэст - эталонный евангелист, который утверждает, что труъ объектный подход радикально упрощает код и улучшает поддерживаемость системы. И даже если по Бруксу "серебряной пули нет", то объектное мышление по всем своим признакам как будто бы попадает под определение серебряной пули. И систему любой сложности у него можно написать, используя всего несколько сотен объектов. Все это очень занятно, интересно и местами познавательно, вот только какого-то глубокого инсайта, раскрывающего глаза, у меня так и не случилось. Может, тру-ООП и способно привести меня в прекрасный мир радужных пони, вот только "истинный" объектно-ориентированный подход мало кто умеет готовить, и потребуется много времени, усилий и практики, чтобы его освоить. И поэтому сходу не скажешь, так ли действительно ценны те принципы, которые пропагандирует Уэст. Попробовать, наверное, стоит, хотя бы ради интереса. Вот только впечатление подпортила ремарка самого автора, которую он честно привел ближе к концу книги в разделе про рулы: поскольку автор - университетский преподаватель, до поры до времени он никогда не пробовал реализовать свои рулы, о которых рассказывал студентам - он оставлял это им в качестве практического задания. Имплементировал он их только однажды, спустя долгое время и в академических целях.
Завершают книгу мысли об Objectionary - репозитории универсальных и переиспользуемых объектов, из которых "специ��листы по сборке приложений" могли бы собирать для себя системы, не прибегая к услугам программистов. И хотя идея отказаться от программирования не нова и в последнее время переживает очередной подъем в виде no-code платформ, с момента появления книги в 2004 году кардинально ничего не поменялось - ни в плане отказа от программистов, ни в плане отказа от формализма в пользу некоего правильного объектного мышления. Идеи автора, может быть, и здравые, но вот насколько приближен к реальности евангелист-теоретик - все еще большой вопрос. Но, пожалуй, почитать все равно стоило.
Довольно трудно формализовать такую тему как развитие определенного образа мышления, поэтому Уэст решил начать с истории ООП, а потом перейти основным понятиям и примерам.
Это в большей степени не техническая, а философская книга: в первых главах на читателя вываливаются горы всевозможных работ - начиная от Платона и его идей, и заканчивая исследованиями интеллекта и сложных систем. Перед читателем предстает история противостояния формального (традиционного, рационального) и герменевтического (эвристического, свойственного ООП) подходов к разработке ПО. Объектно-ориентированный подход еще с момента своего появления в 60х годах подвергался критике со стороны тех, кто видел в программировании математическую точность и строгость. Развитие неформального ОО-подхода в итоге вылилось в появление agile и экстремального программирования, и автор особенно активно топит за последнее.
Как обычно бывает в таких книгах, основные идеи можно сформулировать достаточно кратко, а большая часть книги сообщает контекст, примеры, метафоры, терминологию и т.п. Объект - самостоятельная единица, симулирующая что-то из реальности и предоставляющая свои сервисы. По Уэсту, формулировать интерфейс объекта в виде предоставляемых сервисов - принципиальный момент. Например, "содержать в себе информацию о клиенте" - это не сервис. А вот "предоставить описание" клиента - уже сервис. В целом, сервисы нужно формулировать в активном залоге. Все на свете является объектом, предоставляющим какие-то сервисы (даже символ, который предоставляет сервисы в своем узком домене, вроде "дай свое байтовое представление" или "нарисуй себя"). Объектами являются и всевозможные ограничения, которые, по мнению автора, стоит выносить в настраиваемые Правила (SelfEvaluatingRule). Мотивация для отделения Правил такова, что объект автономен и обладает каким-то базовым поведением, а ограничения на это поведение зачастую специфичны для конкретного приложения. Сами же приложения представляются в качестве Сценариев, координирующих общение между объектами. (Здесь я заметил интересное различие в понимании "уровня приложения" между этой книгой и Domain Driven Design, прочтенной перед ней: у Уэста уровень приложения - это специфические сценарии, ограничивающие поведение доменных объектов. У Эванса - это инфраструктурные вещи, не связанные напрямую с доменом, вроде HTTP-контроллеров или скедулеров). Объекты кооперируются между собой, организуются в структуры (composability - одна из важнейших черт ОО-подхода), отсылают друг другу сообщения (в которых просят предоставить какую-то услугу), подписываются на изменения состояния своих соседей. Объектом является и пользователь приложения, и довольно необычно было видеть "перевернутую" sequence-диаграмму - не когда пользователь заполняет пассивную форму с данными, а когда форма с данными просит пользователя предоставить ей инфу (просит, например, в виде пустого текстбокса или надоедливо мигающего курсора). Кусочек функциональности приложения - это скрипт с коллаборацией объектов, и когда программисты анализируют эту функциональность перед разработкой, они пытаются "рассказать историю общения объектов" (что хорошо ложится на термин Story из Agile). Централизованного контроля следует избегать, распределяя сложное поведение между объектами.
У книги довольно много пересечений с Domain Driven Design Эрика Эванса касательно фокуса на предметной области, но книга Эванса мне показалась более содержательной и конкретной. Возможно, потому что в ней больше внимания уделено паттернам, в то время как Уэст прямо говорит, что его главы с примерами не стоит воспринимать как "книгу рецептов". Цель его книги - научить думать в терминах объектов. Уэст - эталонный евангелист, который утверждает, что труъ объектный подход радикально упрощает код и улучшает поддерживаемость системы. И даже если по Бруксу "серебряной пули нет", то объектное мышление по всем своим признакам как будто бы попадает под определение серебряной пули. И систему любой сложности у него можно написать, используя всего несколько сотен объектов. Все это очень занятно, интересно и местами познавательно, вот только какого-то глубокого инсайта, раскрывающего глаза, у меня так и не случилось. Может, тру-ООП и способно привести меня в прекрасный мир радужных пони, вот только "истинный" объектно-ориентированный подход мало кто умеет готовить, и потребуется много времени, усилий и практики, чтобы его освоить. И поэтому сходу не скажешь, так ли действительно ценны те принципы, которые пропагандирует Уэст. Попробовать, наверное, стоит, хотя бы ради интереса. Вот только впечатление подпортила ремарка самого автора, которую он честно привел ближе к концу книги в разделе про рулы: поскольку автор - университетский преподаватель, до поры до времени он никогда не пробовал реализовать свои рулы, о которых рассказывал студентам - он оставлял это им в качестве практического задания. Имплементировал он их только однажды, спустя долгое время и в академических целях.
Завершают книгу мысли об Objectionary - репозитории универсальных и переиспользуемых объектов, из которых "специ��листы по сборке приложений" могли бы собирать для себя системы, не прибегая к услугам программистов. И хотя идея отказаться от программирования не нова и в последнее время переживает очередной подъем в виде no-code платформ, с момента появления книги в 2004 году кардинально ничего не поменялось - ни в плане отказа от программистов, ни в плане отказа от формализма в пользу некоего правильного объектного мышления. Идеи автора, может быть, и здравые, но вот насколько приближен к реальности евангелист-теоретик - все еще большой вопрос. Но, пожалуй, почитать все равно стоило.
October 19, 2009
This is a good read, but a bit tough one. It's not an easy-to-go "let's become an object coder". It's both philosophical and methodological - not the easiest combo for most developers, but a valuable read without doubt.
September 18, 2019
Superb historic overview of OO and Smalltalk history, limited practical advice, but some useful design techniques.
Definitely made me want to learn Smalltalk, and makes me sad to have missed the "golden age".
Definitely made me want to learn Smalltalk, and makes me sad to have missed the "golden age".
September 7, 2017
Though changing book, perfect.
August 28, 2022
West thoroughly emphasizes the behavioral aspect of objects, in opposition to the classic programming substances of procedures and data. In doing so, he frequently harkens back to Alan Kay and draws from Smalltalk, which is why the coding examples in the book look a lot different than Java or C++ (a good thing!). My only criticism of the author's concept of objects is that he occasionally conflates subclassing with subtyping, though he still explored the different types of inheritance and has an altogether message-oriented view of OOP.
XP - Extreme Programming - is mentioned frequently throughout the book, though I hadn't really heard much about it before. Seems to have been absorbed by Agile, which is unfortunate as the Agile we ended up with is very far removed from the human-centered evolutionary goals XP and the original manifesto were based around. The modeling and design methods presented here are intentionally light on process but still seem like they could be improved on.
Ultimately, this book takes a postmodern perspective on software development, centered around software's unique ability to simulate through the metaphor of objects. This is pretty much the antithesis of formal methods and the notion of computers being a pure, mathematical realm - better to adopt computers to the messy and complex nature of reality than try to bend reality to the precision of the computer, though that seems to be more and more the direction taken recently. Being published in 2004, this book came at the tail end of the object-oriented hype period, after Java's wild rise and the mountains of backlash it generated, especially as Java tends towards a programming style that is at odds with object thinking. Smalltalk isn't dead but it won't ever return to the commercial success it found in the era immediately preceding Java (did I mention I dislike Java?) - we need some fresh takes on OOP that facilitate object thinking and take principled breaks from the C/ALGOL mainstream of data/procedures/heavy syntax.
XP - Extreme Programming - is mentioned frequently throughout the book, though I hadn't really heard much about it before. Seems to have been absorbed by Agile, which is unfortunate as the Agile we ended up with is very far removed from the human-centered evolutionary goals XP and the original manifesto were based around. The modeling and design methods presented here are intentionally light on process but still seem like they could be improved on.
Ultimately, this book takes a postmodern perspective on software development, centered around software's unique ability to simulate through the metaphor of objects. This is pretty much the antithesis of formal methods and the notion of computers being a pure, mathematical realm - better to adopt computers to the messy and complex nature of reality than try to bend reality to the precision of the computer, though that seems to be more and more the direction taken recently. Being published in 2004, this book came at the tail end of the object-oriented hype period, after Java's wild rise and the mountains of backlash it generated, especially as Java tends towards a programming style that is at odds with object thinking. Smalltalk isn't dead but it won't ever return to the commercial success it found in the era immediately preceding Java (did I mention I dislike Java?) - we need some fresh takes on OOP that facilitate object thinking and take principled breaks from the C/ALGOL mainstream of data/procedures/heavy syntax.
November 8, 2024
I fell in love with the object decomposition aspect of software development. The book felt almost philosophical, offering profound perspectives that reshaped my understanding. It introduced me to valuable references I hadn't known existed. I became such a fan of David’s work that I even reached out to him directly, and to my delight, he responded promptly and graciously.
July 14, 2024
u know u are dealing with programmers not philosophers u canot explain theses things like u dive deep into philosophy matters that u make us lost , what the hell is he talking about !!!
August 5, 2007
object oriented thinking.
July 19, 2008
Gives a good overview of thinking in objects in more of the Smalltalk way. Has a good history discussion.
May 2, 2010
Some interesting ideas, but much too long: like most software engineering books it would benefit by being reduced to half its length or less.
October 17, 2012
Great book, no only the technic of OO, but a text about history of OO and its philosophy
October 8, 2014
IMHO the only REALLY good book about object-oriented programming. Changed my view and thinking profoundly.
October 16, 2017
Didn't finish.
November 9, 2014
Definitely worth reading
Displaying 1 - 27 of 27 reviews