Questions tagged «design»

假设我有三个相关的资源，如下所示： Grandparent (collection) -> Parent (collection) -> and Child (collection) 上面这样描述了这些资源之间的关系：每个祖父母可以映射到一个或几个父母。每个父母可以映射到一个或几个孩子。我希望能够支持针对子资源的搜索，但具有过滤条件： 如果我的客户给我传递了一个祖父母的ID参考，那么我只想搜索是该祖父母的直接后代的孩子。 如果我的客户向我传递了对父母的ID引用，我只想搜索父母直接后代的孩子。 我想到过这样的事情： GET /myservice/api/v1/grandparents/{grandparentID}/parents/children?search={text} 和 GET /myservice/api/v1/parents/{parentID}/children?search={text} 分别满足上述要求。 但是我也可以这样做： GET /myservice/api/v1/children?search={text}&grandparentID={id}&parentID=${id} 在这种设计中，我可以允许我的客户端向我传递查询字符串中的一个或另一个：grandparentID或parentID，但不能两者都传递。 我的问题是： 1）哪种API设计更RESTful，为什么？在语义上，它们的含义和行为方式相同。URI中的最后一个资源是“子代”，有效地暗示客户端正在子代资源上运行。 2）从客户的角度看可理解性以及从设计者的角度看可维护性方面，每种方法的优缺点是什么。 3）除了对资源进行“过滤”外，查询字符串的真正用途是什么？如果采用第一种方法，则将filter参数作为路径参数而不是查询字符串参数嵌入到URI本身中。 谢谢！

73 design  rest  api 

《代码完整》一书附有以下引文： “将正常情况放在if而不是之后else” 这意味着在这种else情况下，应该放置与标准路径的异常/偏离。 但是，实用程序员教会我们“尽早崩溃”（第120页）。 我应该遵循哪一条规则？

73 design 

情境 目前，我是一个医疗保健项目的一部分，其主要要求是使用医疗保健提供者使用用户生成的表单来捕获属性未知的数据。第二个要求是数据完整性是关键，并且该应用程序将使用40年以上。我们目前正在将过去40年的客户数据从各种来源（纸张，Excel，Access等）迁移到数据库。将来的要求是： 表单的工作流程管理 表格进度管理 基于安全/角色的管理 报告引擎 手机/平板电脑支持 情况 在短短6个月的时间里，当前的（合同制）架构师/高级程序员采用了“快速”方法，并设计了一个较差的系统。由于他已经设计了一些bean来对数据库执行“删除”操作，所以数据库未规范化，代码已耦合，层没有专用目的，并且数据开始丢失。代码库极度膨胀，并且由于数据库未标准化，因此有些作业只是为了同步数据。他的方法一直是依靠备份作业来还原丢失的数据，并且似乎不相信重构。 将我的发现提交给项目经理之后，建筑师的合同结束后将被撤职。我已经获得了重新架构此应用程序的任务。我的团队由我和一名初级程序员组成。我们没有其他资源。我们已经获得了为期6个月的冻结要求，在此期间我们可以专注于重新构建该系统。 我建议使用像Drupal这样的CMS系统，但是由于客户组织的政策原因，该系统必须从头开始构建。 这是我第一次设计使用寿命超过40岁的系统。我只从事3-5年使用寿命的项目，所以这种情况非常新，但令人兴奋。 问题 哪些设计考虑因素将使系统更“面向未来”？ 应该向客户/ PM问什么问题，以使系统更“面向未来”？

73 design  architecture  project-management  web-applications 

以我的理解，该partial关键字什么也没有做，只是允许在几个源文件之间拆分一个类。除了代码组织之外，还有其他理由吗？我已经在生成的UI类中看到了它的用法。 似乎没有理由创建整个关键字。如果一个类足够大而需要多个文件，那么它可能做得太多。我以为您也许可以用它部分地定义一个类，供其他程序员在某个地方完成，但是最好创建一个抽象类。

72 c#  design  language-design 

