问题标签 [software-design]

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

几个月前，我参加了由一家独立软件开发公司的两位代表主持的演讲。它主要是关于良好的软件设计和实践。

这两个人主要谈论 Java，我记得他们说过，在某些情况下使用 getInstanceOf() 代替构造函数是非常好的做法。它与总是从不同的类而不是构造函数调用 getInstanceOf() 以及它是如何在更大规模的项目中更好的方法有关。

正如你所看到的，我现在记不太清了：/但我记得他们使用的论点非常有说服力。我想知道你们中是否有人遇到过这样的设计，你会说它什么时候有用？还是你认为根本不是？

我负责一个小组项目的以下任务：

a) 设计/绘制架构上下文图
b) ACD 描述
c) UML 部署图

UML 部署图没有问题，因为在线上有大量直接的资源，但 ACD 并非如此。

我需要有关 ACD 是什么以及如何绘制 ACD 的资源。

ACD 是否还有其他名称，例如体系结构上下文图，例如体系结构互连图或操作系统图？我在谷歌搜索中不断遇到相似的名字但不同的图表......

我需要在我的团队中介绍基本的设计原则。我正在寻找不仅限于面向对象设计原则的书籍。它可以涵盖模块化、信息隐藏等概念。仅供参考 - 我们团队中所有项目的实现语言都是 C。

在一般意义上的 MVC 中，View 和 Controller 的关系一般预期是 M:1 吗？也就是说，许多视图会使用同一个控制器？但是一个视图不会使用很多不同的控制器吗？

或者，我应该能够与任何控制器交换任何视图并让一切正常吗？我此时看到两者之间存在相当紧密的依赖关系，因此这不适用于我当前的布局......

我正在尝试为课堂项目设计一些东西，但我不确定如何组织/设计我的视图和控制器。

更新：到目前为止我收到的答案是有帮助的，但不是确定的。让我们稍微扩展一下我的问题。回想起来，一个重要的方面是模型可以改变（策略模式*） 在一个实例中，模型可以创建一个数据库。在另一种情况下，它可以从数据库中读取。我最初的设计目标是获得一个能够处理所有模型的统一（尽管简单）视图。

*我读到（在这里）控制器可以看作是一种策略模式的实现。我的模型将以类似但独立的方式实现。

这是该概念的快速（不完整）类图（鉴于更新的信息）：

我的 MVC 实现概念的类图 http://theopensourceu.com/wp-content/uploads/2010/02/MVC-2334703.png

当我阅读有关软件开发的文章时，我经常听到“干净的界面”这个词。人们谈论 API 和类的干净接口。

你如何定义“干净的界面”？是否有设计具有干净界面的系统的指南？

有几次我在工作面试和不太正式的环境中被问及我的软件设计方法。总会出现很多流行语：瀑布模型、敏捷开发、设计模式、UML、测试驱动开发、需求文档、用户验收测试等等等等，无穷无尽。

我的回答总是最好的方法取决于手头的项目。将瀑布模型与使用 UML 图的设计规范文档一起用于 3 页小册子网站可能是矫枉过正。同样，直接跳到生命支持控制系统上敲定代码也不是一个好主意。

在很短的时间内，提问者会开始在他们的眼中看到这种可疑的表情，因为他们开始思考“他不会给出直接的答案，因为他不理解这些概念，一定是个牛仔”。我发现最好只讨论“正式的”软件工程过程，遵循以下原则：始终使用瀑布模型（将其称为 SLC 以获得额外的分数），收集 50 页的需求文档，将其变成 100 页大量使用 UML 和设计模式的规范文档，6 个月的代码锤炼...

所以我的困惑是我应该使用什么方法听起来令人信服？谈谈我在不同项目上的经历还是反刍萨默维尔？

假设 Stackoverflow 提供 Web 服务，您可以在其中检索特定用户提出的所有问题。从用户 A 获取所有问题的请求可能会导致以下 json 输出：

如果我想以任何我想要的方式操作和呈现数据，将其转储到本地数据库中是否明智？在某些时候，我还想检索每个问题的所有答案并将它们存储在本地数据库中。

我在想的工作流程是：

1. 用户登录。
2. Web 服务检索登录用户提出的所有问题，将它们转储到本地数据库中。
3. 用户想要特定问题的所有答案，另一个 Web 服务进行检索并将它们转储到本地数据库中。
4. 用户注销后，从本地数据库中删除该用户的所有问题和答案。

我总是会再次遇到关于将业务逻辑放置在何处的讨论：在应用程序代码中的业务层内或在存储过程方面在 DB 中。我个人倾向于第一种方法，但我想先听听你的一些意见，不要用我的个人观点影响你。我知道不存在一刀切的解决方案，它通常取决于许多因素，但我们可以讨论一下。

顺便说一句，我们在 Web 应用程序的上下文中（拥有一个 Oracle DB），我们目前的方法是拥有

• UI 层，它接受 UI 输入并执行第一个客户端验证
• 具有许多服务类的业务层，其中包含业务逻辑，包括对用户输入的验证（服务器端）
• 数据访问层，它从数据库调用存储过程以执行持久性/读取操作

然而，许多人倾向于根据存储过程将业务层的东西（尤其是关于验证）移到数据库中。

你怎么看待这件事？我想讨论一下。

在阅读设计模式时会偶然发现这句话。

但是我不明白，谁能给我解释一下？