在OO中设计时

Question

..你从哪里开始？

作为任何设计的基础 - 例如包 - 您作为开发人员从哪里开始。

我首先绘制需求并将其分解为子类别以及此对象和方法。

通常需要一段时间才开始手工绘制 - 然后通过几个版本。但我总是有潜在的感觉，我永远不会完成，它可能会更好。我怎么能克服这个？

一旦我有自己的设计理念，我就不知道如何将设计模式融入其中。

为OO设计花费了多少时间？ （显然这取决于手头的项目）

Answer 1

关于你以某种方式可以做得更好的感觉 - 你永远不会克服这一点，你不应该尝试，因为这基本上告诉你，你对自己的工作至关重要，并且你愿意学习/提高自己。这是您作为开发人员最有价值的资源......

托马斯

Answer 2

我喜欢向新程序员解释它的方式，在我开始时帮助我的方法是首先在一些简单问题陈述中识别所有形容词，动词和名词分类。从名词中你可以找出适合上课的东西。从形容词中你可以识别出能够成为成员变量的最佳候选者，最后从动词中识别潜在的方法。

在过去，我建议通过以不同的颜色强调/突出显示每一个来做到这一点。您还可以在这样的用例中识别actor。

显然，这对所有问题都不起作用，并且很容易构成一些不合理的简单示例，但从设计一组类的起点开始，我发现它是一种有用的思考方式

插入设计模式通常会在此后的阶段发生，通常对我来说至少这是一个发现某种问题的问题，并且只是知道（从内存中，例如撤消/重做的命令模式）或者看到解决方案你正在考虑的是与之前见过的其他东西类似的东西。

Answer 3

取决于：有两个主流。

• 创建一个大型架构，包含大量接口和抽象类（例如readUserInput（））
• 创建您需要的内容（更多AGILE方法，请参阅KISS Principle）

如果您选择第二个，您将领导改进您已完成的工作，然后抽象您的图层。那里你将开始内在，所以DRY。

事实上，我们有时想要为非常小的需求创造出非常棒的东西。我喜欢第二个。希望这有助于，至少一点点。

Answer 4

  

但我总是有潜在的感觉，我永远不会完成，它可能会更好。

这很好，因为在实践中设计很少完成（或严格意义上的最佳）并且几乎总是可以使其更好。在某些时候你只需要写东西。注意让您感到头痛的部件感觉笨拙，太复杂而无法维护。这些是必须更好地设计的东西。准备好反复重写代码，因为好的设计和优秀代码的关键是迭代。没有人在第一次尝试时写出完美的代码。

这一切都让人觉得很抽象，因为对于所有情况都毫无例外地提出了很少的建议。例如，一个基本规则是保持代码简单，但泛化有时会有很大帮助，即使它在开始时看起来更复杂。最后，这通常是一个平衡问题。

考虑设计一段时间，然后编写代码。寻找错误的地方，从第一步开始重复。没有银弹。

Answer 5

设计可以说是开发过程中最重要的一步。你拥有的目标越少，就越有可能将所有东西都撕掉并重新开始。当你进行设计时，设计模式应该自然地流入你正在创建的东西中，而你正在创建它。

但最重要的部分是首先勾勒出你想要的东西，然后指出你需要什么才能到达那里。花点时间，因为设计阶段很重要。

互联网上的OO设计有大量资源可以提供帮助，因为我们显然无法为您编写OO设计书。祝你好运，编码愉快。

Answer 6

这更像是一个信心问题。这是正常的 - 这个东西很难。编程要求完美和预知要做到最好，据我所知，没有人类的成员有这个。

我一直在努力提高我以OO方式设计某些东西的能力（虽然在C ++中，但许多相同的原则适用于其他OO语言），这是我采取的步骤：

• 也许花点时间习惯重构的想法/方法。重构是一个想法，'你可以改变OO设计，如果它不正确，或者让它变得更好。'真的，你可以 - 这意味着如果你搞砸了，你可以回去修理它。关于重构的书籍谈论了使这更容易的技术。我发现阅读那本书帮助我意识到有办法解决你所犯的错误，我发现它减轻了我的设计恐惧。这并不意味着你做了一个糟糕的设计，但它确实意味着你有一点安全网，你可以回去修复它。 你只能尽力设计，而不是更多。 所以如果你不得不回去修理它，请不要担心。
• 罗伯特·马丁关于面向对象设计的书籍/着作是我发现有用的东西。我一直在阅读他的使用Booch方法设计面向对象的C ++应用程序一书，虽然它已经老了，但它还是通过一个非常有条理的，逐步地设计复杂的OO系统的案例研究。走开。我发现，他的新书在这方面也很有用，但往往以更简洁的方式呈现相同的材料。
• 与同事合作，改进面向对象设计的想法。

Answer 7

我可以建议Peter Coad的Java Design作为做OO / Java设计的好指南吗？ 重量和严谨的东西：http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062/ref=sr_1_1?s=books&ie=UTF8&qid=1288364561&sr=1-1

至于从Reqs开始 - 我建议编写简要用例并将reqs绑定到它们，以便reqs在上下文中。

Answer 8

您问题的另一个答案可能是：从测试开始。围绕“测试驱动开发”有很多想法和讨论，我喜欢Scott Ambler的论点：

如果值得建设，值得测试。

如果这种方法听起来很有趣，请参阅Martin Fowler's brief intro或Scott Ambler的较长文章（www.agiledata.org/essays/tdd.html）作为开头。很好的设计帮助了我很多。