smalltalk
Kyle Brown, IBM Fellow, CTO Cloud Architecture, IBM Cloud and Cognitive Software
Kyle Brown，IBM研究员，CTO云架构，IBM Cloud和认知软件
The last year has not been kind to a book that I believe to be one of the classic, and most important works of computer science — the book Design Patterns: Elements of Reusable Object Oriented Design. This is unfortunate, because the preceding year had been the 25th anniversary of the book’s publication and it’s odd that a book that old can generate such vitriol. The twitterverse in particular has been pretty savage to the book — using words like “impenetrable” and in one memorable put-down “the Atlas Shrugged of Computer Science”.
去年对我认为是计算机科学的经典也是最重要的著作之一的书并不好，这本书是《设计模式：可重用的面向对象设计的元素》 。 这是不幸的，因为前一年是该书出版25周年，奇怪的是，一本陈旧的书会产生这种硫酸。 特别是twitterverse在这本书中相当精明-使用“难以理解”之类的词语和一个令人难忘的“计算机科学地图集”。
In a sense, I’m not surprised by this. Even when the book came out, it seemed it had as many detractors as it had supporters. What’s more, even when it was being written, there was a small but impassioned contingent of reviewers at the time that argued that the book needed to be completely rewritten before it was ever published. But every book has issues — and Design Patterns is not immune to the fact that any work is at best an imperfect reflection of the ideas of the authors.
从某种意义上说，我对此并不感到惊讶。 即使这本书问世，似乎它的批评者和支持者一样多。 更重要的是，即使在撰写本书时，当时也只有一小部分但充满激情的审阅者认为这本书在出版之前需要完全重写。 但是每本书都有问题-设计模式不能免除以下事实：任何作品充其量都不能完全反映作者的想法。
However, what to my mind is the most difficult part to understand is that regardless of comments on the format, style, or even font choice of the work, I’ve never quite understood is how anyone could reject the ideas contained within it as being either trivial, useless, or banal. But then again, that’s where my experience as a programmer, and an author, differs from what I have found over the last twenty-five years to be the most common case.
但是，我认为最难理解的部分是，无论对作品的格式，样式，甚至字体选择发表评论，我都从未完全理解过，有人会如何拒绝其中包含的想法琐碎，无用或过时的。 但是话又说回来，这就是我作为程序员和作家的经历，与过去二十五年来我发现的最普遍的情况不同。
So let’s start with the beginning. I first learned how to program in the same way many people of my generation did — we learned BASIC programming on a home computer. For me, it was a succession of them that I encountered at school, at friends houses, and eventually that I owned. During my high school years I learned to program on the Apple II in Integer and Applesoft BASIC, on the VIC-20, on the TI-99/4A, and on the Sinclair TX1000. Programming on the Sinclair, with only 4K and it’s bizarre shift-key combinations to create BASIC keywords was very different experience from programming on the relatively spacious 48K that the Apple II possessed and it’s wonderfully tactile keyboard that required you to fully type out all of your commands. As a result, I did a lot more low-level development with PEEK and POKE on the Sinclair than I did on the Apple, where the wonderful floating-point capabilities of Applesoft BASIC gave me free reign for my imagination. So nearly from the beginning, I learned that your available environment and language formed the way you thought about a problem.
因此，让我们从头开始。 我首先学习了如何以与我们这一代人相同的方式进行编程-我们在家用计算机上学习了BASIC编程。 对我而言，这是我在学校，朋友之家以及我最终拥有的那一系列的继任者。 在我高中的时候，我学会了使用Integer的Apple II和Applesoft BASIC，VIC-20，TI-99 / 4A和Sinclair TX1000进行编程。 在Sinclair上仅进行4K编程，以及使用奇异的Shift键组合来创建BASIC关键字的经历，与在Apple II所拥有的相对宽敞的48K上进行编程的体验大不相同，而出色的触觉键盘要求您完全键入所有内容命令。 结果，我在Sinclair上使用PEEK和POKE进行的底层开发要比在Apple上进行的开发更多，Applesoft BASIC出色的浮点功能使我可以自由发挥自己的想象力。 因此，几乎从一开始，我就知道您可用的环境和语言构成了您对问题的思考方式。
Besides that, the way I learned to program was pretty typical for the time — I learned by writing programs. Now, there would be some programs that you could read — particularly those published in magazines where you had to type them in to run them (no internet!) and in the few that were available freely and circulated on BBS, disk and tape (long before “open source” became a thing), but in general, you learned how to solve problems by solving problems.
除此之外，我当时学习编程的方式非常典型-我是通过编写程序来学习的。 现在，您可以阅读一些程序，特别是那些在杂志上发布的程序，您必须键入它们才能运行它们(没有互联网！)，还有少数可以免费使用并在BBS，磁盘和磁带上流通的程序(长在“开源”成为现实之前)，但总的来说，您学习了如何通过解决问题来解决问题。
When I went to University for my degree, I found that this was still the predominant paradigm for learning the trickier bits of programming and of computer science. For example, when I took a class on operating systems, we would read about a concept, like a semaphore, or a file system, and then be expected to be able to implement the concept. There might be a few simple examples in the text to help get you over the hump as to how the implementation would work, but more often than not these were in a type of pseudocode that you would have to mentally translate into C or C++.
当我去大学攻读学位时，我发现这仍然是学习编程和计算机科学中比较棘手的知识的主要范例。 例如，当我上一堂关于操作系统的课程时，我们将阅读有关信号灯或文件系统等概念的信息，然后期望它能够实现该概念。 文本中可能有一些简单的示例，以帮助您了解实现的工作原理，但更多情况下，这些示例都是伪思维类型，您必须将其转换为C或C ++。
When I graduated from University and went to work as a C++ and C programmer, nothing much changed from the way I had learned things in college. Every programming problem began with searching out the documentation of the relevant libraries, then sitting down and plotting out how to write the solution from scratch. That was just the way I thought development should be, and always would be.
当我大学毕业并以C ++和C程序员的身份工作时，我在大学学习的方式没有太大变化。 每个编程问题都始于搜索相关库的文档，然后坐下来规划如何从头开始编写解决方案。 那就是我认为发展应该而且永远都会的方式。
But then, in the winter of 1989, I had an unusual opportunity come my way that changed the way I thought about programming by changing the way I thought about how to solve problems. That opportunity was when I was introduced to Smalltalk (particularly the Smalltalk/V PM version from Digitalk). Writing programs in Smalltalk is such a departure from traditional ways of developing that it took me a long time to fully wrap my head around it. I’ve found that people that try to learn it end up in one of two extremes — either it becomes their all-time favorite development language and environment, or they hate it with a passion bordering on mania.
但是后来，在1989年冬天，我有了一个不寻常的机会，改变了我对解决问题的方式，改变了我对编程的看法。 那个机会是当我被介绍给Smalltalk时(尤其是Digitalk的Smalltalk / V PM版本)。 用Smalltalk编写程序与传统的开发方式截然不同，以至于我花了很长时间才全神贯注于它。 我发现，尝试学习它的人最终会遇到两个极端之一，要么成为他们一直以来最喜欢的开发语言和环境，要么就以对躁狂症的热情讨厌它。
In order to understand why this is true, you need to understand some things that were, at the time completely radical about Smalltalk, and that even to this day, have not fully been replicated in any other development language or environment.
为了理解为什么这样做是正确的，您需要了解一些当时完全关于Smalltalk的东西，直到今天仍未在任何其他开发语言或环境中完全复制。
1. Smalltalk does not have files where you put your source code. Now, in a sense that’s a lie, because there IS a single file that contains your source code, but it’s not organized the way you think it might be. Instead of a single file for each module or class, all of the early Smalltalk implementations feature a single large, rolling log file, called the change log, that contains the new source code that you’ve added to the system. As you add a new method, or modify a method, it gets added on the end of the change file.2. Smalltalk doesn’t have a file-based compilation system — instead, every change you make to any method or class definition in that changes file is instantly compiled by an incremental compiler and added into a single, large, in-memory image of the entire Smalltalk system. 3. Smalltalk was (and is) completely and totally Object-oriented. It was object-oriented in a way that Java, Python or C++ (or newer languages) cannot even match — in that even Integers are objects — and what’s more, you can extend the behavior of an Integer by adding new methods to it!4. Smalltalk had this great concept called Workspaces that allowed you to highlight and run little snippets of code of any length — it would just compile and run them instantly. People would also mix and match documentation and code snippets within a Workspace — this is the basic idea behind Jupyter notebooks today. This was awesome for just trying something out to see what it did — part of a process of learning by exploration.
1. Smalltalk没有放置源代码的文件。 现在，从某种意义上讲这是一个谎言，因为只有一个文件包含您的源代码，但是它没有按照您认为的方式组织。 所有早期的Smalltalk实现都具有一个大的滚动日志文件(称为更改日志)，而不是每个模块或类只有一个文件，该文件包含您已添加到系统中的新源代码。 当您添加新方法或修改方法时，它会添加到更改文件的末尾。2。 Smalltalk没有基于文件的编译系统-相反，您对任何方法或类定义所做的每次更改都会由增量编译器立即进行编译，并添加到整个内存的单个大映像中Smalltalk系统。 3. Smalltalk完全(并且是)完全面向对象的。 它是面向对象的，Java，Python或C ++(或更新的语言)甚至无法匹配-因为即使Integer都是对象，而且，您可以通过向Integer添加新方法来扩展其行为！4 。 Smalltalk具有一个称为Workspaces的出色概念，它使您可以突出显示并运行任何长度的代码片段-它只是立即编译并运行它们。 人们还会在工作区中混合并匹配文档和代码段，这是当今Jupyter笔记本背后的基本思想。 尝试尝试一些东西以查看其效果真是太棒了-这是探索学习过程的一部分。
But that last observation is merely the tip of the iceberg on what I think was one of the most revolutionary things about Smalltalk that changed the way I develop — and influenced the way that everyone who was exposed to Smalltalk in those days thinks about development. The remainder of that iceberg is this — the entire system, from the code implementing the editors you developed in, to the basic system libraries like the Integer and Collection classes, up through the Smalltalk compiler classes themselves were available in that Image (from a single base, unchanging “sources” file) for you to read!
但是，最后的观察只是冰山一角，我认为这是Smalltalk最具革命性的事情之一，它改变了我的发展方式，并影响了当时接触过Smalltalk的每个人思考发展的方式。 冰山的其余部分是整个系统，从实现您所开发的编辑器的代码到基本系统库(如Integer和Collection类)，再到Smalltalk编译器类本身，都可以在该Image中使用(从单个基本的，不变的“源”文件)供您阅读！
It was this feature that changed the way I thought about developing — and that change only came about by how I was taught to use Smalltalk. I had the wonderful experience of being taught by two of the true masters of the language — Sam Adams and Ken Auer, who at the time were both with Knowledge Systems Corporation, one of the first Smalltalk consulting companies. The simple lesson they taught me was this:
正是这一功能改变了我对开发的思考方式，而这种改变仅是由教会我如何使用Smalltalk来实现的。 我有两个真正的语言大师Sam Sams和Ken Auer教书的经历，他们当时都在Knowledge Systems Corporation(最早的Smalltalk咨询公司之一)中任教。 他们教给我的简单教训是：
Don’t start any new programming task from scratch — always look in the Smalltalk image first to see what’s available and what has been already done before you start building anything new.
不要从头开始任何新的编程任务-在开始构建任何新内容之前，请始终先查看Smalltalk图像以了解可用的内容和已完成的操作。
To me, this was a revelation. It upended everything I had ever learned to this point about programming. But as I’ve thought back over my career and my life, I realized that this really isn’t that unusual. Think back to how you first learned to read (in whatever language that was). Your elementary school teachers didn’t expect you to write a novel as soon as you mastered the alphabet. No, what they probably did (I know mine did) was to first give you the opportunity to read at length before you were expected to be able to write something comparable. As I look back to my elementary school days, I remember writing a lot of book reports — which are really just shorter summaries of larger works — but the point is, we ended up reading probably 10 times more than we actually wrote.
对我来说，这是一个启示。 到目前为止，它颠覆了我从编程中学到的所有知识。 但是，当我回顾自己的职业生涯和生活时，我意识到这确实不是那么寻常。 回想一下您是如何第一次学习阅读的(无论使用哪种语言)。 您的小学老师没想到您掌握了字母后就会写小说。 不，他们可能所做的(我知道我的所作所为)是，首先让您有机会详细阅读，然后才期望您能够写出可比的东西。 当我回想起小学的时候，我记得写了很多书本报告-实际上只是较大作品的简短总结-但重点是，我们最终阅读的书数可能比实际写的书多10倍。
As I moved into high school and college, the lengths of the essays, reports and other things I was expected to write grew, but that same rough 10–1 ratio of reading to writing remained approximately the same, or even increased as I moved on to university and especially graduate school (where the ratio may have been 50–1).
当我升入高中和大学时，期望写论文，报告和其他内容的时间在增加，但是同样粗略的阅读与写作比率为10-1，大致保持不变，甚至随着我继续前进而增加。到大学，尤其是研究生院(比例可能是50–1)。
At this point, some of my Gen Z and Millenial friends will be losing interest as they start muttering about Boomers because of the following thought
此时，由于以下想法，我的Z世代和千禧一代朋友开始对婴儿潮一代发脾气时，他们会失去兴趣。
That’s just Boomertalk. We have this thing called the “Internet” now, and especially this thing called “Stack Overflow”
那只是Boomertalk。 我们现在有了一个叫做“ Internet”的东西，尤其是这个叫做“ Stack Overflow”的东西
(I’m Gen X, thank you — and as such my natural Gen X cynicism informs me that you forgot we exist, didn’t you!) But the argument I want to make is that using Stack Overflow is not the same as what I’m referring to — and that the experience was quite different. When you use Stack Overflow, or a search engine like Google, what you’re doing is narrowing in on a particular way of solving a problem in the specific way you describe it. That’s because you’re searching by keyword — what you’re missing is context — and the ability to see a solution in the context in which it was written. What you’re also missing is the serendipity of coming across a better way of thinking about a problem than you may have had in mind when you began the search. You’re also missing the sheer joy of just chasing rabbits through the source code as you sought to understand how a particular section of the code worked, which led you to another rabbit, and another.
(我是X世代，谢谢您，因此我自然的X世代愤世嫉俗告诉我，您忘记了我们的存在，不是吗！)但是我要说的是，使用Stack Overflow与使用Stack Overflow并不相同我指的是-体验截然不同。 当您使用Stack Overflow或类似Google的搜索引擎时，您正在做的事情就是以描述问题的特定方式来解决问题的特定方式。 这是因为您要通过关键字进行搜索-缺少的是上下文-并且能够在编写该上下文的环境中查看解决方案。 您还缺少的是，碰巧遇到了比开始搜索时可能想到的更好的问题思考方法。 当您试图了解源代码的特定部分是如何工作的，从而导致您找到另一只兔子时，您还错过了仅通过源代码追逐兔子的纯粹乐趣。
And that is where we work our way back to the original topic of this blog, which was the book Design Patterns. I had been a Smalltalk programmer for about five years when the book first came out — in fact, I first encountered the patterns in a xeroxed pre-print of part of the book before the book was officially released. Outside of the context of the book as a whole, they didn’t make much of an impression on me. But then, once the book was released, I took a copy with me on a long car ride from Raleigh to Atlanta (about six hours) and read it on the way. This time, it clicked.
这就是我们回到本博客原始主题的地方，即《设计模式》一书。 该书首次发行时，我已经是Smalltalk程序员大约五年了-实际上，在这本书正式发行之前，我在该书的一部分的施乐预印本中第一次遇到了这些模式。 在整本书的上下文之外，他们对我的印象并不多。 但是，当这本书发行后，我就从罗利到亚特兰大(约六个小时)乘了很长时间的汽车随身带着一本，并在途中阅读。 这次，它单击了。
So let’s think about how the way I had been developing for the last several years had molded my thinking — I would always browse through the Smalltalk source code for ideas and inspiration whenever I was solving a programming problem. That means I had read through most, if not all of the Smalltalk/V and Smalltalk-80 (VisualWorks) source code several times, and had been using things I picked up from that source code in the projects I was working on.
因此，让我们考虑一下我过去几年的开发方式如何塑造了我的思想-每当我解决编程问题时，我总是会浏览Smalltalk源代码以获取想法和灵感。 这意味着我已经多次阅读了大部分(如果不是全部的话)Smalltalk / V和Smalltalk-80(VisualWorks)源代码，并且在我正在从事的项目中一直使用从该源代码中挑选的东西。
What Design Patterns did was to suddenly give me a vocabulary for many (not all, but a lot) of the things that I had already encountered in reading all of that source code. I remember coming across Observer and thinking — “OK, I’ve not only seen this, but I’ve used this a couple of hundred times because you can’t write a GUI in VisualWorks Smalltalk without it.” Then I came across Mediator — and realized I had seen that inside the GUI source code of both Smalltalk versions, and as I read more I kept experiencing the same sense of deja vu over, and over, and over again.
Design Patterns所做的就是突然为我提供了我在阅读所有源代码时遇到的许多(不是全部，而是很多)事情的词汇表。 我记得遇到过观察者的想法：“好吧，我不仅看到了这一点，而且已经使用了数百次，因为没有它，您将无法在VisualWorks Smalltalk中编写GUI。” 然后，我遇到了Mediator ，并意识到我已经在两个Smalltalk版本的GUI源代码中看到了这一点，当我阅读更多内容时，我一遍又一遍地不断体验到同样的deja vu感觉。
The best analogy I can think of was as if I had been reading and writing fiction, but I didn’t have the vocabulary to describe what I was doing — I didn’t know what to call a Character, or a Scene, or a Plot Device, but I had used all of them on my own work and had encountered them in fiction I had read.
我能想到的最好的类比是好像我在读和写小说，但是我没有词汇来描述自己在做什么—我不知道该怎么称呼角色，场景或场景。绘制设备，但我在自己的作品中都使用了它们，并在我读过的小说中遇到了它们。
But the thing that it really did was to open my mind to the possibility that those 23 patterns weren’t all of the recurring themes that I had seen. Today, in fiction (particularly the anime and sci-fi genres) we call these Tropes, and there are entire websites devoted to them, like TVTropes, where you can learn about common themes like The Mad Scientist’s Beautiful Daughter and The Sorting Algorithm of Evil (read them both — you’ll recognize them). But the idea is much older — Joseph Campbell famously declared that there is a single “monomyth” called The Hero’s Journey that can capture the essence of every epic story from The Odyssey through Star Wars.
但是，真正要做的是让我敞开心mind，以为这23种模式并不是我所见过的所有重复出现的主题。 如今，在小说中(尤其是动漫和科幻小说)，我们将其称为Tropes，并且有专门针对它们的整个网站，例如TVTropes ，您可以在其中了解常见的主题，例如《疯狂科学家的美丽女儿》和《邪恶排序算法》 (同时阅读它们-您会认出它们的)。 但是这个想法远不如以前-约瑟夫·坎贝尔(Joseph Campbell)著名地宣称，有一个名为“英雄之旅”的“怪胎”可以捕捉《奥德赛》到《星际大战》中每一个史诗故事的精髓。
And that wraps me back around to the original thesis of this blog. People pick up Design Patterns and expect to read it as literature, but you can’t do that — it’s not a story. You shouldn’t read it that way. It’s more like a textbook about comparative literature. At its best it teaches you something about the art of writing code, much like a comparative literature textbook would teach you something about the art of writing fiction. It will not teach you programming — that is the problem with the way many people started applying the patterns, which resulted in unbelievable overuse of the 23 patterns where they applied the “Everything looks like a nail when you have a hammer” antipattern.
这使我回到了该博客的原始论文。 人们会选择“设计模式”并希望将其阅读为文学作品，但是您不能那样做-这不是故事。 你不应该那样看。 它更像是一本关于比较文学的教科书。 在最好的情况下，它会教给您一些有关编写代码的艺术，就像比较文学教科书会教给您有关编写小说的艺术一样。 它不会教您编程-这是许多人开始应用这些模式的方式的问题，这导致人们难以置信地过度使用了23种模式，他们在其中应用了“当您有锤子时，一切都像钉子”反模式。
Instead, you should just think of the patterns as 23 terms that can be useful for describing particular tropes that are most common in object-oriented programming. It can help you recognize those tropes, and even give you some indication as to when they might be helpful — but most importantly it gives you a vocabulary to talk to others about those tropes.
相反，您应该只将模式视为23个术语，这些术语对于描述面向对象编程中最常见的特定主题很有用。 它可以帮助您识别这些比喻，甚至可以给您一些指示，指出它们何时可能会有所帮助-但最重要的是，它为您提供了与其他人谈论这些比喻的词汇。
Now, there is one more thing I want to bring in about this — probably the most common thing I hear people dismiss the patterns as are “well, these are just things that are language features in X, Y or Z, so you don’t need them in that language”. Nothing could be farther from the truth.
现在，我还想介绍一件事-可能是我听见的人们最常忽略的模式，因为“好吧，这些只是X，Y或Z语言的特征，所以您不需要不需要那种语言的人”。 没有什么比真相更遥远。
You see, the first language that this particular trope was applied to was Smalltalk! When the book came out, the Smalltalk message boards (remember — this was 1996!) were flooded with messages from Smalltalk developers saying that these patterns were only needed because C++ (which was the only other OO language widely used at the time) was so deficient. This was despite the fact that about half of the examples in Design Patterns were originally written in Smalltalk.
您会看到，此特殊音符应用于的第一种语言是Smalltalk！ 当这本书问世时，Smalltalk留言板(记住-那是1996年！)充斥着Smalltalk开发人员的消息，他们说，仅当C ++(当时是唯一被广泛使用的OO语言)才需要这些模式。不足。 尽管有这样一个事实，“设计模式”中约有一半的示例最初是用Smalltalk编写的。
But this is where I was able to help out. To make a long story short, Sherman Alpert, Bobby Woolf and I became co-authors of The Design Patterns Smalltalk Companion — the very first official follow-on book to Design Patterns. We showed that the ideas, the tropes, are universal. You can implement them more simply in some languages than others, but the fact that the ideas remain the same across the boundaries of language and environment is the important thing.
但这是我能够提供帮助的地方。 为了使长话短说，谢尔曼·阿尔珀特，鲍比·伍尔夫和我成为设计模式的Smalltalk伴侣的合着者-最先官方后续书设计模式。 我们证明了这些思想，即对立，是普遍的。 您可以使用某些语言比使用其他语言更简单地实现它们，但是重要的一点是，思想在语言和环境的边界上保持不变。
Which brings me to the last point I want to make — if you don’t understand the patterns, and can’t make heads or tails of them, maybe one thing to do is — read more code. If you’ve primarily read your own code, and you’ve not read widely in the code of others, odds are good that you’ve not encountered any of the patterns, much like you’d never encounter The Sorting Algorithm of Evil if you never watched or read any science fiction or played online MMORPGs. But the more you watch and read, the more likely you are to encounter that trope.
这将我带到我想讲的最后一点—如果您不了解这些模式，并且无法制作它们的头或尾，也许要做的一件事就是—阅读更多代码。 如果您主要阅读自己的代码，并且没有广泛阅读他人的代码，则很可能没有遇到任何模式，就像您从未遇到过“邪恶的排序算法” ，您从未看过或读过任何科幻小说或在线玩过MMORPG。 但是，您观看和阅读的次数越多，遇到该望远镜的可能性就越大。
Another thing to do is to read particular types of code — let’s be honest — not all code is created equally. In my job I do a lot of code review of client code, mostly in Java, and some of it is particularly terrible. In fact, there’s one problem I see that is endemic. That’s where the code is “supposedly” object-oriented, but in fact, it doesn’t take advantage of any of the features of object orientation (no inheritance, no method overrides, and few if any uses of type substitution). In particular I see tons of code where there are these static “data” objects (a misunderstanding of another pattern from Martin Fowler, called the Data Access Object) and these “processing” objects that are, for the most part, just bags of procedures that operate on the data objects. This is object-orientation in name only, and not in practice. If the only code you ever encounter looks like that, then I again understand why you may never have encountered any of the patterns from Design Patterns. I also feel terrible for you, because reading code like that is painful and wearing. Unfortunately, I think that this style of development is encouraged by the very tools we use to develop them — editors that focus on the level of a file will, unfortunately, never encourage you think about what lies beyond the context of the file — yet another thing that’s been lost as file-oriented languages and development environments took over.
另一件事是阅读特定类型的代码-坦白地说-并非所有代码都是平等创建的。 在我的工作中，我对客户端代码进行了很多代码审查，大部分都是用Java编写的，其中有些特别糟糕。 实际上，我发现有一个地方性的问题。 那是代码“应该”面向对象的地方，但是实际上，它没有利用面向对象的任何功能(没有继承，没有方法覆盖，很少使用类型替换)。 尤其是我看到大量的代码，其中包含这些静态“数据”对象(对Martin Fowler的另一种模式的误解，称为数据访问对象)，而这些“处理”对象在大多数情况下只是程序包对数据对象进行操作的对象。 这仅是名称上的面向对象，而不是实际上。 如果您遇到的唯一代码看起来像这样，那么我再次理解为什么您可能从未遇到过Design Patterns中的任何模式。 对于您来说，我也感到很糟糕，因为阅读这样的代码既痛苦又疲惫。 不幸的是，我认为这种开发风格受到了我们用于开发它们的工具的鼓舞-不幸的是，专注于文件级别的编辑器永远不会鼓励您思考超出文件上下文之外的内容–而另一个随着面向文件的语言和开发环境的接管，这种东西已经丢失了。
Despite that potential pain, in any case, reading more code can never be a bad thing. If you don’t have any good code to read in your work, then I encourage you to turn to open source projects — many of us simply consume open-source code and use the public API’s without ever diving down into understanding how the internals are written — doing that will give you an opportunity to see how many different people code, and to compare many different styles of development. Even if you don’t see the 23 patterns from Design Patterns, you will learn to identify and pick up other tropes that will, I guarantee, improve your programming in whatever language you develop in. And, if you want to help others out with a vocabulary to describe those tropes, then you can do what the authors of Design Patterns did — write the trope down so that others can identify it. That’s how everyone will benefit — you from learning from the experiences of others, and everyone else from being able to adopt your vocabulary when they re-encounter that particular concept.
尽管存在潜在的痛苦，但是在任何情况下，阅读更多代码永远不是一件坏事。 如果您在工作中没有任何好的代码需要阅读，那么我建议您转向开源项目-我们中的许多人仅使用开源代码并使用公共API，而无需深入了解内部原理。编写的文档—这样做将使您有机会查看有多少不同的人编写代码，并比较许多不同的开发样式。 即使您没有从Design Patterns中看到23种模式，您也将学习识别并选择其他比喻，我保证，这些比喻将以您开发的任何语言来改善您的编程。并且，如果您想帮助其他人，用词汇表描述这些对白，然后您可以做“设计模式”的作者所做的工作-写下该对白，以便其他人可以识别。 这就是每个人都会从中受益的方式-您从其他人的经验中学习，而其他人在他们重新遇到该特定概念时能够采用您的词汇。
BTW, if you want to try Smalltalk yourself, Squeak Smalltalk provides a very faithful open-source implementation of Smalltalk and is available on most platforms.
顺便说一句，如果您想自己尝试Smalltalk， Squeak Smalltalk提供了一个非常忠实的Smalltalk开源实现，并且在大多数平台上都可用。
翻译自: https://medium.com/@kylegenebrown/design-patterns-smalltalk-and-the-lost-art-of-reading-code-1727d93fd7fa
smalltalk