Questions tagged «design-patterns»

查找脚本的常见模式遵循以下脚本： 观察奇怪的地方，例如没有输出或挂起的程序。 在日志或程序输出中找到相关消息，例如“找不到Foo”。（以下内容仅在找到错误所在的路径时才有意义。如果堆栈跟踪或其他调试信息容易获得，则是另一回事了。） 找到打印消息的代码。 调试Foo输入（或应该输入）图片到消息打印的第一处之间的代码。 第三步是调试过程经常停止的地方，因为在代码中有很多地方Could not find {name}都打印了“找不到Foo”（或模板字符串）。实际上，几次拼写错误使我找到实际位置的速度比我原本要快得多-它使消息在整个系统中（通常在整个世界）都是唯一的，从而导致相关搜索引擎立即受到攻击。 由此得出的明显结论是，我们应该在代码中使用全局唯一的消息ID，将其作为消息字符串的一部分进行硬编码，并可能验证代码库中每个ID仅出现一次。在可维护性方面，该社区认为此方法最重要的利弊是什么，您将如何实施此方法或以其他方式确保永远不必实施它（假设该软件将始终存在错误）？

39 design-patterns  logging  error-messages 

我应该在何处放置与类无关的函数这个问题引发了一些争论，即在C ++中将实用程序函数组合到类中是否有意义或者只是将它们作为自由函数存在于命名空间中。 我来自C＃背景，后者不存在该选项，因此自然倾向于在我编写的C ++小代码中使用静态类。该问题的最高投票答案以及一些评论都说，自由函数是首选，甚至暗示静态类是反模式。为什么在C ++中会这样？至少从表面上看，类上的静态方法似乎与命名空间中的自由函数没有区别。为什么要选择后者呢？ 如果实用程序功能的集合需要一些共享数据，例如可以将其存储在私有静态字段中的缓存，情况会有所不同吗？

39 c++  design-patterns  anti-patterns 

习惯用语和设计模式有什么区别？这些术语似乎在某处重叠。确切地，我不知道。它们可以互换吗？我什么时候应该使用什么？ 这是C ++习语的列表。我可以称它们为设计模式吗？ 维基百科定义 将成语编程为低级设计模式 这是什么意思？什么是“低层次”的意思是在这里吗？ 这个问题的灵感来自另一个问题：https : //stackoverflow.com/questions/7343531/are-the-some-design-patterns-language-dependent

39 design-patterns  terminology  idioms 

有时，我们的应用程序的控制器代码中表示了一些业务逻辑。通常，这是区分从模型调用什么方法和/或传递它们的参数的逻辑。 另一个示例是控制器中存在的一组实用程序功能，这些功能可以根据一组业务规则来格式化或清除从模型返回的数据。 这行得通，但我想知道它是否在灾难中调情。如果控制器和模型之间共享业务逻辑，则这两层将不再可分离，并且继承代码的人员可能会因与业务逻辑相关的代码位置不均匀而感到困惑。 我的问题是，控制器中应允许多少业务逻辑，以及在什么情况下（如果有）？

39 design-patterns  mvc 

