问题标签 [loose-coupling]

上述代码的输出似乎是
Hello from SBI static

我应该在我的代码和 Y 中添加什么来also打印语句
Connected to SBI

非常感谢详细的解释

PS菜鸟在这里

Is there any smell associated with having say a File.IO library being loosely coupled to the logging library? Or should they be kept separate and only combined in the application services?

我意识到这个主题已经被覆盖到死，但我仍然在挣扎，可以通过一些具体的帮助来做。

我的目标是在某种可观察对象（比如说狗）和某种侦听器（比如说所有者）之间实现一个简单的观察者模式。

最终，所有者将成为 MVC 范例中的“视图”，而狗将成为“模型”。我使用 Dog 和 Owner 只是为了尝试简化这里的事情。

我尝试使用 Java 内置的 Observer / Observable 类，但已经意识到 Observers update() 方法有多糟糕 - 它接收一个 POJO，我需要在 update() 方法中检查/强制转换该 POJO。我更希望让我的“update()”方法收到它可以期待的东西。

因此，我遵循了一些教程，包括以 Dog/Owner 为例的教程：

http://www.youtube.com/watch?v=qw0zZAte66A

在这里，我展示了如何滚动我自己的 Observer/Observed 类。在伪代码中，我现在拥有的是：

所以现在我有处理特定事件的方法，而不是一个 update() 方法。杰出的。我目前对 Owner/view 类很满意。它知道 Dog/model 的方法，这很好（我认为）。

我不喜欢的是 Dog/model 引用了 Owner/view 中的方法。我已经阅读了无数次并且完全同意模型不应该与其视图紧密耦合，例如它似乎在上面。我也不热衷于 Dog/model 中的所有“火”方法做几乎相同的事情；循环遍历它的所有侦听器，并在每个侦听器上调用不同的方法。

是否可以进一步解耦这种关系并且不让 Dog/model 调用特定的方法？如果是这样，将狗/模型数据接收到所有者/视图并适当地使用它的最佳方法是什么？

谢谢

我是一名程序员，正在使用 .Net 4.0 进行项目，并试图找出将松散耦合和可扩展设计与同一逻辑操作有时可能异步执行且有时仅同步执行的事实相结合的最佳方法（每个实现支持异步也支持同步，但不是相反）。在这个项目中，每一个这样的逻辑操作都由一个接口表示（松耦合和可扩展性要求很高）。让我们将我的问题集中在一个特定的界面上：IDataDictLoader. 该接口负责加载一个名为DataDict. 此接口有两种可能的实现：一种调用它使用本地 dll 并同步LocalDataDictLoader执行操作（返回DataDict)，另一个调用WebServiceDataDictLoader它使用 Web 服务并异步（返回Task<DataDict>）或同步执行操作。配置文件中的值确定要创建的实现 - 如果值为“Local”，则LocalDataDictLoader创建，如果值为“WebService”，则WebServiceDataDictLoader创建。创建部分在函数中使用由约定引导的反射IDataDictLoader CreateLoader(string configValue)。调用该函数并使用接口的代码事先并不知道实现是什么，即使它想知道它也无法访问配置值。问题是如何设计界面？截至目前，我想到了许多选择：

1. 接口上有两种方法，一种是同步的，一种是异步的，并且LocalDataDictLoader在同步版本中有异步包装器。正如 Stephen Toub在这里所建议的那样，这不是推荐的解决方案。
2. 按照 Josh 在他的 IIMViewModelDL 示例中对问题的回答所建议的去做，这样接口将有一个带有回调参数的 void 方法。虽然该解决方案将从客户端代码中隐藏实现细节，但在我看来，它具有异步调用语义，使用回调。在我看来，这相当于始终返回 aTask<DataDict>并让同步实现同步加载，然后使用TaskCompletionSource<DataDict>. 出于同样的原因，这与选项 1 是错误的。
3. 将接口拆分为两个接口：IDataDictLoader用于同步、IAsyncDataDictLoader : IDataDictLoader用于异步和同步。该解决方案为客户端代码提供了有关操作是否可以异步执行的知识，它不会“撒谎”其性质。现在的缺点是客户端代码，称为CreateLoader(string configValue)，现在必须使用 as/is 条件编码样式来知道它收到的IDataDictLoader实际上是一个IAsyncDataDictLoader还是不是。

那么，您将如何在松散耦合和可扩展性需求之间取得平衡，同时揭示配置实现是否支持异步的真实性质？

一段时间以来，我一直在使用 MVC 和 MVVM 架构开发应用程序。在深入研究了这两种架构之后，我发现 MVVM 的组件比 MVC 的组件更松散耦合。但是在做了一些研究之后，有人说MVC的组件也是松耦合和可重用的，有人可以澄清这个问题吗？

我最近看过 Netbeans 平台开发教程视频（现在称为 trail）（http://www.netbeans.org/kb/trails/platform.html）

我一直想知道使用LookupNetbeans 的稳定性如何

这就是我对查找工作原理的理解

作为图像：

作为伪代码（类结构）：

我的问题是，与高度耦合相比，上述实现是否产生了可靠的结果（也可以考虑从其他类访问静态变量、方法和内部类的场景）？

