标签: decoupling

我在下面的代码中简化并重现了我的问题.我收到的错误是:参数1:无法从'System.Collections.ObjectModel.Collection'转换为'System.Collections.ObjectModel.Collection

导致这个问题的设计决策的一些背景:我已经创建了一个用于处理"IFruit"的Web服务,但由于我理解它们的SOAP和端点绑定的性质,我已经创建了具有IFruit的显式实现的方法.在业务层,为每个特定的水果实现创建一个单独的方法首先会导致大量重复的代码,其次紧密地结合业务和服务层,以便稍后在Web服务中接受新的IFruit类型也需要更改我的代码在业务层(添加冗余代码的另一个副本).这个设计是我过去使用Java成功实现的设计,但C#接口似乎只是与我不同.请指教.

public interface IFruit{
    public string TakeBite();
}

public Apple : IFruit{
    public string TakeBite(){
        return "tasty bite of apple";
    }
}

public void EatFruit(Collection<IFruit> fruits){
    foreach(var fruit in fruits){
        Console.WriteLine(fruit.TakeBite());
    }
}

public void EatApples(Collection<Apple> apples){
    this.EatFruit(apples);
}

我想查看一些非常好的iOS应用程序,看看它们是如何组合在一起的.我已经指定了"完整",因为我对战略中的当前目的比对战术更感兴趣(但希望代码也会在战术上做得很好)."完整"不一定意味着"大".

我自己最初的优先事项是整体设计是可可惯用的(即充分利用Apple为我们提供的东西),并强调类在相关设计约束内尽可能分离.但我对任何能够为特定的公开可用代码库提供充分理由的答案感兴趣,值得仔细研究.

编辑:虽然我主要关注的是应用程序,但图书馆的指导性示例也可能会引起人们的兴趣.

是否有一个nuget包,或其他"标准"包装代码耦合时创建的硬依赖DateTime.Now？

在写我自己之前,我正在寻求相关的指导.虽然这样做是微不足道的,但我宁愿使用存在的东西,如果它已经作为某种程度的标准.

我正在创建一个使用WCF服务与数据源交互的WPF应用程序.我为客户端和WCF服务器使用DI来确保解耦代码,但我不确定如何处理从后端到用户界面的数据传输.

为了保持层分离,数据当前通过几个映射步骤从数据库传输到UI.在服务器端,数据实体映射到域对象,域对象再次映射到服务数据协定.在客户端,WCF代理类映射到视图模型.

一些开发人员声称,在看似相同的类之间"复制"数据会产生维护问题,因为在引入更改时必须更新许多类.相反,他们说你应该跨层使用共享类,因为我们控制客户端应用程序和WCF服务.我也担心所涉及的工作量并看到潜在的性能损失,但另一方面,使用跨层/抽象的共享类可能会产生我看到的紧密耦合.什么是最好的方法？

他们是否矛盾？

解耦是很棒的,很难实现.然而,在大多数应用程序中,我们并不真正需要它,因此我可以设计高度耦合的应用程序,除了明显的副作用之外,它几乎不会改变任何东西,例如"你不能分离组件","单元测试是痛苦的屁股"等

你怎么看？你总是试图解耦和处理开销吗？

我知道C++库应该使用命名空间来避免名称冲突,但是因为我已经不得不:

1. #include 正确的标题(或转发声明我打算使用的类)
2. 按名称使用这些类

这两个参数不要推断命名空间传达的相同信息.现在使用命名空间引入了第三个参数 - 完全限定名称.如果库的实现发生变化,现在我需要改变三个潜在的事情.根据定义,这不是库代码和我的代码之间耦合的增加吗？

例如,查看Xerces-C:它定义了Parser在命名空间内调用的纯虚拟接口XERCES_CPP_NAMESPACE.我可以Parser通过包含适当的头文件,然后导入命名空间using namespace XERCES_CPP_NAMESPACE或使用前缀声明/定义来使用我的代码中的接口XERCES_CPP_NAMESPACE::.

随着代码的发展,可能需要删除Xerces以支持不同的解析器.我通过纯虚拟接口部分"保护"了库实现的变化(如果我使用工厂来构建我的Parser,更是如此),但是一旦我从Xerces切换到其他东西,我需要通过我的代码梳理和改变我的一切using namespace XERCES_CPP_NAMESPACE和XERCES_CPP_NAMESPACE::Parser代码.

最近,当我重构现有的C++项目以将一些现有的有用功能拆分到库中时,我遇到了这个问题:

