问题标签 [design-principles]

在工作中，我们有优化引擎，这些引擎使用的输入之一是业务规则，我们使用专有的规则编辑器创建和编辑。

这些规则是我们自己的专有格式，因为现有的规则引擎无法表示我们需要的复杂业务规则。

无论如何，我们或多或少对规则引擎当前的工作方式感到满意——它非常适用于复杂的业务规则，但对用户界面（规则编辑器）不满意。基本上，这目前由一组表组成，这些表从字面上看是使用复杂的类似电子表格的表格 GUI 进行编辑的。

虽然这是功能性的，但它是一个糟糕的界面，呈现给不是开发人员但相当于业务分析师的最终用户。在动手之前，我认为最好询问 StackOverflow 社区对针对这种情况的用户界面设计的意见。

我的问题

• 您在现有的规则编辑器中看到了哪些最好的用户界面？
• 您认为规则编辑器中用户界面设计背后的最佳原则是什么？

我分别使用术语规则引擎和规则编辑器。对于这个问题，我只关心规则编辑器

StackOverflow 上的其他问题涉及规则引擎，但既不是规则编辑器也不是他们的用户界面设计：

• 评估业务规则引擎的标准
• 什么时候不应该使用规则引擎？
• 我应该使用什么规则引擎？
• 何时使用业务规则引擎
• 如何设计规则引擎？
• 与规则引擎交互的首选方法

当我实例化/声明该类时，是否可以指定该类的父类？例如，我可以做类似的事情：

然后根据该语句，MonitoredDevice 类将从类型参数 DeviceTypeToExtend 扩展。现在，我知道您不能使用类型参数从超类扩展，但是有没有人知道类似的东西可以实现从特定父类“动态”扩展的目标。

谢谢，

史蒂夫

今天看到一个职位描述，要求“有丰富的C++编码经验和结构化设计原则的透彻基础”，所以我想到了这些原则是什么。一开始我觉得用一句话看C++和“结构化设计”有点奇怪，然后我想，好吧C++是一种多范式编程语言，所以它可能像C一样使用。我还查了维基百科页面并阅读关于异常处理和状态机是反结构化设计（不足为奇），但我仍然觉得缺少很多东西。所以我问你，最重要的结构化软件设计原则是什么？

松散地说，里氏替换原则指出派生类可以替代基类而不影响用户。如果基类是抽象类，即没有用户使用基类的实例，那么 Liskov 继承限制是否仍然适用于派生类？

在面向 Web 的应用程序中开发优雅的 Pub-Sub 架构是一项真正的挑战。虽然有一些非常有趣的解决方案使用长轮询连接（例如 COMET）和重复超时（例如 js setTimeout）。恕我直言，AJAX 推送仍然看起来像是一层强制无辜 HTTP 协议的调整和黑客攻击。

那么您认为AJAX 推送是不是 HTTP 协议失常呢？

您可以在 Web 架构中考虑哪些其他替代方案？

可能重复：
StructureMap 单例用法（实现两个接口的类）

我目前正在设计一个小型系统，并且我目前正在使用 structureMap 作为 IoC。我最近才明白接口隔离的意义……我现在想知道。

如果我有一个特定的业务对象，它将实现三个接口......我应该如何在代码的配置和实例化中处理这个？

假设我在一个简单的场景中有两个接口，用于一个名为 EmployeeServiceObject 的服务层类。IGenericEntity 和 IEmployeeServiceObject。

GenericEntity 将为类提供 CRUD 功能，而 IEmployeeServiceObject 将为业务查询/操作提供结果集。

如果在外观/服务层方法上，我必须使用 EmployeeServiceObject 类并实际使用两个接口的功能......应该如何处理？

最初我认为正确的做法是设置 IoC 的配置以将 IEmployeeServiceObject 映射到 EmployeeServiceObject，向工厂询问对象，然后在需要使用 CRUD 功能时将其转换为 IGenericEntity，但我不太确定. 这似乎也不正确，因为我永远不会正式声明具体类实际上正在实现未在 ioc 容器配置中设置的接口。

而且我绝对知道创建同一个具体类的两个实例但要求不同的接口......听起来更糟。

这应该如何处理？

今天我遇到了对象编程风格、具体类型或接口的一个基本悖论。

方法的返回类型有什么更好的选择：具体类型还是接口？

在大多数情况下，我倾向于使用具体类型作为方法的返回类型。因为我相信具体类型更灵活，可以进一步使用并提供更多功能。

这方面的阴暗面：耦合。天使般的：一个具体的类型本身包含你最初将要返回的接口，以及额外的功能。

你的拇指法则是什么？

这有什么编程原则吗？

奖励：这是我的意思是ReadOnlyCollection 或 IEnumerable 用于公开成员集合的示例？

我已经编码了几年，但仍然觉得我的知识还不够广泛，无法成为一名专业人士。我研究过一些与设计模式相关的书籍，但我知道还有很多其他书籍。

那么有人可以列出您认为学习成为更好的程序员和更专业的人的模式和原则吗？

我工作的编程语言：C#、Ruby、Javascript。

我在数据库中有两个表

• FuelStation（fuel_station_id：int（PK），fuel_station_name：varchar，fuel_brand_id：int（FK））
• FuelBrand（fuel_brand_id：int（PK），fuel_brand_name：varchar）

正如我们所看到的，两个表都是通过链接的。外键（fuel_brand_id）

现在，我想设计一个与上述数据模型相对应的对象模型，但我很困惑从以下两种方法中使用哪种方法：

• 是否只制作一个班级FuelStation并String在FuelStation班级中存储燃料品牌。

或者

• 做两个类：FuelStation和FuelBrand。然后将它们与多对一关系相关联，因为一个加油站将只有一个燃料品牌，但一个燃料品牌可以有多个加油站。

Q1。哪种方法更好？

Q2。每种方法的优缺点是什么？

据我所知：

方法 2 的优点

• 它使我们的对象模型更加精细。

• 会计。根据良好的设计原则，我们的对象模型必须至少与关系模型一样精细。方法2遵循该原则

方法 1 的优点

• 无需为每个FuelStation为FuelBrand创建单独的对象

使用虚拟方法是否违反LSP （ SOLID原则的 L 部分）或有一些例外？

在此先感谢，萨格哈·阿亚兹