[我需要知道，如果我使用松散耦合并使用查找 api 来实现它。与紧密耦合的程序相比，我的程序会变得或多或少可靠吗？（我所说的可靠是指应用程序的稳定性、是否经常崩溃等因素）]

如果是这样，它是如何工作的？

晚上。对于某些深度组合的情况，我很难找到合适的设计模式。让我举一个例子。

假设我们有一个 Corporation 类型的类，它有许多 Subsidiary 类型的类，它有许多 Department 类型的类，这些类在类型中包含许多 Unit 类型的类，而 Unit 类型又包含许多 Employee 类型的类。

现在，假设用例是计算每个公司的员工人数。我可以遍历每个公司，为每个子公司再次循环，依此类推，这样会导致嵌套循环，深度为 4 级。另外，如果我在下面几个级别引用我的职业链，我会违反得墨忒耳法则，这会在我修改我的链条的那一刻被打破。

我可以做的另一件事是添加大量的快捷方式引用（好吧也许不是很多，但有一些）。例如，一家公司本身也可以包含一个员工列表，从而无需遍历整个链条来计算他们。这样一来，类的耦合度就降低了（但它们是吗？），现在的问题变成了如何使 Corporation 和 Unit 的 Employee 列表保持同步。我想我可以使用观察者模式来让它们保持更新，但我真的觉得这个想法有什么可怕的错误，或者至少，我并没有真正使用那里最好的解决方案。

因为我很确定这是一个非常常见的领域，有谁能给我指出一个合适的设计模式吗？

谢谢。

我有一个IDirectory接口和一个Directory实现它的类。
我需要创建一个IDirectoryEnumerator只有一个看起来像这样的方法：

所以我创建了一个DirectoryEnumerator类，但我不确定IDirectory要返回哪个类GetDirectories()，因为我想让我的代码保持松散耦合。

IDirectory我应该以某种方式使用带有约束的泛型吗？
我应该通过 DI 容器以某种方式获取它吗？
像这样的东西是否应该紧密耦合，我应该专注于特定的具体类型？
或者还有其他更好的选择吗？

注意：IDirectory我的示例中的具体类型没有任何默认构造函数并且是不可变的。

我正处于 MVC 的第一步。

在我的第一个示例中，我有一个这样的模型：

控制器：

和一个视图：

对我来说奇怪的是，视图与模型紧密耦合：它使用像Model.WillAttendecc 这样的代码......那么如果模型在未来发生变化会发生什么？我应该改变这个特定视图中的所有片段（但也可能在许多其他视图中......）这是紧耦合还是我错过了这里的重点？

编辑

作者在书中指出，这种有用的机制是

模型绑定

鉴于方法 [public ViewResult RsvpForm(GuestResponse guestResp)] 是通过 HTTP 请求调用的，并且 GuestResponse 是 HTTP 完全不知道的 .NET 类型，那么 HTTP 请求怎么可能提供 GuestResponse 实例？答案是模型绑定，这是 ASP.NET MVC 的一个非常有用的特性，它通过将传入的键/值对与所需 .NET 类型上的属性名称进行匹配，自动解析传入的数据并用于填充操作方法参数。这种强大的、可定制的机制消除了与处理 HTTP 请求相关的许多单调乏味的工作，让您主要在强类型 .NET 对象方面工作，而不是在低级别摆弄 Request.Form[] 和 Request.QueryString[] 字典，如在 Web 表单中通常是必需的。

我的两分钱：但是，这种机制为您提供了视图中强类型类的优势（但是，由于 Visual Studio Intellisense功能，这非常有用，否则我认为 Request.Form[] 语法也适合相同的）。另一方面，您将视图与模型紧密耦合，因此模型的每一个微小变化都会导致链接视图的级联变化。

我是 Java 模式的新手，我正试图弄清楚它如何适应现实世界。大多数关于模式的网站和书籍似乎都是由非程序员编写的。

我正在尝试定义模式如何帮助耦合，这是我迄今为止的定义。我想知道的是哪些模式对松散耦合真正有用，它们是否值得努力。另外，到目前为止我的定义/理解是否正确：

“耦合是程度，两个或多个不同的对象，相互访问和/或交互。”

两个对象之间的紧密耦合：

• 引用/实例化：在许多地方，在一个或两个对象（多对多引用）中对另一个对象的许多尊重

• 复杂性：通常很多参数需要访问函数，或者访问不同函数的顺序。相关对象没有通用接口。

• 责任：做应该在被访问的对象或另一个对象中完成的工作。直接访问嵌套函数。

• 性能：有时需要紧密耦合的最大原因，但应尽量减少。

两个对象之间的松散耦合：

• 引用/实例化：很少，但在一个对象中至少有一个引用，但不是在两个（一对少数引用）
  中有帮助的模式：工厂、单例、生成器、复合

• 复杂性：很少，定义明确的参数（通常由接口定义），具有最少可能的功能序列（exp. open, fetch, close）
  有帮助的模式：适配器，桥接器，装饰器，外观，命令 

• 责任：只做对象负责做的工作，并尝试只访问下一层的功能。
  有帮助的模式：装饰器、责任链、MVC

• 性能：确定性能需要在哪里，并将这些类放在一起——甚至可以作为嵌套类，根据定义紧密耦合。