Questions tagged «design»

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 从我所阅读和看到的内容来看，程序员的陈规定型观念不能很好地完成图形处理。但是，我喜欢编程（最好是OOP，PHP，C ++，Objective-C），并且不能否认我在Web设计中具有独特的品味，而其他人则说我做得很好（CSS）。我对自己说：“嘿，等等，我是一名程序员-我怎样才能设计好？”。问题是：是否可能擅长编程和设计？这里有人有同样的感觉吗？ 作为记录：我创建的实际图像在以前被朋友多次称为程序员艺术

22 design  stereotypes 

伪代码可帮助我们以与语言无关的方式理解任务。将伪代码创建作为开发生命周期的一部分是最佳实践还是建议的方法？例如： 识别并拆分编码任务 编写伪代码 得到[PL或TL]的批准 基于伪代码开始编码 这是建议的方法吗？它在行业中实践吗？

22 design  pseudocode 

对于某些开发人员而言，松散耦合是精心设计的软件的圣杯。当它使代码在可预见的将来可能发生的变化面前更加灵活，或者避免代码重复时，这无疑是一件好事。 另一方面，松散耦合组件的努力增加了程序中的间接访问量，从而增加了程序的复杂性，常常使程序难以理解，并常常使效率降低。 您是否认为在没有任何松散耦合用例的情况下专注于松散耦合（例如避免代码重复或计划在可预见的将来可能发生的更改）是一种反模式？松散的联轴器能否落入YAGNI的保护伞下？

22 design  design-patterns  object-oriented 

我的公司目前正在努力采用微服务架构，但是在此过程中我们遇到了一些麻烦（令人震惊）。我们面临的主要争论点之一是如何在我们的不同服务之间传递大量数据。 作为背景知识，我们有一个文档存储，可作为我们可能需要在公司范围内处理的任何文档的存储库。与所述商店的交互是通过服务完成的，该服务为客户提供了唯一的ID和流文档的位置。以后可以通过使用提供的ID进行查找来访问文档的位置。 问题是-对于我们所有的微服务而言，是否为了与文档进行交互而接受此唯一ID作为其API的一部分有意义吗？在我看来，这本质上是错误的-服务不再是独立的，而是依赖于文档存储的服务。尽管我确实承认这可能会简化API设计，甚至可能会带来一些性能提升，但所产生的耦合效果远不止于此。 有谁知道彩虹独角兽（Netflix，亚马逊，谷歌等）如何处理服务之间的大文件/数据交换？

22 design  rest  xml  microservices 

在我读过的不同设计书中，有时会着重强调类必须具有的方法数量（考虑OO语言，例如java或C＃）。这些书中报道的例子通常非常简洁明了，但很少涉及“严重”或复杂的案例。 但是范围似乎在5到8之间。 在一个项目中，我开发了一个类别为“ Note”的类，其属性为属性：Title，Desctiption，CreateDate等。然后是一些基本方法，例如：getRelations（如果将注释分配给了不同的文档），getExpiryDate等。 但是，在开发应用程序时，需要更多的功能，因此需要更多的方法。 我知道，一个类拥有的方法越少，耦合就越松散。就模块化和可重用性而言，这确实是一个很好的优势，而且更易于编辑。 顺便说一句，如果在我们的上下文中不需要（甚至没有意义）创建子类，并且所有需要的功能都与该类相关，那么我们可以进一步附加几个方法？ 我同意拥有15种以上的方法，然后可能需要重新设计。但是即使在那种情况下，如果删除某些方法或继承不是一个选择，那将是正确的方法吗？

22 design  programming-practices 

我正在尝试编写一个“标准”商业网站。所谓“标准”，是指该站点在前端，后端（用于处理内容）运行常规的HTML5，CSS和Javascript，并在数据库中运行MySQL。这是一个基本的CRUD网站：前端几乎可以存储数据库中存储的所有内容；不论用户输入什么，后端都会将其写入数据库并进行一些处理。就像大多数网站一样。 创建我的Github存储库以开始编码时，我意识到我不了解前端后端和API之间的区别。解决我的问题的另一种方式是：API进入这张图片的位置是什么？ 我将列出更多详细信息，然后列出我要提出的问题-希望这会使你们对我的实际问题有更好的了解，因为我很困惑，以至于我不知道要问的具体问题。 一些更多的细节： 我想尝试Model-View-Controller模式。我不知道这是否会改变问题/答案。 该API将是RESTful 我希望后端使用自己的API，而不是允许后端作弊并调用特殊查询。我认为这种风格更加一致。 我的问题： 前端是否调用调用API的后端？还是前端只是调用API而不是调用后端？ 后端是否仅执行API，并且该API将控制权返回给后端（其中后端充当最终的控制器，委派任务）？ 建议使用详尽详尽的答案来解释API与前端后端的作用。如果答案取决于编程模型（除Model-View-Controller模式以外的模型），请描述API的这些其他思考方式。谢谢。我很困惑

