Questions tagged «patterns-and-practices»

这一直困扰着我一段时间。 例如，我们有一个REST API，它为系统提供基本内容，并使用和生成JSON。在此终结点处，它会生成指向图片和描述的URL，并且可以这样找到：// localhost / myApi / pictures / 1 { id: 1, description: "This is a pretty picture of a daisy", URL: <OUR URL> } 现在，OUR_URL应该指向API上的某个位置，例如// localhost / myApi / files / pictures / 1，该位置返回JPG（API后面的应用程序读取文件的物理内容，然后将其流回客户端）。显然，这与生成JSON响应的其余API不同，并且读取和流式传输实际文件会产生开销。 另外，OUR_URL应该指向REST服务范围之外的URL，因此//localhost/files/pictures/1.jpg可以直接在其中读取文件。 所以问题是： RESTful API应该能够返回文件还是仅返回一个位置？

12 rest  patterns-and-practices 

我们有一个系统，通过该系统，可以使用通用方法获得一次数据库连接，并在整个要使用的相关类中传递数据库连接。有人怀疑将数据库连接作为参数传递给不同的类会导致问题，因此我在这里检查是否确实可行，并且还有更好的模式吗？ 我知道有一些ORM工具可以实现持久性，但我们还不能介绍。 欢迎任何反馈，谢谢。

11 java  database  patterns-and-practices 

我这周要参加软件模式考试，我们要学习的主题之一是传出和传出耦合。 我了解，如果封装依赖于许多其他类型，则封装的Ce（有效耦合）较高。 例如： class Car{ Engine engine; Wheel wheel; Body body; } 该类具有较高的传出联轴器，因为它取决于引擎，车轮和车身类型。 如果“ Wheel”类型依赖于其他几个包装（汽车，飞机，自行车），则Ca（费伦特耦合）会较高。 我们考试中可能出现的问题之一是，何时传出/传出耦合好坏？这在我看来很奇怪，因为从逻辑上讲，程序需要具有高传入/传入耦合的包/类。 有没有人举例说明何时/何处高传出或传入耦合好/不好？ 谢谢 ！

11 design-patterns  patterns-and-practices  coupling 

我有一个类：A这是一个综合了一些更小的类，的B，C和D。 B，C和D实现接口IB，IC和ID分别。 由于A支持的所有功能B，C并且D，A器具IB，IC并ID为好，但不幸的是这导致了大量的重路由在执行A 像这样： interface IB { int Foo {get;} } public class B : IB { public int Foo {get {return 5;}} } interface IC { void Bar(); } public class C : IC { public void Bar() { } } interface ID { string Bash{get; set;} } public …

11 c#  design-patterns  patterns-and-practices  composition 

几乎可以肯定，使用我的jar的任何Java项目都将对另一个jar附加依赖，我的jar也将其作为依赖项。 问题是，其他jar有多个版本。 在您项目的第二个jar版本与第二个jar版本不同的情况下，如何避免出现任何问题？ 我不希望我的用户有多余的麻烦来做一些花哨的类加载技巧来添加我的jar。 我是否应该为该通用依赖项的每个可能版本制作一堆不同版本的jar？然后，您只需选择使用与您刚碰到的第二个jar版本相同的jar版本即可？ 有没有更聪明的方式来处理此问题，并使人们更轻松地使用我的jar，而不会发生冲突？

10 java  patterns-and-practices  versioning  project-structure  dependencies 

我正在用Typescript编写游戏，并决定继续尝试坚持“ 基于接口的编程 ” 的思想，在该思想中，您基于对象的接口而不是实现来编写代码。 我写了很多接口和实现它们的类，然后退后一步，意识到这些类足够简单，以至于我可能永远不需要更改实现，因为实际上只有一种方法可以完成班级确实做到了（Phaser.Sprite以受限方式移动坦克就像坦克一样）。 然后，我记得几年前读过有关YAGNI的想法，这基本上是您不应过度设计代码以包含您可能永远不会使用的东西。 遵循最佳实践，每个类都应该实现一个接口，还是应该将其限制为您希望将来可能替换掉的类？

10 object-oriented-design  interfaces  patterns-and-practices 