我仍在寻找域模型验证的最佳实践。将验证放入域模型的构造函数中好吗？我的域模型验证示例如下： public class Order { private readonly List<OrderLine> _lineItems; public virtual Customer Customer { get; private set; } public virtual DateTime OrderDate { get; private set; } public virtual decimal OrderTotal { get; private set; } public Order (Customer customer) { if (customer == null) throw new ArgumentException("Customer name must …

38 design-patterns  domain-driven-design  validation 

我当时正在与一位同事进行讨论，但最终我们对继承的目的产生了矛盾的直觉。我的直觉是，如果子类的主要功能是表达其父级的可能值的有限范围，则它可能不应该是子类。他主张相反的直觉：子类化表示对象的“特定性”更高，因此子类关系更合适。 更具体地讲，我认为如果我有一个扩展父类的子类，但是该子类覆盖的唯一代码是构造函数（是的，我知道构造函数通常不会“重写”，请耐心等待），然后真正需要的是一种辅助方法。 例如，考虑一下这个现实生活的类： public class DataHelperBuilder { public string DatabaseEngine { get; set; } public string ConnectionString { get; set; } public DataHelperBuilder(string databaseEngine, string connectionString) { DatabaseEngine = databaseEngine; ConnectionString = connectionString; } // Other optional "DataHelper" configuration settings omitted public DataHelper CreateDataHelper() { Type dataHelperType = DatabaseEngineTypeHelper.GetType(DatabaseEngine); DataHelper …

37 design-patterns  object-oriented  inheritance  anti-patterns 

任何面向对象的程序都有可想像的设计模式吗？我之所以这么问，是因为最近我看到了带有的Door类的实现Lock。这是测试的一部分，回答说代码遵循Null Object模式： class Lock { public: virtual void close() = 0; virtual void open() = 0; virtual bool is_open() const = 0; virtual ~Lock() { } }; class DummyLock : public Lock { private: DummyLock(); DummyLock(const DummyLock&) = delete; DummyLock& operator=(const DummyLock&) = delete; private: void close() { } void …

37 design  design-patterns  object-oriented  object-oriented-design 

根据Microsoft文档，有关Wikipedia SOLID原则的文章或大多数IT架构师，我们必须确保每个班级仅负一个责任。我想知道为什么，因为如果每个人似乎都同意这条规则，那么似乎没人会同意这条规则的原因。 一些人引用了更好的维护，有人说它提供了简单的测试，或者使类更加健壮或安全。什么是正确的，实际上是什么意思？为什么它可以使维护更好，测试更容易或代码更健壮？

37 design-patterns  architecture  solid  single-responsibility 

我了解模型和视图在“模型－视图－控制器”模式中的作用，但是我很难理解为什么需要控制器。 假设我们正在使用MVC方法创建国际象棋程序；游戏状态应该是模型，GUI应该是视图。在这种情况下，控制器究竟是什么？ 它是否只是一个单独的类，具有在您单击图块时将要调用的所有功能？为什么不只在视图本身中对模型执行所有逻辑？

37 design-patterns  mvc 

为什么在依赖注入模式不是在incluided 四人帮？GOF是否早于广泛的自动化测试？现在依赖注入被视为核心模式吗？

37 design-patterns 

我看到的一个常见模式就是所谓的Mapper模式（不要与之DataMapper完全混淆），它以某种“原始”数据源（例如ADO.NET DataReader或DataSet）作为参数，并将字段映射到业务/域对象上的属性。例： class PersonMapper { public Person Map(DataSet ds) { Person p = new Person(); p.FirstName = ds.Tables[0].Rows[0]["FirstName"].ToString(); // other properties... return p; } } 这个想法是您的Gateway / DAO / Repository / etc。将在Mapper返回之前调用它，因此您将获得一个丰富的业务对象与基础数据容器。 但是，这似乎与工厂模式有关（即使不完全相同），工厂模式会构造并返回域对象。维基百科说这是：DDD工厂： 工厂：用于创建域对象的方法应委托给专门的工厂对象，以便可以轻松地互换替代实现。 从该引用中，我唯一想到的区别是可以对DDD样式的工厂进行参数化，以便在需要将“映射器”键入特定类的情况下，如果需要的话可以返回一种特殊类型的对象（例如BusinessCustomer与ResidentialCustomer）。并且只翻译。 那么这两种模式之间是否存在差异，或者它们本质上是相同的东西却具有不同的名称？

37 design-patterns 

当我开始一个新项目时，我经常会立即开始考虑实现的细节。“我要在哪里放置DataBaseHandler？我应该如何使用它？要使用它的类应该从某些Abstract超类中扩展。发送请求和解析数据的方法？” 我最终停滞了很长时间，因为我想为可扩展性和可重用性编写代码。但是我觉得几乎不可能过去思考如何实现完美。 然后，如果我只想说“拧紧它，就完成它！”，我很快就会碰壁，因为我的代码没有组织好，混合了抽象级别，等等。 您有什么技术/方法来启动一个新项目，同时建立一个可以很好地扩展的逻辑/模块化结构？ - -编辑- - 好吧，这已经是很难接受答案的问题类型了，但是希望获得更多反馈，看看是否有共识。TDD听起来真的很酷，坦率地说，我一直在意欲加快使用JUnit等的速度。与此同时，TDD的拥护者如何看待这一事实，即与TDD有关的合理点解决了我的问题？特别的问题是，TDD似乎并没有真正解决设计问题。当然，我同意TDD将帮助我定义我想做什么，然后我可以逐步研究如何做，但是有许多不同的总体设计模式/结构可以全部通过单元测试。就是这样：它测试单个UNITS。我想我有点困惑...我不知道。也许我' 谢谢！

37 project-management  design-patterns  code-quality  paradigms  code-reuse 

在iOS上实施MVC模式时遇到问题。我已经搜索了Internet，但似乎找不到解决此问题的任何好方法。 许多UITableViewController实现似乎很大。我见过的大多数示例都允许UITableViewController工具<UITableViewDelegate>和<UITableViewDataSource>。这些实现UITableViewController是变大的一个重要原因。一种解决方案是创建实现<UITableViewDelegate>和的单独类<UITableViewDataSource>。当然，这些类必须参考UITableViewController。使用此解决方案是否有任何弊端？通常，我认为您应该使用委托模式将功能委托给其他“ Helper”类或类似类。是否有解决此问题的完善方法？ 我不希望模型包含太多功能，也不希望包含视图。我认为逻辑应该真正属于控制器类，因为这是MVC模式的基石之一。但是最大的问题是： 您应该如何将MVC实现的控制器划分为较小的可管理部分？（在这种情况下，适用于iOS中的MVC） 尽管我正在特别寻找iOS的解决方案，但可能会有解决此问题的一般模式。请举例说明解决此问题的好方法。请提供一个论点，为什么您的解决方案很棒。

36 design-patterns  mvc  ios  iphone  gui 

几年前，当面向对象编程的概念被介绍给程序员时，它看起来很有趣并且编程更加简洁。OOP就是这样 Stock stock = new Stock(); stock.addItem(item); stock.removeItem(item); 使用自描述名称更容易理解。 但是现在，具有数据传输对象，值对象，存储库，依赖注入等模式的OOP变得更加复杂。为了达到上述目的，您可能必须创建多个类（例如abstract，factory，DAO等）并实现多个接口 注意：我不反对使协作，测试和集成更容易的最佳实践

36 design-patterns  productivity  programming-practices  object-oriented-design 

随着Javascript在未来几年内将成为Web上无处不在的编程语言，每隔五分钟就会弹出新的框架，并且事件驱动的编程在服务器端和客户端均处于领先地位： 作为Java语言开发人员，您是否认为传统设计模式比其他语言/环境重要或重要？ 请命名您作为Javascript开发人员经常使用的前三种设计模式，并举例说明它们如何对您的Javascript开发有所帮助。

36 javascript  design-patterns  node.js