Question

我最近一直在阅读很多关于设计模式的内容，其中一些可以让我们的生活变得更轻松，其中一些似乎只会让事情复杂化（至少对我来说是这样）。我很想知道每个人都认为什么样的设计模式被淹没或被低估了。有些模式很简单，许多人甚至没有意识到他们正在使用模式（装饰器可能是最常用的，没有实现）。我的目标是让模式新手对一些更复杂或未知的模式以及我们应该使用它们的原因有所了解。

Answer 1

新手最重要的“模式”是

保持简单。
了解为什么据说好的做法是好的，所以你可以判断它们是否适合特定情况。
您必须平衡针对某种情况的竞争关注，而不仅仅是想一个。（解除v。凝聚力，测试健全性，完善性，良好做法，时间）

对于带有很酷名称的正式模式，我认为审查关注接口的模式是有帮助的，因为帮助让你思考依赖关系和契约，而不仅仅是对象。或者正如鲍勃叔叔（马丁）所说，取决于抽象，而不是结核。所以我的回答是：

Dependency Injection
（在较小程度上facade，decorator，adapter）

请参阅Dependency Inversion Principal，其中一个SOLID Principals，（我相信您已经分析过了）。狭隘地看，DI is very simple虽然它经常变得过于复杂。我认为在更广泛的背景下观察它是很重要的，这是一种思考每个级别和部分设计的方式，而不仅仅是以某种方式排列的代码。

一句警告。我认为一些模式新手对模式过于热心，并且认为代码不好，除非它实现模式，并且模式使解决方案变得更好。他们有时关注模式而不利于其他良好的OOP / D实践。这是个错误。固先生自己explains this here。

Answer 2

更少的代码是更好的代码。

Answer 3

我是monte carlo单元测试的忠实粉丝。许多非常复杂，高效的算法极难测试，因为有许多不同的代码路径和边缘条件。如果存在一个与复杂算法完全相同的天真算法，或者甚至只是做出不同权衡的算法（如哈希表与平衡树），您只需生成大量随机输入，将其输入到天真有效的算法，并确保结果匹配。我发现了大量奇怪的边缘案例错误，否则几乎不可能找到。

Answer 4

我前几天实施了策略模式，它用于封装方法，而不是在运行时交换。有点像命令模式，但更多的是解耦。

这就是我使用它的方式。我不得不向第三方发送文件，我有几个选项可供选择，我有FTP，SFTP，FTPS和SMB。

接口：

interface ITransferStrategry
{
    void TransferFiles(System.Collections.Generic.IList<string> files);
}

实现：

public class FTPTransfer : ITransferStrategry
{

    public void TransferFiles(IList<string> files)
    {
        // Transfer to FTP Code Here
    }

}

上下文：

public class TransferContext
{

    private ITransferStrategry _strategy;

    public TransferContext(ITransferStrategry strategy)
    {
        this._strategy = strategy;
    }

    public void Send(IList<string> files)
    {
        this._strategy.TransferFiles(files);
    }

}

客户端：

public void Client()
{
   TransferContext context = new TransferContext(new FTPTransfer());
   context.Send(files);
}

它非常简单易维护。希望这对任何人都有帮助。

Answer 5

常识和效率可以取代所有设计模式。

编辑：看到评论者没有明白我的观点......

我想说的是，不是记住所有的设计模式，而是用这些术语思考，你可以暂时反思问题并以高效优雅的方式解决问题，这是基于常识和你的经验。很有可能，你会想到的将是这些设计模式中的一个或多个。但是为了使用它们，您不需要事先知道它们。无论如何，我永远无法记住那些20多个模式的名字并记住每个名字所代表的心理联想。

Answer 6

的余额

我的意思是，有各种各样的模式和指导方针，但都可能过度使用，从而产生反模式效果。

关于什么以及如何应用已知实践的经验来自您撰写的每一行，您与其他编码人员的每次讨论以及来自思考的人的每篇阅读不同。

Answer 7

最缺乏使用的设计模式是....所有这些。如前所述，许多使用设计模式的人没有正确地利用其优缺点。我也发现“为什么如此关注模式的具体细节？我不需要知道名字”这个论点被越来越多的人所抛弃，但这些都远远超过那些没有利用或思考的人。关于设计模式。

Y-Combinator刚刚将此链接发布到计算机科学免费大学讲座页面 - http://lecturefox.com/computerscience/ - 许多高级主题，但没有一个关于OOP或设计模式的主题。

Answer 8

头等功能。

什么是最未充分利用或未被充分认可的设计模式？

8 个答案:

的余额