问题标签 [software-design]

我即将开始我在桌面软件设计方面的第一次尝试，我想知道我可以随身携带的网页设计核心原则背后的任何相似之处，或者差异、书籍或文章等？

非常感谢任何帮助。

我看到 DTO 类型在域模型的类型中创建并在类型之间传递。这是好习惯吗？

我一直认为 DTO 主要用于上下文边界（即对象图的边缘）以解耦上下文实现（例如在域/ui 边界）。

例如，当马克·扎克伯格在一次采访中说他在 2 周内写了 Facebook 时，他究竟（或至少大致）写了什么？我想象大型数据库或树中的“用户”对象能够协商到其他用户对象的链接，但我想知道树的总体管理器是如何工作的。当用户登录时，“主”程序是否会查找该用户的对象并派生一个进程以在用户登录时与其他用户对象进行交互？谢谢。

通常，在软件设计中，当数据库或文件等资源出现问题或错误时，首选以下哪个选项？

1. 显示错误消息
2. 不要显示错误消息并表现得好像资源是空的（例如，不要填充 GUI 组件）]

例如，用户应该看到他们抱怨的空 DataGrid，还是应该有错误消息？哪个更好？

我看到了这个问题：如果“实用程序”类是邪恶的，我应该把我的通用代码放在哪里？

我想，为什么实用程序类是邪恶的？

假设我有一个包含几十个类的域模型。我需要能够 xml-ify 实例。我是否在父级上创建一个 toXml 方法？我要创建一个 MyDomainXmlUtility.toXml 辅助类吗？这是业务需求跨越整个领域模型的情况——它真的属于实例方法吗？如果应用程序的 XML 功能上有一堆辅助方法呢？

我正在从事一个项目，其主要设计指导原则是可扩展性。

我通过定义一个元类来实现一个插件系统，该元类使用类方法注册任何加载的插件的类名（每种类型的插件都继承自核心代码中定义的特定类，因为有不同类型的插件在应用程序）。基本上这意味着开发人员必须将他的类定义为

并且主程序将知道他的存在，因为PieChart将包含在可用的注册插件列表中ChartPluginAncestor.plugins。

作为类方法的挂载方法，所有插件在其类代码加载到内存时都会被注册（甚至在该类的对象被实例化之前）。

该系统对我来说足够好™（尽管我总是对如何改进体系结构的建议持开放态度！）但我现在想知道管理插件文件的最佳方法是什么（即包含插件的文件在哪里以及如何应储存）。

到目前为止，我正在使用 - 出于开发目的 - 我称之为“插件”的包。我将所有包含插件类的 *.py 文件放在包目录中，我只是import plugins在 main.py 文件中发出，以便所有插件都能正确安装。

编辑：杰夫在评论中指出，import plugins包的各个模块中包含的类不会很容易获得（我没有意识到这一点 - 出于调试目的 - 分别导入每个类from plugins.myAI import AI）。

然而，这个系统只有在我开发和测试代码时才好用，因为：

• 插件可能带有自己的单元测试，我不想将它们加载到内存中。
• 所有插件当前都加载到内存中，但确实有某些插件是相同功能的替代版本，所以你真的只需要知道你可以在两者之间切换，但你只想加载你选择的那个从配置窗格。
• 在某些时候，我会希望有一个安装插件的双重位置：一个系统范围的位置（例如在某处/usr/local/bin/）和一个特定于用户的位置（例如在某处/home/<user>/.myprogram/）。

所以我的问题真的是——也许——三个：

1. 插件容器：我的目标最明智的选择是什么？单个文件？包？.py 文件的简单目录？）
2. 识别插件的存在而不必加载（导入）它们：使用 Python 内省来做到这一点的聪明方法是什么？
3. 将插件放置在两个不同的位置：是否有标准的方法/最佳实践（至少在 gnu/linux 下）可以做到这一点？

我有一个应用程序从第三方接收大部分数据。其中一组数据是事务列表。我无法写入此服务，但我想向该数据添加更多信息，以便在我自己的应用程序中使用。我打算使用带有扩展信息的 SQL 表来做到这一点。

问题是第三方数据没有从他们这边返回记录标识符。这意味着我不能使用第三方主键作为我的附加数据的主键。如果可以的话，我显然只是使用该密钥并存储扩展数据。

例如，返回的数据是：

客户 ID 在此表中不是唯一的，但是可以保证其余信息（整体而言）是唯一的。

我想添加其他数据。例如：

我玩弄了使用作为所有其他信息散列的主键的想法，但据我所见，查询该数据的效率非常低。例如，我可能想在屏幕上显示 100 笔交易。这将需要从第三方检索数据，对每条记录进行散列处理，并使用这 100 个键之一查询我的本地数据库以获取所有数据。

有没有人有什么建议？

我想要一些使用 uml 学习软件设计的资源（案例研究，书籍）

我的类有以下构造函数

可以看出，它有6个参数。看到这段代码，我的一位前辈说，与其传递 6 个参数，不如传递一个配置对象。

我以这种方式编写代码是因为最近我读到了“依赖注入”，它说“类必须要求他们想要什么”。所以我认为传递配置对象会违反原则。

我对“依赖注入”的解释正确吗？或者 我应该听从前辈的建议吗？

我想知道人们在多用户应用程序中为用户分配权限和业务逻辑之间的界限在哪里。

例如，如果用户有权访问多辆汽车，您是直接通过用户类分配这些权限，方法是将它们添加到用户的汽车对象集合中，还是在 ACL 中分配它们并使用 ACL 检索用户可以访问的汽车列表？

对于何时应该将 ACL 用于此类事情以及何时应该成为业务逻辑的一部分，是否有任何指导方针？