问题标签 [tightly-coupled-code]

这有点难以解释......希望这个问题不是含糊的......

您可以查看代码以了解想法...

ClassA.java

ClassB.java

ClassC.java

接口InterA.java

配置ClassConfig.java（在同一个包的其他java类文件上）

主要方法

当我执行 main 方法时，ClassA没有注入 Autowired 字段“abcd”并导致NullPointerException

它仅在我声明ClassA为 a@Component并获得它的 bean 时才有效......间接自动装配不会发生

我应该解耦ClassA并使ClassC一切松散耦合吗？

是否有任何简单的注释可以用来告诉 Spring 自动注入 @Autowired 字段，即使对象是以紧密耦合的方式创建的？

注意 请不要告诉我使用 ApplicationContextClassC来创建ClassA.

任何可以找到答案的Spring Geek？

我正在开发一个游戏，其中我有一个嵌套类，它必须访问外部类的成员函数和变量才能执行它的功能。特别是外部类包含与游戏对象相关的成员函数和数据，而嵌套类扩展了一个AnimationTimer，它基本上必须利用游戏对象的位置才能在画布上绘制它们。此外，外部类必须调用 AnimationTimer 的 start() 方法，因此肯定需要外部类中的AnimationTimer实例。现在因为我对此有点陌生，所以我对这篇文章有点困惑所以

1. 这真的是紧密数据耦合的情况吗？
2. 在这种情况下，您有什么建议，我应该将其转换为非嵌套类并通过 static 修饰符访问“父母”成员函数（在这种情况下，为什么这是正确的，为什么不正确）？

欢迎任何建议:)

我正在制作一个 Xamarin Forms 跨平台应用程序。我一直在试图弄清楚如何让我的应用程序以最佳方式与 Azure 后端集成。我遇到了一个问题。我一直在尝试构建尽可能松耦合的程序。但是后来我被告知将我的 Azure 服务类创建为单例，以停止多次创建并破坏后端连接

因为我不能使用带有单例的接口来使我的应用程序松散耦合。我必须选择。我认为我应该使用接口，以实现松散耦合。但是我对后端开发了解不多。创建我的 AzureServices 数据库类的多个实例会搞砸吗？

谢谢你的帮助。

这是我的 AzureServices 格式的示例

有时我们会遇到一个类不需要使用自己的属性的问题。见方法A：

为了避免这种情况，我们可以使用方法B：

但是方法B是一种紧耦合结构，这意味着两者都Ball互相World了解，这是不好的。

那么，哪种方法更好呢？

• A : 松耦合，但有些类不会使用自己的属性，或者
• B : 类会使用它们的属性，但是紧耦合结构？

什么时候使用每一个？

如果在客户端使用需要特定格式（例如[{id: 1, name: "Jack", available: true}]）数据的库，服务器应该以客户端请求的确切结构处理数据还是发回通用数据（例如[{userId: 1, username: "Jack", isUserAvailable: true}]），然后可以在如果客户端库将来发生变化，客户端以避免紧密耦合和中断？

我正在编写代码来创建一个简单的游戏，但我不确定这部分是否紧密耦合（高耦合）：

有一个名为 GameEngine 的接口，它在其中控制游戏的流程。还有一个名为 GameEngineImpl 的类实现了 GameEngine 接口。在 A、B 和 C 等其他类中，他们像这样使用 GameEngine：

其他两个类也以与 A 类类似的方式使用 GameEngine。

当我把它转换成UML类图时，类A、B和C的依赖指向GameEngine接口，GameEngineImpl类指向GameEngine接口。

这会是一个紧密耦合的代码吗？

我开始学习使用 ES6 模块和 webpack 来组织 JavaScript 代码。我不明白的是如何在不使模块彼此紧密耦合的情况下使用它们。使用导出的代码不是天生就不可能创建松散耦合的模块吗？

当目标对象时excelColumns，pdfColumns部分共享相同的对象，其中一些甚至有条件地共享，什么是一个好的 OOP 模式来避免函数式编程、紧密耦合和样板，如下面的代码？让我们假设，将有很多共享列，而只有少数非共享列和条件列。

我想编写一个程序，将二阶微分方程转换为两个常微分方程，但我不知道如何在 Python 中做到这一点。

我收到很多错误，请帮助正确编写代码。

几乎每个功能都需要在前端 (FE)、编排层 (OL)、后端 (BE) 和其他上游进行更改。在我的组织中（或在大多数地方），FE 团队无法提高任何 PR 以将其合并到主模式，除非 OL 模式被推送到生产环境，因为它们之间的紧密耦合。解决此问题的最佳方法是什么？或者哪个“版本”应该合并到开发中？

我对此的分析：

• 在部署 BE 之前，使用功能标志隐藏功能。

• 从 main 创建一个 Release 分支，一旦 OL
  模式可用，该分支就会合并。

请提供更多相同的建议