design-principles

    2热度

    2回答

    我想了解is-a vs是像是一种关系,我在某处阅读,我们必须尝试遵循设计,以便我们总是有 - 是一种关系,而不是 - 像一个。考虑形状基类和衍生三角形和圆形类的经典例子。所以圆圈是一个分享,三角形也是一个形状。功能显示区域在基类中定义。下面的程序运行良好。 #include "stdafx.h" #include<cmath> #include <iostream> class shape

    0热度

    1回答

    我正在读implementing_the_visitor_pattern_without_recursion从Python的食谱,第三版 The implementation with additional Visit Class修复缺陷the one without it,因为它要求。 “这个配方的一个潜在危险是关于产生节点和非节点值的区别 。在实现中,所有节点 自动遍历。这意味着您不能使用 节

    1热度

    1回答

    请考虑以下情况。 三个应用程序A,B和C必须合作:A是一个外部的第三方应用程序,而B和C是内部应用程序(所以我们可以控制B和C,而不是A)。 B回复A提出的请求,同时使用C和B本身包含的逻辑。将B看作A和C之间的层。 A,B和C有一些基本的共同概念,理解和使用。 假设这里的关键任务是去耦所有的东西,所以如果明天我们想要使用A1而不是A,B和C之间的所有交互都保持固定(并且分别如果我们想用C1代替C

    1热度

    4回答

    我正在看我的一些项目,并将它们与我在github上看到的东西进行比较,我觉得我过度思考。我喜欢OOP,但我觉得我制作的文件太多,班级太多。 例如,在一个小型项目中,我有一个跳棋游戏,我有很多文件可能都会进入一个文件/类。我怎么知道我什么时候想过我的解决方案?这是我的一些文件的样子; |src | |- player.cpp | |- piece.cpp | |- color.cpp | |

    1热度

    2回答

    如果我有一个复杂的任务来解决,我有时最终会遇到一种控制执行的方法。由于空检查,if语句,调用在类型之间映射的方法等等,这种方法可能变得非常长,我努力使它更简单。 实施例1 public class A public string MethodA(string stringA) { var fooResult = _fooService.fooMethod(stringA);

    1热度

    1回答

    以下代码A来自Kotlin for Android开发人员。代码B由我撰写。 这两个不同的代码块的功能是否相同? 代码A class DetailActivity : AppCompatActivity(), ToolbarManager { override val toolbar by lazy { find<Toolbar>(R.id.toolbar) } ...

    1热度

    1回答

    我们正在构建一个使用Realm作为我们的模型/数据库的iOS应用程序,但我们希望设计客户端,以便它可以轻松地适应将来可能发生的REST-ful API中的更改。假设我们正在为适应不同活动的体育竞赛组织开发应用程序。根据正在玩什么运动,每个事件都有不同类型的事件类型。现在API只返回足球,棒球和足球,但将来它可能会扩展到包括篮球。之后它可能会消除棒球。我设计的领域对象,使事件从事件类型使用这样的一对

    1热度

    1回答

    我一直负责为我们公司的内部测试标准和程序开发文档。我一直在做大量的研究并发现了一些很好的文章,但我总是喜欢在这里与社区联系。 这就是说,我的问题是这样的:你如何看待一个拥有非常大的遗留代码库的公司,这是几乎不可测试的,如果在所有可测试的情况下,并试图测试你可以有效地进行测试?你有关于如何为紧密耦合的代码创建一些有用的自动化测试用例的提示吗? 我们所有的新代码都被编写成尽可能松散耦合,我们都为我们新

    0热度

    1回答

    有没有一种方法,我可以要求传入一个函数的对象实现一组核心方法? 例如,我希望能够编写一个总和方法来总结实现'+'运算符的任何可迭代对象。 我初步实现如下 trait addable[T <: addable[T]]{ def +(other: T): T } def sum[T <: addable[T]](items: Iterable[T]) = if(items.i

    1热度

    2回答

    单一职责原则(SRP): - 每个班级都应该承担一个责任。基本上,应该有一个单一的理由来改变。我不确定 最后的声明究竟意味着什么。我的解释是,设计类的方式应该有一个单一的理由来改变,因为每种方法都是一种行为,因此也是一种理由。那是对的吗?如果不是什么确切的原因定义? 考虑一个股票交易所系统,其中大部分开发者提出设计,其中StockService.java同时具有买入和卖出方法。这里将有两方面的原因