在我的新项目中，我决定尝试使用TDD。一开始我就遇到了问题。我想在应用程序中做的第一件事就是赋予从数据源读取数据的能力。为此，我想使用存储库模式。现在： 如果测试是为了真正实现存储库接口，那么我将测试具有数据库访问权限的类，并且我知道应该避免这种情况。 如果测试不是针对存储库模式的真正实现，那么我将进行良好的测试……只是模拟。在这些单元测试中，将不会测试任何生产代码。 我从两天开始考虑这个问题，但仍然无法提出任何合理的解决方案。我该做什么？

10 tdd  patterns-and-practices  repository 

我正在为即将设计的功能寻找图案或体系结构指导。基本上，这是一个具有多个导出目标的导出功能，我正在寻找一种方法，使之足够通用，以便在插入新的导出目标时不需要进行很多核心更改。通过导出目​​标，我只是指的是不同类型的输出，无论是PDF，PowerPoint演示文稿，Word文档，RSS等。我都有一组基本数据，以JSON和XML表示。此数据用于构造图像（使用任何数量或导出类型（例如，PNG，JPG，GIF等），图形，文本表示形式，表格等。 我正在尝试找到一种将所有渲染和布局抽象为某种渲染或布局引擎的方法，该引擎可以处理其他导出目标的添加。任何有关如何解决此问题的帮助/建议/资源将不胜感激。提前致谢。 对于我要实现的目标的图形表示。

10 patterns-and-practices  architectural-patterns 

程序的一部分从数据库中的许多表和列中获取数据进行处理。有些列可能是null，但是在当前处理上下文中这是一个错误。 从理论上讲，这不会发生，因此，如果这样做，则表明数据错误或代码中存在错误。错误具有不同的严重性，具体取决于哪个字段null。也就是说，对于某些字段，应停止处理并通知某人；对于其他字段，应允许该处理继续进行，而仅通知某人。 是否有任何好的架构或设计原则来处理稀有但可能的null条目？ 解决方案应该可以用Java来实现，但是我没有使用标记，因为我认为问题在某种程度上与语言无关。 我的一些想法： 使用NOT NULL 最简单的方法是在数据库中使用NOT NULL约束。 但是，如果原始数据插入比随后的处理步骤更重要，该怎么办？因此，如果插入内容将a null放入表中（由于错误或什至出于某些合理的原因），我不希望插入操作失败。假设程序的更多部分取决于插入的数据，但不取决于此特定列。因此，我宁愿冒险在当前处理步骤而不是插入步骤中出错。这就是为什么我不想使用NOT NULL约束的原因。 天真的取决于NullPointerException 我可以使用数据，就像我期望它始终存在一样（这确实应该如此），并在适当的级别上捕获生成的NPE（例如，以便停止当前条目的处理，而不是整个处理进度） ）。这是“快速失败”的原则，我经常喜欢它。如果这是一个错误，至少我会得到一个已记录的NPE。 但是后来我失去了区分各种丢失数据的能力。例如，对于某些丢失的数据，我可以将其省略，但是对于其他一些数据，应停止处理并通知管理员。 null在每次访问之前进行检查并引发自定义异常 自定义异常可以让我根据异常来决定正确的操作，因此这似乎是可行的方法。 但是，如果我忘记在某个地方检查该怎么办？然后，我还会使用从未有过或很少有期望的空检查（因此绝对不是业务逻辑流程的一部分）使我的代码混乱。 如果我选择这种方式，哪种模式最适合该方法？ 欢迎对我的方法提出任何想法和意见。还有任何更好的解决方案（模式，原理，代码或模型的更好体系结构等）。 编辑： 还有一个约束，因为我使用ORM进行从DB到持久性对象的映射，因此在该级别上执行null检查将不起作用（因为在null不会造成任何危害的部分中使用了相同的对象） 。我添加此内容是因为到目前为止提供的答案都提到了该选项。

9 design-patterns  object-oriented-design  database-design  patterns-and-practices  null 

ycombinator最近发表的一篇文章列出了关于优秀程序员原理的评论。 #7.优秀的程序员：我优化代码。更好的程序员：我构造数据。最佳程序员：有什么区别？ 承认主观和有争议的概念-有人对这意味着什么有立场吗？是的，但是我以后想根据自己的想法编辑这个问题，以免预先回答这些问题。

9 programming-practices  source-code  data  patterns-and-practices