Questions tagged «design»

老板给了我一个具有特定逻辑的项目。我必须开发一个网页，该网页必须带领导航员处理很多情况，直到他/她找到产品为止。 这是站点中导航的路径方案： 重要！ 在产品页面中，导航器可以选择他想要的过滤器。 如果是A，则他/她必须通过B（然后是C）或C，然后到达产品。 如果是B，则他/她必须经过C并到达产品。 如果为C，则他/她直接到达产品。 当然，如果我从AI开始走的是最长的路，当我到达产品时，我将拥有3个有源滤波器。 到目前为止，我开发了下面的代码，效果很好。 if filter_A if filter_B filter_C() .. else .. else filter_C .. else .. else if filter_B filter_C() .. else .. else filter_C() .. else .. 我在这里问一个更专业的程序员在这种情况下会做什么。我不尊重DRY原理，我不喜欢它，我想知道开发这种逻辑的另一种方法。 我曾考虑过将代码的每个部分拆分为函数，但是在这种情况下，这是一个好主意吗？

15 design  design-patterns  language-agnostic  conditions  if-statement 

我刚刚开始一个新的个人项目（Python），并且正在编写相当于该程序“草稿”的内容，这是完成我想做的事情的最低要求。我尚未投入大量的错误/异常处理或美观的UI元素（即使在我最终将需要这些东西的情况下），并且该文档仅足以帮助我将来了解自己在做什么。 如此粗糙地违反项目设计/管理的既定原则？我是科学家，而不是程序员，因此无法及时掌握这些信息。因此，主要问题是，是否应该就介于以下两个极端之间的目标达成共识： 从一开始就编写全面，高质量的代码，包括所有异常处理，使您知道最终需要使用。 从一开始就编写一份工作最少的草稿，然后再填写所有细节。 相关问题：什么时候可以牺牲设计的“整洁度”来完成项目？

15 design  project-management  time-management 

