标签: software-design

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

我们正在开发一个面向服务的大型多层应用程序,必须从头开始设计.现在我们需要开始编程,并尝试组装第一块砖.

问题是从哪里开始？有人建议我们应该从设计持久数据模型开始,这将提供更清晰的视图.这是一个好方法吗？

编辑为Suirtimed

这里没有太多的敏捷文化.这是一个SOA样式项目,使用WCF,SQL Server,实体框架(使用POCO生成器用于域对象),ASP MVC和Workflow Foundation.我们是一个由4名开发人员组成的团队; 技术合理(但不是专家).

我正在研究遗留框架,显然有两个库是相互依赖的.我的意思是libA从中导入libB,然后libB从中导入libA.首先我认为这是一个糟糕的设计,但为什么有人会做这样的事情呢？相反,哪些条件可以导致某人写这个？

编辑:

每个库都依赖于另一个库中的类,因此它们会导入包并jar在其构建路径中包含其他库.

我在这里遇到一种情况，我的类中需要一个计时器，它根据时间间隔调用一些方法。

在正常情况下，我会实例化计时器并在构造函数本身中配置它。但我想以依赖注入的方式做到这一点。在构造函数中传递计时器很容易，但为了将方法绑定到其 OnTimeElapsed 很棘手，实例化该类的工厂是否应该配置此计时器？我应该如何继续而不违反依赖注入原则。

谢谢

编辑1

1. 根据 Misko发布的视频
2. 在他的其他演讲中（永远不要测试您的框架：此处的.net框架）
3. 在他的代码审查指南中，除了构造函数中的字段分配之外所做的任何事情都被认为是不好的。

我实现依赖注入的主要目标是，我需要在特定的运行时间内对方法是否被调用进行单元测试。

所以我的问题是：我应该在哪里绑定 OnTimerElapsed 事件？我真的想在这里测试计时器吗？我似乎在这里迷路了

请帮忙。

我正在处理几个活动图，其中描述了有关客户端 - 服务器应用程序的不同用例。可以使用最终节点来指定用例的结束而不是流程的结束吗？例如，在登录用例结束时，服务器和客户端都不会结束，但它们会继续执行其他交互。在这种情况下我必须使用最终节点吗？

谢谢。

好像是 java.util.regex.Pattern 和 java.util.regex.Matcher 是聚合关系，我觉得。而java API 说在下面使用它们。

Pattern p = Pattern.compile("a*b");
Matcher m = p.matcher("aaaaab");
boolean b = m.matches();

为什么 Pattern 和 Matcher 是通过静态方法初始化的？放置这种可能性有什么好处？直接在我的来源上对呼叫创建者不利吗？

以下是我正在进行的项目的简化.

我们有Talker niceTalker谁说"早上好!我的名字是乔".然后我们有一个schitzophrenic rudeTalker,谁说"他就是我".

我花了一段时间来理解代码的作用.对我来说,这似乎是压倒一切的非常复杂的方式Talker小号talk()方法.更多,TalkModifier用作命令模式中的命令(未示出).

为什么采用这种方法,而不是通过继承说多态？这是一个已知的模式,哪一个？

public interface Talker {
    String getName();
    void talk();
}

-

public interface TalkModifier {
    public Talker modify(Talker talker);
}

-

class NiceGuy implements Talker {
    @Override
    public void talk() {
        System.out.println("Good morning! My name is " + getName() +".");
    }
    @Override
    public String getName() {
        return "Joe";
    }
}

public class Application {

    public static void main(String[] …

我看到有人建议将 MVC 与洋葱架构一起实施。但两者如何共存呢？它们不是两种不同的架构吗？例如，Onion设计中的Controller在哪里？

我理解不止一种设计模式的组合，因为它们服务于不同的目的（行为、创建等），并且可以在系统的不同模块中独立实现，但我不知道如何实现两种不同的架构。

我正在制作一个基于 .Net 的应用程序的结构。目前，我使用的是 MVC 5。以下是系统不同组件的详细信息。\n
1. 数据库\xe2\x80\x93 这是底层数据库，将包含数据\n
2. OData API \xe2\x80\ x93 此 API 将与数据库交互，并且仅执行与数据库相关的操作 (CRUD)。我希望这个 API 成为访问和操作数据的唯一平台。它将提供通过不同方式（IQueryable、SQL 查询、存储过程）检索数据的功能。\n
3. 业务服务\xe2\x80\x93 它由两部分组成。引擎和API。引擎中将包含业务逻辑，其中可能包括业务规则，例如 WorkflowEngine 将处理所有工作流操作。驻留工作流程操作（CRUD 操作）和非常驻工作流程操作（提交、批准、发回）。API将在UI和引擎之间进行通信。然后引擎将运行业务逻辑并与 OData 进行通信。BusinessAPI 将是专有 API，对这些 API 的访问将基于订阅（付费访问）。\n
4. UI \xe2\x80\x93 用户界面将基于 MVC，仅与业务 API 交互，并且仅负责显示数据并将数据发送回 BusinessAPI。
\n

它看起来像一个 N 层架构。如果我引入接口，它是否可以与ONION架构相媲美。\n
如何将其转换为 ONION 架构而不影响安全性、可扩展性和性能。\n

我注意到，laravel程序员通常使用特质来在控制器中实现某种类型的依赖注入，而且laravel本身也会使用很多特质来实现对我来说似乎是服务的东西。

我来自symfony，那里的框架本身并没有广泛使用特征，由于这种原因（不是很清晰的设计），我发现使用trait有点奇怪。服务不应该在自己的类中定义吗？将特征用于服务是否可以接受？