22 design  web-development  architecture  terminology 

我正在创建新的业务Web应用程序，并且想要实现： 使用各自领域的最佳技术。我想要具有可靠ORM的可靠后端框架。我想要最先进的SPA（单页应用程序）框架，并为前端应用程序使用最新的HTML和Javascript功能 公开后端实体和业务服务以供不同类型的应用程序使用，例如，Web应用程序，移动（Android）以及可能的其他类型（智能设备等） 因此，为了满足这两个要求，我倾向于将我的应用程序完全隔离在后端和前端应用程序中，并使用REST API（JSON）来组织它们之间的通信。这是合理的方法吗？ 这种分离并不是显而易见的设计解决方案，因为许多Web应用程序技术都集成了视图层，其中服务器端应用程序或多或少地控制视图的生成并部分处理视图的响应（例如，带有视图层的SpringMVC，带有视图的PHP Yii Java JSF / Facelets层将其组件的状态完全保存在服务器上）。因此-周围有许多技术提出了更强的耦合性，并有望缩短开发时间和提供更标准的路径。所以-在开始以未广泛使用的方式使用技术时，我必须谨慎。 据我了解，完全分离的SPA前端通常是由使用第三方API引起的。但是，当后端和前端都由一家公司开发时，这种去耦声音设计是否有效？ 我目前选择的技术是Java / Spring后端和Angular2 / Web组件/聚合物前端-如果允许我这么说的话。但这与这个问题无关，因为这个问题是关于一般设计而不是具体技术的选择？

21 design  rest  api  front-end  backend 

我正在处理一个处理请求的项目，该请求有两个组件：命令和参数。每个命令的处理程序非常简单（<10行，经常<5）。至少有20条命令，可能会超过50条。 我提出了一些解决方案： 一个大的开关/ if-else命令 命令到功能的映射 命令到静态类/单的映射 每个命令都进行一点错误检查，唯一可以抽象的位是检查为每个命令定义的参数数量。 什么是解决此问题的最佳解决方案，为什么？我也愿意接受我可能错过的任何设计模式。 我为每个提出了以下优点/缺点列表： 开关 优点 将所有命令保持在一个功能中；由于它们很简单，因此使其成为可视化查找表 不需要使用大量只会在一个地方使用的小功能/类来弄乱源代码 缺点 很长 难以以编程方式添加命令（需要使用默认大小写进行链接） 映射命令->功能 优点 一口大小的小块 可以以编程方式添加/删除命令 缺点 如果在线完成，则外观与开关相同 如果没有在线完成，很多功能只能在一个地方使用 映射命令->静态类/单例 优点 可以使用多态来处理简单的错误检查（仅3行，但仍然） 与map类似的好处->功能解决方案 缺点 很多非常小的班级将使项目混乱 实施并非都在同一个地方，因此扫描实施并非易事 额外说明： 我正在用Go编写此代码，但是我认为解决方案不是特定于语言的。我正在寻找一个更通用的解决方案，因为我可能需要用其他语言做一些非常相似的事情。 命令是字符串，但是如果方便的话，我可以轻松地将其映射为数字。函数签名类似于： Reply Command(List<String> params) Go具有顶级功能，而我正在考虑的其他平台也具有顶级功能，因此第二个和第三个选项之间的区别。

21 design  design-patterns  map  switch-statement 