我知道这个话题有点争议，互联网上有很多各种各样的文章/观点。不幸的是，他们中的大多数人都假设该人不知道NULL和空字符串之间的区别是什么。因此，他们通过联接/聚集讲述令人惊讶的结果的故事，并且通常会做一些更高级的SQL课程。这样，他们绝对会遗漏所有要点，因此对我毫无用处。因此，希望这个问题和所有答案将使话题向前发展。 假设我有一个包含个人信息（姓名，出生等）的表，其中的一列是具有varchar类型的电子邮件地址。我们假设由于某些原因，某些人可能不想提供电子邮件地址。将此类数据（不带电子邮件）插入表时，有两个可用的选择：将单元格设置为NULL或将其设置为空字符串（''）。让我们假设我知道选择一个解决方案而不是另一个解决方案的所有技术含义，并且可以为任何一种情况创建正确的SQL查询。问题是，即使两个值在技术层面上都不同，但在逻辑层面上却完全相同。看完NULL和”之后，我得出一个结论：我不知道那个人的电子邮件地址。也不管我怎么努力 我无法使用NULL或空字符串发送电子邮件，因此显然大多数SMTP服务器都同意我的逻辑。所以我倾向于在不知道该值的地方使用NULL，并认为空字符串是一件坏事。 经过与同事的激烈讨论，我提出了两个问题： 我是否假设使用空字符串作为未知值会导致数据库对事实“撒谎”，对吗？更准确地说：使用SQL关于什么是价值和什么不是价值的想法，我可能得出结论：我们拥有电子邮件地址，只是发现它不为空。但是后来，当尝试发送电子邮件时，我会得出一个矛盾的结论：不，我们没有电子邮件地址，@！＃$数据库一定在撒谎！ 是否有逻辑上的情况，其中空字符串”可以很好地承载重要信息（除了值和没有值），而通过其他任何方式（如附加列）进行存储都会很麻烦/效率低下。我见过很多帖子声称有时将空字符串与实数值和NULL一起使用是很好的，但是到目前为止，还没有看到一种合乎逻辑的方案（就SQL / DB设计而言）。 PS有些人会很想回答，这只是个人品味的问题。我不同意 对我来说，这是一个具有重大后果的设计决策。因此，我希望看到一些出于逻辑和/或技术原因而对此表示反对的答案。

72 design  database  sql  strings  null 

“抽象类”和“接口”是相似的概念，其中接口是两者中比较抽象的。一个区别因素是抽象类在需要时为派生类提供方法实现。但是，在C＃中，最近引入的扩展方法已减小了这种差异因素，该扩展方法使得可以为接口方法提供实现。另一个区别因素是，一个类只能继承一个抽象类（即没有多重继承），但可以实现多个接口。这使接口的限制更少，更加灵活。因此，在C＃中，什么时候应该使用抽象类而不是具有扩展方法的接口？ 接口+扩展方法模型的一个著名示例是LINQ，其中为IEnumerable通过多种扩展方法实现的任何类型提供了查询功能。

70 c#  design  interfaces  inheritance  abstract-class 

我从事编程已有两年了，在解决问题和创建中小型脚本方面通常都不错，但是，我通常不擅长以面向对象的方式设计大型程序。几个问题 最近，一位与我有着多年经验的同事正在研究一个问题。我在解决问题上的时间比他长，但是，他提出了一个更好的解决方案，最后我们将使用他的设计。这真的影响了我。我承认他的设计更好，但是我想提出一个和他一样好的设计。我什至正在考虑辞职。不知道为什么，但是突然之间，我感到有些压力，例如，大三学生会怎么看我等等？正常吗 还是我对此考虑太多了？ 我的工作涉及使用Python编程。我尝试阅读源代码，但是您认为我如何提高我的设计技能？我应该学习什么好书或软件吗？ 请赐教。非常感谢您的帮助。

69 design  skills  object-oriented-design 

