Questions tagged «coupling»

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

11 design-patterns  patterns-and-practices  coupling 

从这个线程开始，我开始 单例模式 这让我开始思考班级之间的耦合程度以及如何最好地实现松散耦合。请记住，我是一名新程序员（我的第一份工作开始已经四个月了），这确实是我对此的首要考虑，并且非常热衷于理解这一概念。 那么，究竟是松耦合还是重耦合呢？在当前（也是第一个项目）中，我正在研究ac＃winforms项目，该项目的GUI部分创建对象和对其事件的订阅，当它们被触发时，GUI创建另一个对象（在本示例中为datagridview（一个类是我创建的，它包装了一个标准的datagridview并添加了其他功能）并将其附加到GUI。这是不好的结合还是好的？ 我真的不想养成不良习惯并开始编写不好的代码，因此，我感谢您的答复。

11 language-agnostic  coupling 

主要问题 眼看着良好的支持最先进的编程平台有包管理（想想gem，npm，pip，等），它是有意义的设计应用程序或系统由内部开发的软件包，从而促进并创建一个松散耦合的架构？ 例 这样的一个示例是创建用于数据库访问以及用于身份验证和系统其他组件的软件包。当然，这些也使用外部程序包。然后，您的系统导入并使用这些软件包-而不是将其代码包含在自己的代码库中。 注意事项 对我来说，这似乎可以促进代码去耦并提高可维护性，几乎是一种基于Web的桌面应用程序方式（更新几乎是自动应用的，单一功能的单一代码库，等等）。 这看起来像是一个合理而理智的设计概念吗？如今，这实际上已用作构建应用程序的标准方法吗？

10 design  design-patterns  architecture  packages  coupling 

有时只需要紧密耦合对象即可。例如，一个CsvFile类可能需要与CsvRecord该类（或ICsvRecord接口）紧密配合。 但是，从我过去的经验中学到，测试驱动开发的主要宗旨之一是“永远不要一次测试一个以上的类”。表示您应该使用ICsvRecord模拟或存根，而不是的实际实例CsvRecord。 但是，在尝试这种方法之后，我注意到嘲笑CsvRecord该类可能会变得有些毛茸茸。这使我得出以下两个结论之一： 编写单元测试很困难！那是代码的味道！重构！ 模拟每个依赖项是不合理的。 当我用实际CsvRecord实例替换模拟对象时，事情进行得更加顺利。当寻找其他人的想法时，我偶然发现了这篇博客文章，该文章似乎支持上面的第二点。对于自然紧密耦合的对象，我们不必太担心模拟。 我会偏离轨道吗？以上假设2有不利之处吗？我是否真的应该考虑重构设计？

10 tdd  coupling  mocking 

现代程序中流行的高级体系结构选择是基于REST的微服务系统。这具有几个优点，例如松耦合，易于重用，对可用技术的限制有限，高可伸缩性等。 但是我预见到的这种架构中的问题之一是对应用程序依赖项的可见性不佳。例如，假设我有一个应用程序，该应用程序每天使用一组REST调用。该应用程序还使用第二组REST调用，但每季度仅使用一次。如果我要扫描过去一周的日志，我会看到所有的每日校准数据，但可能看不到季度调用。当需要重构时，每季度调用的中断风险很高。 可以使用什么模式或工具来减少这种风险，并提供对松散耦合体系结构的依赖性的更大可见性？

9 architecture  rest  enterprise-architecture  microservices  coupling