问题标签 [design-principles]

我是SOLID和DRY等软件设计原则的忠实粉丝。面向对象软件设计还有哪些其他原则？

笔记。我不是在寻找诸如“评论你的代码”之类的答案，而是寻找像鲍勃叔叔所讨论的那样的面向对象设计原则。

我正在重新编写一个作为数据输入工具的应用程序。现有应用程序在 Access 中，由具有多个网格的表单组成，每个网格包含许多列，需要用户水平滚动才能查看列。

表单上的当前网格在父子关系中分层布局。顶部网格代表项目，下方网格代表所选项目中的 SKU，下方网格代表上方所选 SKU 的季节数据（定价、运输信息等）。

我正在寻找有关此类应用程序的良好 UI 设计原则的建议。如何设计一个表单，让用户可以灵活地查看表单上数据的所有列，而无需滚动太多？

对于商业应用程序的 UI 原则，有哪些好的在线资源？

谢谢！

试图破译一个合适的面向对象设计来实现。基本情况是您有一个 PstnNumber，它本质上是一个始终以 0 开头的 10 位电话号码（例如 0195550000）。如果缺少前导 0（例如 195550000），则引入了允许自动更正数字的规则。

开始编辑

我意识到最初的问题可能被误解了（感谢那些已经回答过的人），所以我进行了编辑以尝试更好地解释这个场景。

结束编辑

我开始玩一些初步的概念，然后想我会问是否有更合适的方法可以走或做其中一个就足够了（在某种程度上）？

概念一

概念 2（已删除）

概念三

我认为概念 1 可能违反 Liskov 替换规则，因为子类改变了 Number 属性的行为（很高兴知道我是否误解了这一点）。

任何替代建议都会很高兴地收到。

是否在业务类中引用 System.Windows.Forms 并使用 MessageBox.Show 错误？

目前有一个事件处理装饰器类装饰一个服务类。当某些事件触发时，装饰器想询问用户是否要继续处理某些功能。

这个装饰器类有这些消息框可以吗？

大家好

最近在看这本书：

Bob Martin 的“敏捷软件开发、原则、模式和实践”

本书中列出了以下（SOLID）敏捷设计原则：

• 单一职责原则
• 开闭原则
• 里氏替换原则
• 接口隔离原则
• 依赖倒置原则

由于这本书很旧（2003 年），我有一个问题：

1. 除了 SOLID 方法，还有其他新开发的原理吗？如果是，是否有任何书籍/网站涵盖了这些新兴原则以及您可以推荐给我的实用代码示例？

当然，我可以谷歌搜索其中的一些。

但是，在stackoverflow中读写了很多profis，所以我也想听听他们的意见：D

在 OO 组件中，当您只有一个可用于类的实现并且该类没有“发布”到其他组件时，是否仍然建议使用接口并使用接口来代替？

我完全了解“界面编程”的设计原则，并广泛使用它。

最近，我一直观察到，大多数情况下，从不需要不同的实现（尽管可能并且有意义）。由于总是使用接口，应用程序代码将具有相当数量的接口，每个接口只有一个实现，并且接口似乎有点开销。

相反，是否最好只使用具体类并仅在需要第二个实现时才引入接口？无论如何，现在使用 IDE 提取接口是一件轻而易举的事。并且当引入新接口时，对旧具体类的引用可以更改为使用新接口。

你怎么看？

所以干掉代码应该是件好事吧？在我正在从事的一个项目中，存在某些模型/实体或多或少相同的情况，除了使用它们的上下文。也就是说，每个这样的实体都有一个标题、描述、标签、一个 user_id 等和一些其他属性。因此，他们在各自控制器中的 CRUD 操作看起来非常相似。

我的经理争辩说它重复了代码，需要干掉。因此，他提出了 CRUD ruby​​ 模块，当included 负责所有这些实体的控制器的 CRUD 操作时。但最终，Simplicity 受到了损害。代码失去了可读性，因为每个“事物”都被命名为“对象”。调试变得困难，干掉代码的全部意义就丢失了。

这只是一个案例。其中有几个 DRYing 会导致复杂、难以调试的代码。所以问题是，我们什么时候停止干燥代码？因为并非每次您都意识到代码已经失去了简单性（而且代码作者通常从未意识到代码的简单性已经失去了）。此外，如果我们必须在简单性和 DRYed 代码之间进行选择，应该选择什么，如果有一种情况，您只能获得其中任何一个。

在考虑性能的情况下，将软件的组件或架构设计归零是否可取？我的意思是，设计/架构应该准备好在性能密集型环境中使用吗？

在设计组件时，我们是否应该遵循良好的 OO 原则并确保组件是“可扩展的”。这样，当我们遇到性能问题时，我们会在这里和那里稍微调整设计。尽管这样，我们经常会遇到性能问题，稍微调整软件可能无济于事。

或者，我们是否应该提出一个设计，虽然很复杂，但性能问题却轻而易举。我们仍然需要调整软件，但调整通常非常简单，因为设计是面向性能的。

注意：在上面列出的任何一种情况下，我都没有尝试在遇到性能问题之前调整软件的性能。重新表述这个问题，软件的设计是否应该以性能为导向？

请不要回答我说这完全取决于软件预期运行的环境。原因是任何工业级软件的客户似乎总是想要越来越多。您可能不会计划您的软件在性能密集型环境中持续运行，但如果必须这样做呢？当我们感觉到这一点时，我们是否应该重新设计软件？

这个问题一直困扰着我一个星期，我还没有答案。你对此有什么看法？

我们正在使用 C# 和 EmguCV 进行图像处理项目。我们的团队由3人组成。为了取得更快的进展，我们三个人同时处理不同的子问题或尝试不同的算法。

目前，我们每个人都创建了一个包含我们正在处理的主要代码的函数，并且我们所有人都对驱动程序进行了更改以添加对我们新函数的调用。所有这些都发生在同一个文件上。我们正在使用源代码控制，所以我们还没有进入对方的脚趾。但我不认为随着我们取得更多进展，这将是可持续的。另外，我觉得代码越来越混乱。

我在想我们最好实现策略模式并将我们的算法或子问题处理封装到它们自己的类中，并从驱动程序中调用每个类的执行方法。

但是我意识到这种方法可能存在一些问题：

1. 不同的算法采用不同的输入（源图像、一些不同的参数集等）
2. 不同的算法返回不同的输出（新图像、特征集、矩阵等）

我相信我可以通过做这样的事情来克服第一个问题

我可以更改不同策略的构造函数，以便它们可以接受不同类型的参数。

当我考虑如何处理返回多个类型/值的问题时，我首先想到的就是将execute的返回类型从void更改为类似于哈希表的东西，其中可以存储和返回不同的返回参数或具有类的其他成员，例如“ int _returnCode”，可以通过其他方法或通过该类的只读属性检索。

我不确定这在设计原则方面会有多好，并且很高兴听到您对此的看法。谢谢

我对 Liskov 替换原则的理解是，基类的某些属性是真的，或者基类的某些实现的行为，对于派生类也应该是真的。

我想这意味着当一个方法在基类中定义时，它不应该在派生类中被覆盖——因为这样替换基类而不是派生类会产生不同的结果。我想这也意味着，拥有（非纯）虚拟方法是一件坏事？

我想我可能对原理有错误的理解。如果我不这样做，我不明白为什么这个原则是好的做法。谁可以给我解释一下这个？谢谢