Questions tagged «design»

有时，我需要修改从方法本身内部传递到方法中的值。一个示例将在此处清除诸如此类的字符串： void SanitizeName(string Name) { Name = Name.ToUpper(); //now do something here with name } 这是完全无害的，因为该Name参数未通过引用传递。但是，如果由于某种原因，将来开发人员决定让ref传递所有值，则对字符串进行任何清理都会影响方法外部的值，这可能会带来不利的结果。 因此，我总是像这样创建本地副本，而不是重新分配参数本身： void SanitizeName(string Name) { var SanitizedName = Name.ToUpper(); //now do something here with name } 这样可以确保更改传递的值永远不会影响方法外的操作，但是我想知道我是否对此过于偏执。

12 design  programming-practices 

我正在编写一个应用程序，到此为止： private void SomeMethod() { if (Settings.GiveApples) { GiveApples(); } if (Settings.GiveBananas) { GiveBananas(); } } private void GiveApples() { ... } private void GiveBananas() { ... } 这看起来很简单。有一些条件，如果满足，则将调用方法。但是，我在想，这样做是否更好： private void SomeMethod() { GiveApples(); GiveBananas(); } private void GiveApples() { if (!Settings.GiveApples) { return; } ... } private void GiveBananas() …

12 design  conditions 

我们正在测试C ++ 11（即-std=c++11）下的库。该库使用auto_ptr以下模式： Foo* GetFoo() { autoptr<Foo> ptr(new Foo); // Initialize Foo ptr->Initialize(...); // Now configure remaining attributes ptr->SomeSetting(...); return ptr.release(); } C ++ 11已弃用auto_ptr，因此我们希望远离它。 但是，该代码同时支持C ++ 03和C ++ 11，因此它不是yanking那样简单auto_ptr。还值得一提的是该库没有外部依赖项。它使用C ++ 03; 并且不使用Autotools，Cmake，Boost等 auto_ptr在保持与C ++ 03的兼容性的同时，我们应如何处理设计更改以脱离C ++ 11？

12 design  c++  c++11 

我正在开发一个使用MS SQL来处理各种数据的Web应用程序：包括用户，用户帐户，用户许可证，许可证价格，发票。 我需要记录用户对系统的实时使用情况，并将其用于每月计费：例如，每当用户获得特定页面/ URL时就记录一次，并在月底根据所获取的页面数向用户计费。 是否应该将这些日志事件写入MS SQL数据库的表中？ 是否应将这些日志事件写入非SQL的仅追加日志文件？ 我应该为每个用户将这些日志事件写入不同的日志文件吗？ 这不是一个特别庞大的网站：例如，最多10,000个用户，每个用户平均每天进行5个可记录事件=> 50,000个事件/天= 30个事件/分钟= 18,000,000个事件/年。 我问是因为这两种选择似乎都是可行的，而且我看不出是否有明显的优势。 与计费事件相关的数据很简单，例如： 用户ID（SQL中与Users表的外键关系） 日期和时间 计费页面的URL 我对这个问题的回答如下： 将日志写入数据库表的一些好处： 关系完整性：例如，记录的事件与有效的用户ID相关联（通过将用户ID定义为表之间的外键） 易于阅读的账单：例如SELECT COUNT GROUP BY，获得每个用户的日志事件数的计数 写入日志文件的一些好处： 性能更容易：SQL较少使用，例如仅用于用户登录事件，而大多数仅用于读取 易于管理：通过移动旧日志文件而不是通过从数据库中删除/存档，例如在年底时更易于归档旧数据 如果我的答案有误，请告诉我；或夸大某事的重要性；或忘记了一些重要的考虑。 和/或，如果与我的答案不同，请告诉我您的答案是什么。

12 design  web-development  database  performance  logging 

我在一家大公司工作，这规定了敏捷过程的使用。例如，对于我们的项目，我们使用专门针对管理敏捷开发的基于云的服务。 我所服务的特定工程团队没有传统开发的软件（相反，我们从更鸟瞰的角度帮助推动项目），但是这种情况正在发生变化。我们有大量即将到来/计划中的软件项目，这些项目大多以数据为中心-例如，我们将进行数据监控，收集，汇总和一些报告。其他任务包括使用专用硬件和各种类型的客户端/服务器（多层）体系结构进行自动化。我将协助雇用多个人，并制定我们前进的许多计划。 我的问题是进行快速原型设计（一次性代码）是否适合敏捷哲学。例如，我喜欢Python及其广泛的软件包。我看到使用基于Python的工作流非常快地实现我们的许多想法的可能性。但是，我认为会有很多人认为Python不是“企业质量”的，并且许多工作都需要用Java或C ++重写。 但是，创建Python原型将使我们在快速实现真实结果方面付出巨大的努力。 您是否能够在企业环境中将快速原型制作（希望在Python中）整合到可靠的敏捷工作流程中？

12 python  agile  design  prototyping  product-management 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 6年前关闭。 我们知道与客户协商规范更正的最佳情况，使规范能够满足客户的要求，而不是客户的要求或想法。正在谈判，解释。 有时，我们无法说服客户。我们被迫按照设计生产破碎的产品。这被魔术师称为“恶魔学”，恶魔召唤恶魔并真正实现他们的愿望，导致魔术师消亡，这是另一种方法，一旦客户意识到自己的错误，他们就会非常不满意，当然还要设法锁定责怪开发商。 现在，我面对的是一个截然不同的方法：客户创建了简单的规范，这些规范不能解释一些关键的警告，并且完全不愿意修复它们，承认明显的错误并接受建议的更正。按照这些规格制造的产品将严重损坏，并可能导致人员伤亡。不过，现在完全放弃合同为时已晚。合同对此有惩罚性条款，我们真的不能接受。 老板的决定？我们会正确地完成工作，并根据规格向客户说谎。有问题的算法隐藏在表面之下足够深的位置，产品可以很好地完成工作，在出现警告的情况下不会失败，并且除非有人挖得太深，否则他们将永远不会发现我们没有按要求进行破解。 这种执行规范的策略有一些通用名称吗？

12 design  specifications 

我在有关.NET属性的设计问题。 interface IX { Guid Id { get; } bool IsInvalidated { get; } void Invalidate(); } 问题： 此接口具有两个只读属性，Id和IsInvalidated。但是，它们本身是只读的事实本身并不能保证它们的值将保持不变。 可以说，我的意图是要清楚地表明…… Id 表示一个常量值（因此可以安全地缓存），而 IsInvalidated可能会在IX对象的生存期内更改其值（因此不应缓存）。 我如何修改interface IX以使该合同足够明确？ 我自己尝试的三种解决方案： 该界面已经过精心设计。调用方法的存在Invalidate()使程序员可以推断出类似名称的属性的值IsInvalidated可能会受到它的影响。 仅在方法和属性的命名类似的情况下，此参数才成立。 通过事件增强此接口IsInvalidatedChanged： bool IsInvalidated { get; } event EventHandler IsInvalidatedChanged; …Changed事件的存在IsInvalidated表明该属性可能会更改其值，而事件的类似事件的缺失Id则表明该属性不会更改其值。 我喜欢这种解决方案，但其中很多其他的东西可能根本就不会使用。 IsInvalidated用以下方法替换属性IsInvalidated()： bool IsInvalidated(); 这可能太微妙了。可以暗示每次都会重新计算一个值-如果它是一个常数，则不需要。MSDN主题“在属性和方法之间选择”对此有这样的说明： 在以下情况下，请使用方法而不是属性。[…]每次调用操作都会返回不同的结果，即使参数没有更改。 我希望得到什么样的答案？ 我对解决该问题的完全不同的解决方案最感兴趣，并给出了它们如何击败我的上述尝试的解释。 如果我的尝试在逻辑上有缺陷或具有尚未提及的重大缺点，以致仅剩一种解决方案（或没有解决方案），我想听听我哪里做错了。 如果缺陷很小，并且在考虑了多个解决方案后仍然存在，请发表评论。 至少，我希望获得一些反馈，以了解哪种是您首选的解决方案，以及出于何种原因。

12 c#  design  .net  properties 

这就是我所谓的“组合式” getter / setter方法（来自jQuery）： var foo = $("<div>This is my HTML</div>"), myText; myText = foo.text(); // myHTML now equals "This is my HTML" (Getter) foo.text("This is a new value"); // The text now equals "This is a new value") 这与单独（理论）方法的逻辑相同： var foo = $("<div>This is my HTML</div>"), myText; myText = …

12 design  javascript 

这基本上是一个关于弱实体是什么的问题？我们什么时候应该使用它们？应该如何建模？ 普通实体和弱实体之间的主要区别是什么？在进行域驱动设计时，弱实体是否对应于值对象？ 为了使问题始终保持话题，这里是一个来自维基百科的示例，人们可以用来回答以下问题： 在此示例中OrderItem，我们将其建模为弱实体，但我不明白为什么不能将其建模为普通实体。 另一个问题是，如果我想跟踪订单历史记录（即订单状态的变化），那将是正常实体还是弱实体？

12 design  database  database-design  entity 

我是一家嵌入式系统公司的软件开发人员。我们有一个项目经理，他负责整个项目进度表（包括电气，质量，软件和制造），因此他的软件进度表非常简短。 我们还有一个软件经理，我的老板。他让我编写和维护软件进度表，设计文档（高低级设计），SRS，变更管理，验证计划和报告，发布管理，审阅，当然还有软件。 我们整个软件团队只有一名测试工程师（十名成员），并且在任何给定时间，都有几个项目正在进行。 我花了80％的时间制作这些文档。我的老板来自流程方面，并且认为我们需要更好的文档来改进软件： 他认为设计是最重要的，编码是“只是将设计写下来”，时间不要太长，并且“所有代码都应在硬件准备好之前编写”。 即使我们告诉他与分布式模型的协作更轻松，也不了解中央版本控制和分布式版本控制之间的区别。 不懂代码，想了解每个错误及其建议的解决方案。 认为验证应由开发人员完成，测试人员应进行验证。事实是，我们的验证仅检查实现是否正确（我们不编写单元测试，在计划中从未考虑过），而验证是黑盒测试，因此缺少单元测试。 我真的很困惑 我负责维护所有这些文件吗？本质上，这让我感到自己正在执行软件项目管理。我可以接受技术文档，但我相信开发人员不应该进行计划/计划。 我不太喜欢创建文档，我想解决问题并编写代码。以我的经验，创建设计文档只会在一定程度上有所帮助，而对于更好或更快速的代码来说却无济于事。 我觉得老板并不真的在乎制造更好的产品，而只是在管理层眼中成为一名好经理。 我能做什么？整整一年，我已经完成了3个月的实际编码，其余时间仅用于制作文档和等待来自客户的错误报告。

12 design  project-management  development-process  documentation 

我正在开发一个应用程序，该应用程序将用于在工业环境中打开和关闭阀门，并且正在考虑这样的简单操作：- public static void ValveController { public static void OpenValve(string valveName) { // Implementation to open the valve } public static void CloseValve(string valveName) { // Implementation to close the valve } } （该实现会将一些字节的数据写入串行端口以控制阀门-从阀门名称派生的“地址”，以及“ 1”或“ 0”来打开或关闭阀门）。 另一个开发人员问我们是否应该为每个物理阀创建一个单独的类，其中有几十个。我同意，最好使用PlasmaValve.Open()而不是编写类似的代码ValveController.OpenValve("plasma")，但这是否太过分了？ 另外，我想知道如何最好地考虑到一些假设的未来需求： 我们被要求支持一种新型的阀门，该阀门需要不同的值来打开和关闭它（不是0和1）。 我们被要求支持可以设置在0-100之间的任何位置的阀，而不是简单地“打开”或“关闭”。 通常，我会在这种情况下使用继承，但是最近我开始着手解决“继承之上的组合”问题，并想知道使用组合是否有一个更好的解决方案？

12 design  design-patterns  object-oriented 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 2年前关闭。 我意识到我很难创建OOP设计。我花了很多时间来确定此属性是否正确设置为X类。 例如，这是一个有几天的帖子：https : //codereview.stackexchange.com/questions/8041/how-to-improve-my-factory-design 我不相信我的代码。因此，我想改善设计，减​​少设计时间。 您如何学习创建好的设计？您可以推荐我一些书吗？

12 design  object-oriented 

我正在阅读彼得·塞贝尔（Peter Seibel）写的这本很棒的书，叫做《编码员在工作：对编程技巧的思考》，而我正在与约书亚·布洛赫（Joshua Bloch）进行对话，我找到了这个答案，这对程序员来说很重要。该段是这样的。 这里有一个问题，那就是编程是一种智力精英，而这些人往往是组织中最聪明的人。因此，他们认为应该允许他们做出所有决定。但是，仅仅是他们是组织中最聪明的人这一事实并不意味着他们应该做出所有决策，因为智能不是标量。这是一个向量数量。 在最后一句话，我没有得到他试图分享的见识。有人可以进一步解释它对向量量的含义，可能试图提供相同的见解。 再往下看，我要说的是，他并不是要建立一个非技术人员（有时很笨拙）可以成为技术人员的经理的组织，原因是他们可以花更多的时间写好电子邮件，因为下一个原因以上段落之后的声明是。 而且，如果您缺乏同理心或情感智慧，那么您就不应该设计API，GUI或语言。 我了解他说的是，在软件工程中，程序员应该知道用户如何看待他们的产品和设计。 我觉得上一段非常有趣。

12 design  project-management  customer-relations 

我正在开发用于集成视听系统的信号管理和路由模块，并且正在设计该模块，以便在不同的信号分配网络中尽可能地灵活。该模块的目的是处理跨多个堆叠矩阵切换器1的路由并处理必要的格式转换。 在这一点上，我探索的最好的解决方案是将网络映射到一个图形，该图形具有针对切换器支持的每种信号类型的离散顶点，然后通过代表处理格式转换的视频处理器的节点进行连接。 颜色代表信号格式。 圆形节点是切换台，源或宿。 正方形节点是执行格式转换的视频处理器。 从那里，我可以使用Dijkstra算法的实现来识别为使输入X到输出Y所必须形成的路径。这应该允许有关所有切换器和处理器的输入/输出配置的数据传入并相应地调整模块。 这是一个适当的解决方案，还是值得研究的替代方法？ 1个又名“纵横开关”，是具有M输入x N输出的视频路由器，支持一对多连接。每个物理设备可以处理多种信号格式，并且可能执行或可能不执行任何格式转换。 编辑：正如PéterTörök所提到的，图形不一定是一棵树，该图是一个简单的例子来说明这个想法。在“现实世界”中实现时，可能会存在多个路径，这些路径可提供不同级别的清晰度（DVI> VGA>组件>复合），而我打算用边缘加权来表示。 编辑2：这是一个稍微全面的示例，其中指示了方向性，并显示了由两种信号类型组成的网络。最初的示例已稍作修改，因此设备上的每个输入和输出都定义为离散节点，因为这将提供控制矩阵路由/输入选择所需的数据。

12 design  algorithms 

我们正在尝试使用DDD方法将数据从庞大的Service层移至Domain层。当前，我们的服务中有很多业务逻辑，这些业务逻辑遍布各地，并且无法从继承中受益。 我们有一个中心的Domain类，这是我们大多数工作的重点-Trade。贸易对象将知道如何定价，如何估计风险，验证自身等。然后，我们可以用多态性替换条件。例如：SimpleTrade将以一种方式定价，而ComplexTrade将以另一种定价。 但是，我们担心这会使贸易类膨胀。它确实应该负责自己的处理，但是随着添加更多功能，类的大小将成倍增加。 所以我们有选择： 将处理逻辑放在贸易类中。现在，根据交易类型，处理逻辑是多态的，但是交易类别现在具有多种责任（定价，风险等）并且规模很大 将处理逻辑放入其他类，例如TradePricingService。Trade继承树不再具有多态性，而是类更小并且更易于测试。 建议的方法是什么？

12 object-oriented  design  domain-driven-design