foo.h中

class Useful;  // Forward Declaration

class Foo
{
public:

    Foo(const Useful& u);
    ...snip...

}

Foo.cpp中

#include "foo.h"
#include "useful.h" // Useful Library

Foo::Foo(const Useful& u)
{
    ... snip ...
}

当时很大程度上是出于无知(并且部分地出于懒惰),所有功能都useful.lib被置于全局命名空间中.

随着内容的useful.lib增长(以及更多客户端开始使用该功能),决定将所有代码移动useful.lib到其自己的名称空间中"useful".

客户端.cpp文件很容易修复,只需添加一个using namespace …

刚刚大学毕业,我遇到了一些需要减少耦合的代码.但我并不完全理解所有概念,并想要一个简单的例子来帮助我.为了让你开始,我有一个人类,一个字段,名称.我在该类中有一个方法来连接一些文本.

我知道这是一个愚蠢的例子,大多数人都不会考虑在这种简单的情况下减少耦合,但我只想要一个简单的例子来帮助我完全理解代码和概念.

在主窗口后面的代码中,我放了一个文本框和一个按钮.窗口加载时,它显示person x name字段的当前值.单击该按钮时,将调用x.PersonAddText方法.目前,此示例的耦合计算为8.按钮单击事件为3,窗口加载事件为3.

有没有办法,使用这个例子,我们可以将它们降低到低于它们中的一个或两个.

以下是我的所有代码:

我的人员类:

public class Person
{
    //Fields
    private string name;

    //Properties
    public string Name
    {
        get { return name; }
        set { name = value; }
    }

    //Constructors
    public Person()
    {
        name = "joe";
    }

    //Methods
    public string PersonAddText(string text)
    {
        return name += " - " + text;
    }

    //Interfaces (or additional code below here please to aid understanding)
}

我的守则背后:

    Person x = new Person();

    public MainWindow()
    {
        InitializeComponent();
    }

    private void …

请注意,这是一篇很长的帖子.对不起,但我想澄清一点:

我想知道如何将Swing GUI与Presentation和Business Logic分开很长一段时间.在工作中,我必须使用一个小的Swing对话框为一些数据实现3 MD Excel Export以配置导出.我们不使用像Spring这样的框架,所以我必须自己实现它.

我想完全将GUI与Business Logic分开,这些都是精确的后续任务:

• 告诉BL从GUI开始工作
• 从BL到GUI报告进度
• 报告从BL到GUI的日志记录
• 将BL结果委托给GUI

当然,GUI不应该注意BL实现,反之亦然.我创建了上述所有这些任务,例如几个接口ProgressListener,LogMessageListener,JobDoneListener等,要由业务逻辑被解雇.例如,如果业务逻辑想要告诉记录,则会调用

fireLogListeners("Job has been started");

实现公共接口LogListener +的类附加到BL,现在将通知有关"作业已启动"的日志消息.所有这些监听器此时都是由GUI本身实现的,一般看起来像这样:

public class ExportDialog extends JDialog implements ProgressListener, LogListener, JobFinishedListener,  ErrorListener {

    @Override
    public void jobFinished(Object result){
        // Create Save File dialog and save exported Data to file.
    }

    @Override
    public void reportProgress(int steps){
        progressBar.setValue(progressBar.getValue()+steps);
    }

    @Override
    public void errorOccured(Exception ex, String additionalMessage){
        ExceptionDialog dialog = new ExceptionDialog(additionalMessage, ex);
        dialog.open();
    }

    // etc.
}

"GUI和BL创建类"只是将GUI(作为所有这些侦听器的界面)附加到BL,它看起来像这样: …

在域驱动设计中,域层据说不依赖于其他层,即存储库接口位于域层内,而其实现位于基础架构层.

然而,有界上下文(带域+ infra)被部署为一个单元(可部署),因此这些层实际上是逻辑的而不是物理的.那么在域和基础架构层之间绘制这个虚拟分隔符有什么好处？

更新

在传统的分层方法中,域(服务)被认为依赖于基础设施层.相反,当涉及DDD /清洁/六边形体系结构时,域独立于其他层,因为域层具有由基础结构层实现的接口.

无论您使用DDD还是传统的分层方法,您仍然需要模拟存储库,这意味着域实际上并不是独立的.它是否正确？

将代码分解为模块化/解耦的函数和类是很好的,但如果你做得太多,你会得到非常碎片的代码,这也是不好的.

何时将代码拆分为函数的黄金法则是什么？