我似乎经常遇到一些设计问题，但我不知道是什么是真的很合适。一方面我经常听到我应该限制耦合和坚持单一职责，但当我这样做时，我常常发现它很困难到在需要时将信息获取到程序的一部分。为了例如，classSingerdefinitialize(name)@name=nameendattr:nameend那么Song应该是:classSongdefnew(singer)@singer=singerendend或classSongdefnew(singer_name)@singer_name=singer_nameendend后者耦合性小，按道理应该用。但如果我以后发现宋有什么需要了解更多歌手，我的
方法调用通常可以省略接收者和参数的括号:deffoo;"foo"endfoo#=>"foo"在上面的例子中，foo在方法调用和对潜在局部变量的引用之间是不明确的。在没有后者的情况下，它被解释为方法调用。但是，当方法名原则上可以是常量名时(即，当它以大写字母开头，并且仅由字母组成时)，似乎需要消歧。defFoo;"Foo"endFoo#=>NameError:uninitializedconstantFooFoo()#=>"Foo"self.Foo#=>"Foo"为什么会这样？为什么即使在没有同名常量的情况下，也需要明确区分方法调用和对常量的引用？ 最佳答案
我是RubyonRails的新手，我阅读了这些文章。DesignPatternsinRuby:Observer,SingletonDesignPatternsinRuby但我无法理解设计模式和设计原则之间的实际区别。有人可以解释一下区别吗？ 最佳答案 设计原则:设计原则是我们在设计软件时应该遵循的核心抽象原则。记住它们不是具体的——而是抽象的。只要我们在允许的条件内，它们就可以以任何语言、任何平台应用，无论处于何种状态。例子:封装变化的内容。针对接口(interface)而非实现编程。依赖抽象。不要依赖于具体的类。设计模式:它们是针
在一些个人项目中，我正在慢慢地从PHP5转向Python，目前我很喜欢这种体验。在选择走Python路线之前，我查看了Ruby。我从ruby社区注意到的是猴子修补既常见又受到高度重视。我还遇到了很多关于调试ruby软件试验的恐怖故事，因为有人包含了一个相对无害的库来做一些小工作，但却在没有告诉任何人的情况下修补了一些频繁使用的核心对象。我选择Python是因为(除其他原因外)它的语法更清晰，而且它可以完成Ruby可以做的一切。Python使OO的点击比PHP以往任何时候都好得多，而且我正在阅读越来越多的OO原则，以加深这种更好的理解。今晚我一直在阅读关于RobertMartin
谁能帮忙说明一下Dependencyinversionprinciple在JavaScriptjQuery中？这将突出并解释这两点:一个。高层模块不应该依赖于低层模块。两者都应该依赖于抽象。B.抽象不应依赖于细节。细节应该取决于抽象。什么是抽象或高级/低级模块？这对我的理解很有帮助，谢谢! 最佳答案 我想说DIP在JavaScript中的应用方式与它在大多数编程语言中的应用方式大致相同，但您必须了解鸭子类型的作用。让我们举个例子看看我的意思...假设我想联系服务器获取一些数据。如果不应用DIP，这可能看起来像:$.get("/add
在这本书中:ReginaObe和LeoHsu，PostgreSQL启动与运行，p.101。它是作为对PostgreSQLXML数据类型的介绍而编写的:TheXMLdatatype,similartoJSON,is“controversial”inarelationaldatabasebecauseitviolatesprinciplesofnormalization.没有进一步的解释。有人可以详细说明什么是规范化原则以及为什么XML确实违反了其中一些原则。 最佳答案 关系模型是一阶逻辑模型，这意味着我们谓词中的变量只能包含值。值之间
我们有一个产品，每个客户都有一个XML配置文件，其中包含多组UI选项和子选项。例如，一种类型的用户(称他们为A)有一组选项，而另一种类型的用户(称他们为B)有一组不同的选项。我遇到的问题是A和B共享大部分选项，尽管有时当他们共享一个选项时，一个或多个子选项不同。现在，我们让客户拥有30种类型的用户，而不是两种类型的用户，并且该客户的配置文件因相同的信息重复多达30次而变得臃肿，这给开发带来了维护噩梦。在这种情况下，您会推荐哪些方法来应用DRY原则？ 最佳答案 您需要实现一种继承形式，就像面向对象编程语言或CSS中的继承一样，您从一组
LSP说“派生类型不能改rebase类型的行为”，换句话说“派生类型必须完全可以替换它们的基类型”。这意味着如果我们在基类中定义虚方法，我们就违反了这个原则。另外，如果我们使用new关键字在驱动方法中隐藏一个方法，那么我们又违反了这个原则。换句话说，如果我们使用多态性，我们就违反了LSP!在许多应用程序中，我在基类中使用了虚拟方法，现在我意识到它违反了LSP。另外，如果你使用模板方法模式，你就违反了我经常使用它的原则。那么，当您需要继承并且还希望从多态性中获益时，如何设计符合此原则的应用程序呢？我很困惑!请参阅此处的示例:http://www.oodesign.com/liskov-s
当我遇到以下代码时，我正在重构一些简单脚本文件解析器的旧代码:StringReaderreader=newStringReader(scriptTextToProcess);StringBuilderscope=newStringBuilder();stringline=reader.ReadLine();while(line!=null){switch(line[0]){case'$'://Processtheentire"line"asavariable,//i.e.addittoacollectionofKeyValuePair.AddToVariables(line);brea
在我们的C#MVC应用程序中，我们有很多接口(interface)与实现它们的对象一对一映射。即:基本上，对于创建的每个对象，都执行了“提取接口(interface)”操作。Moq使用这些接口(interface)为我们的单元测试生成模拟对象。但那是唯一一次重新使用接口(interface)。我们系统中没有具体对象实现多个接口(interface)。谁能告诉我这是否会在以后造成问题？如果是这样，它们会是什么？我在想，我们的应用程序有很多重复，例如在这两个接口(interface)中(编辑:在我们的服务层中)唯一不同的是方法名称和它们采用的参数类型，但是从语义上讲，他们对发送消息的存储库
