我已经研究 OOP 很长一段时间了，我对这个理论有了很好的掌握。我阅读了关于 OOP 的Head First 一书，虽然它强化了很多理论，但我发现案例研究有些琐碎。
我发现我每天都在将 OOP 原则应用到我的代码中，但我不确定我是否正确应用了它们。我需要达到能够查看我的代码并知道我是否正确使用继承，我的对象是否足够内聚等等的地步。
有没有人有任何好的建议（书籍、在线指南、博客、演练等），以帮助您在下一步发展扎实的 OOP 技能？
我主要在 .NET（Visual Basic）中工作，但我欢迎包含各种平台的建议。
阅读Martin Fowler 的Refactoring，并将其应用到您自己的工作中。
它将带您了解软件代码的一系列恶臭特征，这些特征描述了如何检测不正确构造的类，更重要的是，如何修复它们。
考虑研究设计模式。尽管它们似乎在企业应用程序中并不常用（我已经看到它们在 API 和框架中比嵌入到企业代码中更常用），但它们可以在很多情况下用于使软件更简单或更健壮，如果只有开发人员知道如何应用它们。
关键是首先要了解设计模式，然后通过经验学习如何应用它们。
有一本关于设计模式的 Head First 书籍，它非常简单地教授了这个概念，但如果你想要一本真正详细介绍设计模式的书，请查看Gang of Four design patterns book，这基本上是使设计模式成为主流的原因，并且是几乎每次提起这个话题都会提到。
设计模式可以在某种程度上应用于几乎任何面向对象的语言中，尽管在某些情况下某些模式可能是矫枉过正或过度工程化。
编辑：
我还想补充一点，你应该看看这本书Code Complete 2。在软件开发领域，这是一本非常有影响力的书。它涵盖了许多不同的概念和理论。每次阅读它，我都会学到一些新东西。这是一本非常好的书，如果我每 6 个月到一年读一次，我会从不同的角度来看待它，只要重新阅读它，我就会成为一个更好的程序员。无论你认为自己知道多少，这本书都会让你意识到你真正知道的有多么少。这真的是一本很棒的书。我不能强调你应该拥有这本书多少。
如果您已经具备基础知识，我相信只有经验才能让您走得更远。你说你不确定你是否正确地应用了这些原则，但没有一种正确的方法。您今天编写的代码，您将在 6 个月后查看，并想知道为什么要这样写，并且可能知道更好、更清洁的方法。我还保证，10 年后，你仍然会学习新的技术和技巧。不要太担心它，它会来的，尽可能多地阅读，并尝试将你所阅读的内容分成小块应用。
我目前正在阅读以下书的一半：
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062
在深入研究代码之前，我不能强烈推荐这本书，因为它可以学习一种真实的、专业级的、实用的方法来起草和应用格式良好的迭代设计策略。
我也读了“ Head First ”这本书，觉得读了它我感觉好多了。
在拥有几年的工作世界经验之后，我现在查看了我推荐的 Craig Larman 书，这本书对我来说是完美的“下一步”。
无论您对 UML 表示法有积极的感受还是消极的感受，请不要让它影响您购买这本书 (ISBN 0131489062) 的决定。
标题中突出显示“UML”具有误导性。虽然作者确实使用并解释了 UML 符号，但这些解释非常好地融入了相关的设计讨论中，而且本书在任何时候读起来都不像一个无聊的 UML 规范。
事实上，这是直接从书中摘录的一段话：
重要的是知道如何在对象中思考和设计，这是一项与了解 UML 符号非常不同且更有价值的技能。在绘制图表时，我们需要回答关键问题：对象的职责是什么？它与谁合作？应该应用哪些设计模式？远比了解 UML 1.4 和 2.0 之间的区别更重要！
这本书有时看起来像是在与首席架构师或项目经理“交谈”。我的意思是，它假定读者对软件项目的规划和方向有很大的控制权。
尽管如此，即使您只负责公司的一小部分项目和产品，我仍然会推荐这本书，并鼓励您将本书建议的一些“缩小”修改应用到您的项目中。
我的 OOP 顿悟来自很久以前 Grady Booch 的书。突然我意识到为什么物体是好的。
虽然多态性很酷，但封装是对象很酷的 75%。它有点像一个界面：你看到的是按钮，但看不到接线。在对象出现之前，只有最自律的编码人员才会让他们肮脏的手指远离其他人程序的内部部分（这被称为“结构化编程”）。
对象使做正确的事变得容易。继承和多态性是很少的好处。
了解对象的一种方法是阅读其他人的代码。通过阅读 Delphi VCL 框架的源代码，我学到了很多东西。即使只是查看 Java 的文档也可以帮助您了解单个对象类应该做什么以及它是如何设计为供其他对象使用的。
开始一个你自己的项目，当你想对你自己的类进行子类化并发现你必须返回并分解一些受保护的方法时要注意，这样你就可以只覆盖一个过程而不是全部替换它。看看祖先如何通过调用抽象函数与后代对话。换句话说，去犯很多错误并从中吸取教训。
享受！
坦率地说，重新阅读有关信息隐藏的旧 David Parnas 论文有助于我保持正确的心态。案例研究可能不直接适用，但您应该能够从中获得一些有用的概括。
当我试图在 VB6 中实现一个非常 OO 的问题（动态和递归地构建 SQL 语句）时，我顿悟了。理解多态性或继承的最好方法是需要它而不能使用它。
肯定会帮助您的一件事是从事一个著名的、受人尊敬的开源项目。要么挖掘源代码，看看事情是如何完成的，要么尝试做一些添加/修改。您会发现对于大多数问题没有一种风格或一种正确答案，但是通过查看几个项目，您将能够对如何完成事情有一个广泛的了解。从那里开始，您将开始发展自己的风格，并希望在此过程中为开源做出一些贡献。
我认为您必须尝试实施 OO 解决方案并失败。反正我就是这样做的。我所说的失败是指你最终编写了臭代码，同时成功地交付了一个可行的解决方案。写完之后，您会感觉到事情不太对劲。您可能会有一些顿悟，和/或您可能会去寻找其他程序员的更巧妙的解决方案。毫无疑问，您会意外地实现标准设计模式的一些变体。事后看来，一盏灯会亮起（哦！这就是访客的目的），然后理解就会加速。
正如其他人所说，我认为通过一些好的 OO 开源代码工具是一个好主意。与愿意批评您的工作的更有经验的程序员一起工作也是如此。然而，理解来自于实践。
您可能想尝试阅读（和编写）一些 Smalltalk 一段时间。Squeak 是一个免费的实现，它可以向您展示完全面向对象的环境（与 java 或 .net 不同）的强大功能。包括所有库代码源。语言本身非常简单。您会发现，自 1980 年以来，java 和 c# 正在慢慢添加 Smalltalk 众所周知的功能。
Tortoise HG是一款设计精美的 OO 开源软件（用 Python 编写）。
如果您已经了解基础知识，那么使用完全面向对象的语言从头开始构建将是充分理解 OOP 软件架构的良好一步。如果您不了解 Python，Python Essential Reference 将在几天到一周内带您完整了解该语言。
在你理解了语言之后，看看上面的软件，你会有各种各样的顿悟。
要彻底理解任何事情，您需要对至少一个抽象级别以上和以下一个级别有相当的了解。在 OO 的情况下，其他人提到设计模式是 OO 之上的层。这有助于说明为什么 OO 是有用的。
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.