在我制作的这款游戏中，我观看了Stuart Sierra的演讲“ 数据中的思考 ”，并将其中的一种想法作为设计原则。不同之处在于他在Clojure中工作，而我在JavaScript中工作。我发现我们的语言之间存在一些主要差异： Clojure是惯用的函数式编程 大多数状态是不可变的 我从幻灯片“一切都是地图”中汲取了灵感（从11分钟6秒到> 29分钟）。他说的一些话是： 每当您看到一个带有2-3个参数的函数时，就可以将其变成一个映射并仅将一个映射传入。这有很多优点： 您不必担心参数顺序 您不必担心任何其他信息。如果有多余的键，那不是我们真正关心的。它们只是流过而不会干扰。 您不必定义架构 与传递对象相反，没有数据隐藏。但是，他认为数据隐藏可能会导致问题并被高估： 性能 易于实施 通过网络或跨流程进行通信后，无论如何，都必须让双方都同意数据表示。如果仅处理数据，则可以跳过这额外的工作。 与我的问题最相关。这是29分钟的时间： “使您的功能可组合”。这是他用来解释概念的代码示例： ;; Bad (defn complex-process [] (let [a (get-component @global-state) b (subprocess-one a) c (subprocess-two a b) d (subprocess-three a b c)] (reset! global-state d))) ;; Good (defn complex-process [state] (-> state subprocess-one …

69 design  design-patterns  architecture  functional-programming 

在扩展Java集合框架的第一个实现过程中，我很惊讶地看到集合接口包含声明为可选方法的方法。如果不支持，则期望实现者抛出UnsupportedOperationExceptions。这立即让我感到震惊，因为它是糟糕的API设计选择。 在阅读了约书亚·布洛赫（Joshua Bloch）出色的“有效Java”（Effective Java）书之后，后来得知他可能对这些决定负有责任，但似乎并没有遵循书中所遵循的原则。我想声明两个接口：Collection和MutableCollection，它通过“可选”方法扩展Collection，将导致可维护性更高的客户端代码。 还有的问题一个很好的总结在这里。 是否有充分的理由为什么选择了可选方法而不是两个接口实现？

69 java  design  api  immutability 

所以我不知道这是好是坏的代码设计，所以我想我最好问一下。 我经常创建用于处理涉及类的数据的方法，并且经常对方法进行大量检查，以确保事先没有空引用或其他错误。 一个非常基本的例子： // fields and properties private Entity _someEntity; public Entity SomeEntity => _someEntity; public void AssignEntity(Entity entity){ _someEntity = entity; } public void SetName(string name) { if (_someEntity == null) return; //check to avoid null ref _someEntity.Name = name; label.SetText(_someEntity.Name); } 因此，您可以看到im每次都检查null。但是该方法应该没有此检查吗？ 例如，外部代码应事先清除数据，这样方法就不需要进行如下验证： if(entity != null) // this …

67 c#  design  validation 

我最近开始在一个与一些年龄较大的开发人员（大约50岁以上）一起工作的地方。他们致力于处理无法解决系统故障的航空关键应用。结果，较老的程序员倾向于以这种方式进行编码。 他倾向于在对象中放入一个布尔值，以指示是否应该引发异常。 例 public class AreaCalculator { AreaCalculator(bool shouldThrowExceptions) { ... } CalculateArea(int x, int y) { if(x < 0 || y < 0) { if(shouldThrowExceptions) throwException; else return 0; } } } （在我们的项目中，该方法可能会失败，因为我们正在尝试使用当时无法使用的网络设备。区域示例仅是异常标志的示例） 对我来说，这似乎是一种代码气味。编写单元测试变得有些复杂，因为每次都必须测试异常标志。另外，如果出现问题，您是否想立即知道？确定如何继续是呼叫者的责任吗？ 他的逻辑/理由是我们的程序需要做一件事，向用户显示数据。任何其他不会阻止我们这样做的异常都应忽略。我同意不应忽视它们，而应该冒泡并由适当的人员来处理，而不必为此处理标志。 这是处理异常的好方法吗？ 编辑：只是为了提供更多有关设计决策的信息，我怀疑这是因为如果该组件失败，程序仍可以运行并完成其主要任务。因此，当用户可以正常工作时，我们不想抛出异常（不处理它？）并让它删除程序。 编辑2：为了提供更多上下文，在本例中，该方法被调用来重置网卡。当网卡断开连接并重新连接时，会出现问题，它被分配了另一个IP地址，因此Reset将引发异常，因为我们将尝试使用旧的IP重置硬件。

64 c#  design  object-oriented-design  exceptions  code-reviews 

我正在设计一个新系统，我想知道什么是控制反转（IOC），更重要的是何时使用它。 它必须使用接口来实现还是可以通过类来实现？

64 design  design-patterns  inversion-of-control 

单一责任原则规定，一个班级只能做一件事情。有些情况很明确。但是，其他方法则很困难，因为在给定的抽象级别上查看时看起来像“一件事”，而在较低级别上查看时可能是多个事物。我还担心，如果在较低级别上遵循“单一责任原则”，则会导致过度分离，冗长的馄饨代码，而不是实际解决手头的问题，因为花更多的时间在所有内容上创建微型类并收集信息。 您将如何描述“一件事”的含义？有什么具体迹象表明一个班级确实比“一件事情”做得更多？

64 design  object-oriented 

OOP背后的主要思想是统一单个实体（对象）中的数据和行为。在过程编程中，有数据和修改数据的单独算法。 在“模型-视图-控制器”模式中，数据和逻辑/算法分别放置在不同的实体中，分别是模型和控制器。在等效的OOP方法中，模型和控制器不应该放在同一逻辑实体中吗？

61 design  object-oriented  mvc 

在程序设计中，我经常遇到必须将对象实例传递给多个类的情况。例如，如果我有一个加载音频文件的控制器，然后将其传递给播放器，然后播放器将其传递给playerRunnable，后者又将其传递到其他地方，等等。这看起来很糟糕，但我没有知道如何避免。还是可以这样做？ 编辑：也许播放器示例不是最好的，因为我以后可以加载文件，但是在其他情况下不起作用。

60 class-design  design