在我的大多数项目中使用Hibernate大约8年之后，我进入了一家不鼓励使用Hibernate并希望应用程序仅通过存储过程与DB进行交互的公司。 在执行了几周之后，我无法为我将开始构建的应用程序创建丰富的域模型，并且该应用程序看起来像（可怕的）事务脚本。 我发现的一些问题是： 由于存储过程仅加载最少的数据，因此无法导航对象图，这意味着有时我们具有具有不同字段的相似对象。一个示例是：我们有一个存储过程来从客户那里检索所有数据，另一个存储过程是从客户那里检索帐户信息以及一些字段。 许多逻辑最终出现在帮助器类中，因此代码变得更加结构化（实体用作旧的C结构）。 令人讨厌的脚手架代码，因为没有框架可以从存储过程中提取结果集并将其放入实体中。 我的问题是： 有没有人遇到过类似情况，并且不同意存储过程方法？你做了什么？ 使用存储过程有实际好处吗？除了“没有人可以发布弃用表”这一愚蠢的观点之外。 有没有一种使用存储过程来创建富域的方法？我知道有可能使用AOP将DAO /存储库注入到实体中，从而能够导航对象图。我不喜欢这个选项，因为它非常接近伏都教。 结论 首先，谢谢大家的回答。我得出的结论是，ORM无法启用Rich Domain模型的创建（如某些人所述），但是它确实简化了（通常是重复的）工作量。以下是对结论的更详细说明，但并不基于任何硬数据。 大多数应用程序请求并将信息发送到其他系统。为此，我们在模型术语（例如，业务事件）中创建抽象，然后域模型发送或接收事件。事件通常需要来自模型的一小部分信息，而不是整个模型。例如，在一家网上商店中，支付网关会向用户收取一些用户信息和总计费用，但不需要购买历史记录，可用产品和所有客户群。因此，该事件具有少量特定的数据集。 如果我们将应用程序的数据库作为外部系统，则需要创建一个抽象，以允许我们将域模型实体映射到数据库（如NimChimpsky所述，使用数据映射器）。明显的区别是，现在我们需要为每个模型实体手工映射到数据库（旧模式或存储过程），而且还有一个痛苦，因为两个实体不同步，所以一个域实体可能会部分映射数据库实体（例如，仅包含用户名和密码的UserCredentials类映射到具有其他列的Users表），或者一个域模型实体可能映射到多个数据库实体（例如，如果存在一对一一张表上的映射，但我们只想将所有数据归为一类）。 在只有几个实体的应用程序中，如果不需要横向实体，那么额外的工作量可能很小，但是当有条件需要横向实体时，额外的工作量就会增加（因此，我们可能想实现某种“懒惰”正在加载”）。随着应用程序具有更多实体的发展，这项工作只会增加（我感觉它会非线性地增加）。我在这里的假设是，我们不会尝试重塑ORM。 将数据库视为外部系统的一个好处是，我们可以围绕以下情况编写代码：需要运行两种不同版本的应用程序，其中每个应用程序都有不同的映射。在连续交付生产的情况下，这变得更加有趣……但是我认为ORM在较小程度上也是可行的。 我将不考虑安全性，因为开发人员即使没有访问数据库的权限，也可以通过注入恶意代码来获取存储在系统中的大部分（即使不是全部）信息。我不敢相信我忘了删除记录客户信用卡详细信息的行，亲爱的上帝！）。 小更新（6/6/2012） 存储过程（至少在Oracle中）阻止执行诸如零停机时间连续交付之类的操作，因为对表结构的任何更改都将使过程和触发器无效。因此，在更新数据库期间，应用程序也将关闭。Oracle 为这种称为基于版本的重新定义提供了解决方案，但是我向该功能询问过的少数DBA提到，该功能实施得很差，他们不会将其放入生产数据库中。

21 java  design  orm  stored-procedures  domain-driven-design 

此问题是从Stack Overflow 迁移而来的，因为可以在Software Engineering Stack Exchange上回答。 迁移 8年前。 我发现自己在努力了解该原理是什么，为什么对语言设计如此重要。 基本上，它指出，对于expr语言中的每个表达式，都应与此结构完全相同： (function () { return expr; })() 另外，我听说Ruby遵循了这一原则，而Python则没有。我不明白为什么这是真的，或者根本不是真的。

21 design  language-agnostic 

已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗？更新问题，以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 在马丁·福勒（Martin Fowler）的书《重构：改进现有代码的设计》问世之前，我们习惯将对代码的主要更改称为“重新架构”，而将较小的更改称为“清理”。IMO，重构技术都是常识/我们一直在做的显而易见的事情。 您认为重构曾经是新事物吗？也许只是一种诱使管理人员分配时间进行代码清理的方法？

21 design  refactoring  terminology 

