如何培养*现实生活*oop 技能？
我已经研究 OOP 有一段时间了，并且对理论有了很好的掌握。 我读了关于 OOP 的 Head First 书，虽然它强化了很多理论上，我发现案例研究有点微不足道。
我发现我每天都在代码中应用 OOP 原则，但我不确定我是否正确应用了它们。 我需要达到这样的程度：我能够查看我的代码，并知道我是否正确使用了继承，我的对象是否足够内聚，等等。
是否有人有任何好的建议（书籍、在线指南、博客、步行） -通过等）以采取下一步发展扎实的 OOP 技能？
我主要使用 .NET（Visual Basic）工作，但我欢迎结合各种平台的建议。
I've been studying OOP for quite a while now and I have a good grasp of the theory. I read the Head First book on OOP and, while it reinforced a lot of the theory, I found the case studies to be somewhat trivial.
I find that I'm applying OOP principles to my code each day, but I'm not sure if I'm applying them correctly. I need to get to the point where I am able to look at my code and know whether I'm using inheritance appropriately, whether my object is cohesive enough, etc.
Does anyone have any good recommendations (books, online guides, blogs, walk-throughs, etc.) for taking the next step in developing solid OOP skills?
I am working primarily in .NET (visual basic), but I welcome suggestions that incorporate various platforms.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
要彻底理解任何事情，您需要对至少一个抽象级别以上和以下一个抽象级别有足够的了解。 就 OO 而言，其他人提到设计模式是 OO 之上的一层。 这有助于说明为什么面向对象是有用的。
至于面向对象下面的层，请尝试使用高阶函数/后期绑定一段时间，并了解如何使用这些相对简单的构造。 另外，尝试了解 OO 是如何在底层实现的（虚函数表等）以及如何在纯 C 中完成它。一旦您理解了使用高阶函数和后期绑定的价值，您很快就会意识到 OO 是只是一种方便的语法，用于传递一组相关函数及其操作的数据。
To understand basically anything thoroughly, you need to have a decent knowledge of at least one abstraction level above and one level below it. In the case of OO, others have mentioned design patterns as the layer above OO. This helps a lot to illustrate why OO is useful.
As far as the layer below OO, try to play around with higher-order functions/late binding for a while and get a feel for how these relatively simple constructs are used. Also, try to understand how OO is implemented under the hood (vtables, etc.) and how it can be done in pure C. Once you grok the value of using higher order functions and late binding, you'll quickly realize that OO is just a convenient syntax for passing around a set of related functions and the data they operate on.
阅读 Martin Fowler 的重构，并将其应用到您自己的工作中。
它将带您了解软件代码的一系列恶臭特征，这些特征描述了如何检测不正确构造的类，更重要的是，如何修复它们。
Read Refactoring by Martin Fowler, and apply it to your own work.
It will take you through a litany of malodorous characteristics of software code that describe how to detect improperly constructed classes, and even more importantly, how to fix them.
考虑研究设计模式。 尽管它们似乎并不常用于企业应用程序（我发现它们更常用于 API 和框架而不是嵌入到企业代码中），但它们可以在很多情况下用于使软件更简单或更强大，如果只有开发人员知道如何应用它们。
关键是首先了解设计模式，然后根据经验，您将学习如何应用它们。
有一本关于设计模式的 Head First 书籍，它非常简单地教授这个概念，不过如果你想要一本书的话真正详细介绍了设计模式，请查看四人组设计模式书 ，这基本上是设计模式成为主流的原因，并且几乎每次提出该主题时都会提到。
设计模式可以在某种程度上应用于几乎任何面向对象的语言，尽管某些模式在某些情况下可能是过度杀伤或过度工程的。
编辑：
我还想补充一点，你应该看看Code Complete 2这本书。 这是软件开发领域非常有影响力的一本书。 它涵盖了许多不同的概念和理论。 每次读它我都会学到新东西。 这是一本好书，如果我每 6 个月到一年读一次，我就会从不同的角度来看待它，通过重读它，我就能成为一个更好的程序员。 无论你认为自己知道多少，这本书都会让你意识到你真正知道的有多么少。 这真是一本很棒的书。 我无法强调你应该拥有多少这本书。
Consider looking into Design Patterns. Although it seems like they aren't commonly used in enterprise applications (I've seen them more commonly used in API's and Frameworks than embedded into enterprise code), they could be applied to make software simpler or more robust in a lot of situations if only developers knew how to apply them.
The key is to understand the design patterns first, then with experience you'll learn how to apply them.
There is a Head First book on design patterns that teaches the concept pretty simply, although if you want a book that really covers design patterns in detail, check out the Gang of Four design patterns book, which is basically what made design patterns mainstream and is referred to almost every time the topic is brought up.
Design patterns can be applied in pretty much any object-oriented language to some degree or another, although some patterns can be overkill or over engineering in some cases.
EDIT:
I also want to add, you should check out the book Code Complete 2. It's a very influential book in the world of software development. It covers a lot of different concepts and theories. I learn something new every time I read it. It's such a good book that if I read it every 6 months to a year, I look at it from a different perspective that makes me a better programmer just by re-reading it. No matter how much you might think you know, this book will make you realize just how little you really know. It's really a great book. I can't stress how much you should own this book.
如果您已经具备了基础知识，我相信只有经验才能让您走得更远。 你说你不确定你是否正确应用了这些原则，但没有一种正确的方法。 您今天编写的代码，您将在 6 个月后查看，并想知道为什么要这样编写，并且可能知道更好、更简洁的方法。 我还保证 10 年后，你仍然会学习新的技术和技巧。 不要太担心它，它会来的，只要尽可能多地阅读，并尝试将所读到的内容分成小部分应用。
If you already have the basics, I believe only experience will get you further. You say you are not sure if you are applying the principles correctly, but there is no one correct way. Code you write today, you'll look at in 6 months time, and wonder why you wrote it that way, and probably know of a better, cleaner way of doing it. I also guarantee that after 10 years, you'll still be learning new techniques and tricks. Don't worry too much about it, it will come, just read as much as you can, and try and apply what you read in small chunks.
我目前正在阅读以下书籍的一半：
http://www.amazon.com /Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062
在学习现实生活中的、专业级的、实用的方法方面，我强烈推荐这本书在深入研究代码之前，起草并应用格式良好的迭代设计策略。
我也读过《Head First》这本书，并觉得读了它之后我的处境好多了。
在拥有了几年的工作经验之后，我现在认为我推荐的克雷格·拉曼的书对我来说是完美的“下一步”。
关于本书标题中出现的“UML”：
无论您对 UML 符号有积极的感受还是消极的感受，请不要让它影响您购买本书（ISBN 0131489062）的决定。
标题中突出的“UML”具有误导性。 虽然作者确实使用并解释了 UML 表示法，但这些解释非常好地融入到相关的设计讨论中，并且本书读起来绝不会像一本无聊的 UML 规范。
事实上，这是直接摘自书中的一段话：
这本书有时看起来像是在与首席架构师或项目经理“交谈”。 我的意思是，它假设读者对软件项目的规划和方向有很大的控制权。
尽管如此，即使您只负责公司项目和产品的一小部分，我仍然会推荐这本书，并鼓励您将本书建议的一些“缩小”修改应用到您的项目部分。
I am currently half-way through the following book:
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062
I cannot recommend this book strongly enough in terms of learning a real-life, professional-grade, practical approach to drafting and applying a well-formed and iterative design strategy before diving into code.
I, too, read the "Head First" book and felt that I was much better off for having read it.
After having a few years of working-world experience, I now view the Craig Larman book that I am recommending to be a perfect "next step" for me.
About the Presence of "UML" in this Book Title:
Whether you have positive feelings or negative feelings about UML notation, please do not let that influence your decision to buy the book (ISBN 0131489062) in either direction.
The prominence of "UML" in the title is misleading. While the author does use and explain UML notation, these explanations are extremely well-woven into relevant design discussions, and at no time does this book read like a boring UML spec.
In fact, here is a quote taken directly from the book:
This book at times seems like it is "speaking to" a lead architect or a project manager. What I mean to say by that is that it assumes that the reader has significant control over the planning and direction of a software project.
Nonetheless, even if you are only responsible for some very small piece of your company's projects and products, I would still recommend this book and encourage you to apply some "scaled down" modifications of the book's advice to your piece of the project.
我对 OOP 的顿悟来自很久以前的 Grady Booch 的书。 突然我意识到为什么物体是好的。
虽然多态性很酷，但封装是对象酷的 75% 的原因。 它有点像界面：您看到按钮但看不到接线。 在对象出现之前，只有最有纪律的编码人员才会将肮脏的手指远离其他人程序的内部部分（这被称为“结构化编程”）。
对象使您可以轻松地做正确的事。 继承和多态性没什么好处。
了解对象的一种方法是阅读其他人的代码。 通过阅读Delphi VCL框架的源代码，我学到了很多东西。 即使只是查看 Java 文档也能帮助您了解单个对象类应该做什么以及如何设计它以供其他对象使用。
开始一个你自己的项目，当你想要对你自己的类进行子类化时，你会发现你必须返回并分解一些受保护的方法，这样你就可以只重写进程的一部分，而不是替换它的全部，请注意。 了解祖先如何通过调用抽象函数与后代通信。 换句话说，犯很多错误并从中吸取教训。
享受！
My OOP epiphany came from Grady Booch's book, way long time ago. Suddenly I realized why objects were good.
While polymorphism is cool, encapsulation is 75% of why objects are cool. It is sort of like an interface: you see the buttons but not the wiring. Before objects, only the most disciplined coders kept their grubby fingers off the internal bits of other people's procedures (it was called "structured programming").
Object make it easy to Do the Right Thing. Inheritance and polymorphism are little bonuses.
One way to learn about objects is to read other peoples' code. I learned a lot by reading the source code for the Delphi VCL framework. Even just looking at the documentation for Java will help you see what a single object class should do and how it is designed to be used by other objects.
Start a project of your own and pay attention when you want to sub-class your own classes and find that you have to go back and break up some protected methods so you can override just one piece of a process instead of replacing all of it. See how ancestors talk to descendants by calling abstract functions. In other words, go make a lot of mistakes and learn from them.
Enjoy!
坦率地说，重读大卫·帕纳斯关于信息隐藏的旧论文可以帮助我进入正确的心态。 这些案例研究可能并不直接适用，但您应该能够从中得到一些有用的概括。
Frankly, re-reading old David Parnas papers on information hiding helps me get in the right state of mind. The case studies may not be directly applicable but you should be able to get some useful generalizations out of them.
当我尝试在 VB6 中实现一个非常面向对象的问题（动态和递归地构建 SQL 语句）时，我顿悟了。 理解多态性或继承的最好方法是需要它但不能使用它。
My epiphany happened when I tried to implement a very OO problem (dynamically and recursively building SQL statements) in VB6. The best way to understand polymorphism or inheritance is to need it and not be able to use it.
肯定会对您有所帮助的一件事是致力于一个众所周知的、受人尊敬的开源项目。 要么深入研究源代码，看看事情是如何完成的，要么尝试进行一些添加/修改。 您会发现大多数问题都没有一种风格或正确的答案，但是通过查看多个项目，您将能够对如何完成事情有一个广泛的了解。 从那里，您将开始发展自己的风格，并希望在此过程中为开源做出一些贡献。
One thing that will definitely help you is working on a well-known, respected open source project. Either dig through the source code and see how things are done or try to make some additions / modifications. You'll find that there isn't one style or one right answer for most problems, but by looking at several projects, you'll be able to get a wide view of how things can be done. From there, you'll begin to develop your own style and will hopefully make some contributions to open source in the process.
我认为你必须尝试实施面向对象的解决方案并失败。 无论如何，我就是这么做的。 我所说的失败是指你最终在成功交付可行的解决方案的同时编写了臭代码。 写完之后你就会感觉到哪里不太对劲。 您可能会有一些顿悟，并且/或者您可能会从其他程序员那里寻找更灵活的解决方案。 毫无疑问，您会意外地实现标准设计模式的某些变体。 事后看来，一盏灯会亮起（哦！这就是访客的目的），然后理解就会加速。
正如其他人所说，我认为通过一些优秀的 OO 开源代码进行工具化是一个好主意。 与更有经验的程序员一起工作也是如此，他们愿意批评你的工作。 然而，理解是通过实践而来的。
I think you have to attempt and fail at implementing OO solutions. That's how I did it anyway. What I mean by fail is that you end up writing smelly code while successfully delivering a working solution. After it's written you'll get a feel for where things didn't quite feel right. You may have some epiphanies, and/or you may go and hunt for a slicker solution from other programmers. Undoubtedly you'll implement some variation of standard design patterns by accident. In hindsight, a light will click on (oh! so that's what a visitor is for), and then understanding will accelerate.
As others have said, I think tooling through some good OO open source code is a good idea. So is working with more experienced programmers who would be willing to critique your work. However understanding comes through doing.
您可能想尝试阅读（和编写）一些 Smalltalk 一段时间。 Squeak 是一个免费的实现，可以向您展示完全面向对象环境的强大功能（与 java 或 .net 不同）。 包含所有库代码源。 语言本身非常简单。 您会发现 java 和 c# 正在慢慢添加自 1980 年以来为 Smalltalk 所熟知的功能。
You might want to try to read (and write) some Smalltalk for a while. Squeak is a free implementation that can show you the power of a fully object-oriented environment (unlike java or .net). All library code source is included. The language itself is incredibly simple. You'll find that java and c# are slowly adding the features well-known to Smalltalk since 1980.
Tortoise HG 是一款设计精良的 OO 开源软件（用 Python 编写）。
如果您已经了解基础知识，那么使用完全面向对象的语言从头开始构建一些东西将是完全理解 OOP 软件架构的良好一步。 如果您不懂 Python，Python 基本参考将带您了解几天到一周内即可完整掌握语言。
当你理解了这门语言之后，再看看上面的软件，你就会有各种顿悟。
Tortoise HG is extrodanarily well designed piece of OO open source software (written in Python).
If you already understand the basics, building something from scratch in a fully object oriented language will be a good step in fully understanding OOP software architecture. If you don't know Python, Python Essential Reference will take you through the language in full in a few days to a week.
After you understand the language take a look through the software above and you'll have all sorts of epiphanies.