我有以下地图： Map<Double, List<SoundEvent>> soundEventCells = new HashMap<Double, List<SoundEvent>>(); 这HashMap会将double值（它们是时间点）映射到相应的SoundEvent“单元格”：每个“单元格”可以包含多个SoundEvent。这就是为什么将其实现为的原因List<SoundEvent>，因为这正是它的本质。 为了提高代码的可读性，我考虑过实现一个非常简单的静态内部类，如下所示： private static class SoundEventCell { private List<SoundEvent> soundEvents = new ArrayList<SoundEvent>(); public void addEvent(SoundEvent event){ soundEvents.add(event); } public int getSize(){ return soundEvents.size(); } public SoundEvent getEvent(int index){ return soundEvents.get(index); } // .. remove() method unneeded } 并且比地图声明（以及许多其他代码）看起来更好，例如： Map<Double, SoundEventCell> soundEventCells …

15 java  design  object-oriented 

（出于这个问题的目的，当我说“接口”时，我的意思是语言结构interface，而不是用另一种意义上的“接口”，即，一个类提供了与外界进行交流的外部方法，并且操纵它。） 松散耦合可以通过使对象依赖于抽象而不是具体类型来实现。 这允许松散耦合，主要有两个原因：1-与具体类型相比，抽象的更改可能性较小，这意味着从属代码中断的可能性较小。2-不同的具体类型可以在运行时使用，因为它们都适合抽象。以后也可以添加新的具体类型，而无需更改现有的从属代码。 例如，考虑一个类Car和两个子类Volvo和Mazda。 如果您的代码依赖于Car，则可以在运行时使用Volvo或Mazda。同样，以后可以添加其他子类，而无需更改从属代码。 另外，Car-是一种抽象-，更改的可能性小于Volvo或Mazda。汽车在相当长的一段时间内大体相同，但沃尔沃和马自达的变化可能性更大。即抽象比具体类型更稳定。 所有这些都是为了表明我理解什么是松散耦合以及如何通过依赖抽象而不是依赖具体实现来实现松耦合。（如果我写的东西不准确，请这样说）。 我不明白的是： 抽象可以是超类或接口。 如果是这样，为什么接口因其允许松耦合而受到特别赞扬？我没有看到它与使用超类有什么不同。 我看到的唯一区别是：1-接口不受单一继承的限制，但这与松耦合这一主题无关。2-接口更加“抽象”，因为它们根本没有实现逻辑。但是，我仍然不明白为什么会有如此大的不同。 请向我解释为什么说接口在允许松散耦合方面是很棒的，而简单的超类却不是。

15 design  object-oriented  interfaces 

我们的知识领域涉及人们赤脚行走在压力记录板上。如果在传感器数据中识别出人脚，我们会进行图像识别，从而产生“脚”类对象。 必须对脚的数据执行一些计算。 现在，哪种API更好： class Foot : public RecognizedObject { MaxPressureFrame getMaxPressureFrame(); FootAxis getFootAxis(); AnatomicalZones getAnatomicalZones(); // + similar getters for other calculations // ... } 要么： class Foot : public RecognizedObject { virtual CalculationBase getCalculation(QString aName); // ... } 现在，我可以提出很多优点和缺点，但是我不能真正决定哪个最重要。请注意，这是最终用户应用程序，而不是我们出售的软件库。 有什么建议吗？ 第一种方法的一些专家可能是： 吻-一切都非常具体。API，但实施也是如此。 强类型返回值。 从此类继承是万无一失的。什么都不能覆盖，只能添加。 API是非常封闭的，什么都不会进入，什么都不能被覆盖，所以更少的地方会出错。 一些缺点： 随着我们发明的每一项新计算都被添加到列表中，吸气剂的数量将会增加 API更可能会更改，如果引入了重大更改，我们需要一个新的API版本，即Foot2。 如果在其他项目中重复使用该类，我们可能不需要进行所有计算 …

15 design  c++  object-oriented  programming-practices  language-agnostic 

我最近遇到了Jaron Lanier提出的一个名为“现象学编程”的想法。 这个想法是在计算机程序中使用“表面”接口而不是单点接口，利用统计信息来找出较小的错误，这些错误通常会导致“经典”程序崩溃。 两行描述在这里： 根据Jaron的说法，“当前软件思想（协议遵循性）与（他正在讨论的）思想（模式识别）之间的真正区别与我们正在创建的错误类型有关”，如果“我们不知道， “找不到思考和创建软件的不同方法，无论我们的处理器有多快，我们都不会写出超过一千万行代码的程序。” 稍长的解释在这里。甚至更长的解释在这里。 因此，这个问题回过头来，人们往往会挑出明显的机器人主导的涵义，那么人们将如何实际设计和编写“交互程序”呢？

15 design  program 

一方面，有一条建议说“建一个要扔掉”。只有在完成软件系统并查看最终产品之后，我们才能意识到设计阶段出了什么问题，并了解我们应该如何真正做到这一点。 另一方面，存在“第二系统效应”，它表示设计的同一类型的第二系统通常比第一个系统差。有许多功能不适合第一个项目，而被推入第二个版本通常会导致过于复杂和过度设计。 这些原则之间不是在这里有些矛盾吗？对这些问题的正确看法是什么，两者之间的边界在哪里？ 我认为，这些“好的做法”是在弗雷德·布鲁克斯（Fred Brooks）的开创性著作《神话人月》中首次得到推广的。 我知道其中一些问题已通过敏捷方法解决，但从深处看，问题仍然是原则。例如，在上线之前，我们不会对3个Sprint进行重要的设计更改。

15 design  project-management  programming-practices  project  principles 

受此问题启发使用第三方库-始终使用包装器吗？ 我想知道人们实际上认为第三方库是什么。 来自PHP的示例： 如果我正在使用Zend框架构建应用程序，是否应该将Zend框架库视为第三方代码？ C＃中的示例： 如果正在构建桌面应用程序，是否应该将所有.Net类都视为第三方代码？ Java示例： 是否应将JDK中的所有库都视为第三方库？ 有人说，如果一个库是稳定的并且不会经常更改，那么就不需要包装它。但是我看不到如何包装不依赖第三方代码的类。

15 programming-languages  design  object-oriented  unit-testing  terminology 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 4年前关闭。 我是一家小公司的首席开发人员，使用C＃和ASP.Net。我们的团队很小，只有2-3人，没有太多的开发和设计经验。我没有机会向更多的高级开发人员学习，我的团队中没有人可以指导我并帮助我选择最佳方法，因为我自己会照顾大部分项目。 在没有更多经验丰富的开发人员的情况下，如何在实际项目中工作时提高软件开发技能？

15 web-development  self-improvement  development-process  experience  design 

我已经使用敏捷方法（SCRUM）大约三年了，我看到了它的某些优势，特别是在许多级别的短期反馈中（来自能够早期访问已实现功能的客户，来自可以测试功能的测试人员）。实施后，其他开发人员可以通过审查等方式就新代码提供非常早期的反馈）。 另一方面，我有两个悬而未决的问题，第一个我将尝试在这个问题中进行解释。 问题：难以获得良好的设计 我试图在代码混乱时立即进行重构，我会尽力编写单元测试（这确实有助于防止错误，尤其是重构时）。另一方面，以小增量开发一些复杂的功能，每天提交并在非结构化代码时不断重新思考代码，这使我无法产生出真正好的设计。 我最近采用的另一种方法可以生产出唯一经过精心设计的模块，方法是采用不同的方法：我分析了几天的问题（实际上，在我开始认真研究该问题之前，我已经将这个问题花了几个月的时间） ），为所有涉及的类及其之间的关系草拟了相当详细的设计，持续了两天，然后将自己锁在办公室，并通过不间断地工作了大约三周时间写下了整个代码。结果是我一段时间以来取得的最好的结果，很少有易于定位和修复的错误，并且设计非常清晰，自此以后就不需要进行任何相关更改。 因此，到目前为止，我发现预先了解要执行的操作的总体效果比开始以小增量编写代码要有效得多，以期在此过程中神奇地出现大效果。尽我最大的努力，小增量开发方法一直使我的设计变糟。 问题：有没有类似的经历？我是否以错误的方式应用SCRUM，或者如果我想以较小的增量进行开发并且最终仍然使用精心设计的软件，应该注意什么？还是应该在开始实际编码之前安排设计用户故事？至少对于比平均水平更复杂的功能，这是否被视为一种好的做法？ 编辑-注意 我知道这样一个事实，即好的设计不是绝对的东西，本身没有价值，而是取决于上下文，因此，人们应该针对一种足以解决当前问题的设计。 例如，如果我必须实现一个简单的组件，即（1）必须尽快准备就绪，（2）仅使用一次，（3）不用，那么我不会在乎（过分）好的设计。由系统的其他部分（YAGNI）使用。 当组件（1）会被多次使用并且会在产品的几种不同版本中使用时，我确实会在乎良好的设计；（2）需要维护并随着时间的流逝而扩展；（3）取决于它，还有很多其他组件。

15 design  agile 

在围绕MVC设计项目的体系结构时遇到一些问题。（这是一个C ++ / Marmalade SDK项目，我没有使用任何特定的MVC框架，而是创建了一个。） 在几篇文章中（例如在史蒂夫·伯贝克（Steve Burbek）的原始文章中），我一直在阅读“ MVC triad”的概念，这使我感到困惑，因为我从字面上理解了这个概念。当我第一次阅读它时，看起来应用程序是围绕“ MVC triad”单元构建的（我应该为每个UI单元构建一个单元），但是我发现这相当不灵活，我认为这并不是打算使用MVC的方式。然后，进一步研究该问题，我发现了控制器和视图紧密耦合的几个示例，即一对一关系-TextEditView具有TextEditController。 但是，当我回到项目时，发现使用一个控制器（按“逻辑单元”，如AddElementController）和该特定控制器的多个视图可能会很有用。 我显然在考虑类似AddElementController之类的东西，它应该具有某种选项卡式UI。我是否应该具有一个具有AddElementTabView的AddElementController以及用于选项卡的几个AddImageView，AddSoundView等？还是每个选项卡视图都应该有一个不同的“子控制器”？ 总而言之，关于MVC模式（不是X框架对此模式的特殊理解/实现），为一个控制器拥有多个视图是否正确，还是每个视图都应具有其特定的控制器？ 另外，在控制器上保留一些状态信息是否正确还是应该是无状态的（意味着状态应该放在某些非域状态模型上）？ 在此先感谢所有。

15 design  design-patterns  architecture  mvc 

我通常喜欢使用小方法，这是Bob Martin在Clean Code中所建议的。我对Objective-C的内部知识也已经读够了，至少对它的消息分发如何工作有一些了解（bbums系列对此特别有用）。 尽管有过早的优化问题，但我想知道，Objective-c使用objc_msgSend所做的所有工作，实际上是否足够重要，以至于“许多小方法”方法对于Objective-C项目而言是不可取的。 经验发现尤其值得欢迎（也许我有时会自己进行测试）。任何编写过大型Objective-C项目的人的经验也将很棒。 澄清度 这个问题的总体语气是故意的。我不是在问特定应用程序的性能调优（这就是为什么我在这里而不是在SO上问的原因），而是更多关于Objective-C的语言特性是否会阻碍某种设计方法。我观察到我从Apple和其他各方（在github等上）看到的许多代码都倾向于大型方法（和类），并且我想知道这是否由于语言而逐渐消失了本身。当然，我可能读错了代码，或者可能是文化因素而不是技术因素导致了这种趋势（如果存在）。 （对于它的价值，我目前正在编写Objective-C，并且正在使用小的方法） 进一步要求 我同意已经给出的两个答案。我想做的另一件事是让某人指向我（希望是实质性的）开源（或其他可见的）Objective-C代码库，该代码库使用了不错的简短方法（和小型类）。我尚未在Objective-C中看到任何东西可与（例如）fitnesse来源进行比较。

15 design  coding-style  objective-c 

我们正在使用带有控制器/视图表示层和模型的ASP.NET MVC 2，该模型和模型由业务逻辑层，数据访问层[存储过程和与存储过程进行通信的类/方法]组成。 在业务层及更高层中，对于大多数用途而言，编辑似乎能够代表对象的创建和对象的编辑。这与定义“保存”方法的存储库设计模式非常吻合。我们可以简单地在存储过程中检查ID是否为0，然后如果ID为0则创建一个新对象，否则我们可以只更新现有对象，因为类别ID应该匹配一个。 讨论的主要要点是，将包含创建的编辑拆分为DAL层之外的创建和编辑的单独部分是否最有意义。 一个明显的例子可以显示为路线： 创建 - HTTP：// someurl / somearea /编辑/ 0 编辑 - HTTP：// someurl / somearea /编辑/ 254 与 创建 - HTTP：// someurl / somearea /创建 编辑 - HTTP：// someurl / somearea /编辑/ 254 是否有与此相关的既定标准或最佳实践？ 我知道这是一个小细节，但从逻辑上讲，这是一个重要的细节。

15 design  design-patterns  asp.net-mvc 

在需要尽快完成工作并做好工作的产品上工作时，何时才能牺牲设计的可维护性和“整洁”才能使事情快速完成并交付使用？而且在什么程度上还可以，特别是当使它变得“整洁”的技术对我来说是新的时？

15 design 

关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 6年前关闭。 如此众多的自由软件项目都有精美的艺术品，尤其是网站，我不知道编码员在哪里遇到他们的艺术家。除了当地艺术专业的学校董事会之外，还有其他地方可以要求吗？我想到了IRC，但我担心实际上有人可能会问起那小而频繁的用户群。

15 design  free-software