允许对数据库条目（数据）进行版本控制的方法有哪些？ 考虑一下内容管理系统还原文章更改的能力。 他们的优点/缺点是什么？

21 design  database 

过去，我已经阅读了很多有关该主题的文章，并观看了Bob叔叔的有趣的演讲。但是，我始终很难正确地构建桌面应用程序，并区分在UI端和逻辑端应该承担哪些责任。 良好做法的简短摘要就是这样的。您应该设计与UI分离的逻辑，以便无论哪种后端/ UI框架，都可以（理论上）使用库。基本上，这意味着UI应该尽可能地虚设，繁重的处理应该在逻辑端进行。否则，我可以在控制台应用程序，Web应用程序或桌面应用程序上真正使用我的漂亮库。 此外，鲍伯叔叔建议对使用哪种技术会给您带来很多好处（良好的界面）的不同讨论，这种递延概念使您可以将经过良好测试的实体高度去耦，这听起来不错，但仍然很棘手。 因此，我知道这个问题是一个相当广泛的问题，已经在整个互联网上讨论了很多次，还以大量好书进行了讨论。因此，为了从中获得好处，我将发布一个非常小的虚拟示例，尝试在pyqt上使用MCV： import sys import os import random from PyQt5 import QtWidgets from PyQt5 import QtGui from PyQt5 import QtCore random.seed(1) class Model(QtCore.QObject): item_added = QtCore.pyqtSignal(int) item_removed = QtCore.pyqtSignal(int) def __init__(self): super().__init__() self.items = {} def add_item(self): guid = random.randint(0, 10000) new_item = { "pos": [random.randint(50, 100), …

20 design  python  mvc  gui  coupling 

我认识的大多数（如果不是全部）IT人员相信，在编码之前使用UML或其他类型的图对软件进行建模是有益的。（我的问题不是专门关于UML的，它可以是软件设计的任何图形或文本描述。） 我不太确定。主要原因是：代码没有说谎。它由编译器或解释器检查。希望它具有自动化测试，并且需要通过静态代码分析。如果一个模块不能与另一个模块正确连接，则在代码中通常很明显，因为会收到一条错误消息。 使用图表和其他文档无法完成所有这些操作。是的，有些工具可以检查UML，但是到目前为止，我所看到的一切都非常有限。因此，这些文档往往不完整，不一致或简单。 即使图本身是一致的，您也不能确定代码是否实际实现了它们。是的，有代码生成器，但是它们从不生成所有代码。 我有时会觉得对建模结果的痴迷是因为这样的假设，即代码不可避免地必须是一些不可理解的混乱，而建筑师，设计师或其他掌握高薪的高薪人士则不必处理这些混乱。否则，它将变得太昂贵。因此，所有设计决策都应远离代码。代码本身应该留给能够写（甚至可以读）但不必处理其他任何东西的专家（代码猴子）。当汇编程序是唯一的选择时，这可能很有意义，但是现代语言允许您以很高的抽象水平进行编码。因此，我真的不再需要建模。 我缺少用于建模软件系统的哪些论据？ 顺便说一句，我相信图是一个伟大的方式来记录和沟通软件设计的某些方面，但是，这并不意味着我们应该立足于他们的软件设计。 澄清： 由于不清楚，这个问题被搁置了。因此，让我添加一些解释： 我在问使用将软件建模的（非代码）文档作为有关软件设计的主要事实来源是否有意义。我没有想到从这些文档中自动生成很大一部分代码的情况。如果是这种情况，我会将文档本身视为源代码，而不是模型。 我列出了此过程的一些缺点，这使我想知道为什么有这么多人（以我的经验）认为它是进行软件设计的首选方法。

20 design  architecture  uml  modeling 

我正在实现一个接收消息的IRC机器人，并且正在检查该消息以确定要调用的函数。有更聪明的方法吗？在我掌握了20条命令之后，它似乎很快就变得一发不可收拾。 也许有一种更好的抽象方法？ public void onMessage(String channel, String sender, String login, String hostname, String message){ if (message.equalsIgnoreCase(".np")){ // TODO: Use Last.fm API to find the now playing } else if (message.toLowerCase().startsWith(".register")) { cmd.registerLastNick(channel, sender, message); } else if (message.toLowerCase().startsWith("give us a countdown")) { cmd.countdown(channel, message); } else if (message.toLowerCase().startsWith("remember am routine")) …

20 java  design  abstraction