Android - 为什么使用接口被认为是 Activity 和 Fragment 之间通信的最佳实践？
Android - Why is using an Interface considered the best practice of communicating between Activity and Fragment?
在本文档 "Communicating with Other Fragments" 中，Google 告诉我们通信 Activity 和 Fragment 的最佳实践是 实现接口 。然后可以通过 Fragment 调用此接口并在 Activity.
中执行必要的行为
但也有一种 hack 方法可以做到这一点。直接通过"getActivity()"的方法得到Activity，然后我们就可以使用它下面的所有"public method"了。
这让我很困惑。因为我真的想不出使用 hack 方法来做这件事有什么严重的缺点。
我想到的第一种方法的优点是：
- 我可以把"resource accessibility"限制在我的Activity下面。但是既然Fragment能够调用"getActivity()"，那么它其实是可以访问其中所有的"public"方法的。所以这真的不能说服我。
- 代码更具可读性和故事性。对于第一种方法，代码告诉我们 "this Activity only open these specific accessible area for the Fragment"。我们只要看Activity中的代码就可以直接知道"What inside the Fragment may interfere the Activity"。否则，我们需要打开Fragment下的代码，看看它做了什么。
好吧，我把这些总结出来后，自己也有点服气了。但坦率地说，我真的想要其他一些可靠的东西，并且必须有这样做的理由。任何想法或文件将不胜感激！！
除了
之外，这种方法没有固有的"advantage"
- 这是一个可以识别的成语。使用接口是常见的方式
其中两个 类 在 Java.
中相互通信
- 相同的代码可以在许多不同的
Fragment 和 Activity 中重复使用。
- 它遵循模块化和抽象的一般原则，其中
Fragment "tells" Activity 表示它已经达到了某种状态，Activity 决定了它的状态与此状态有关的自己的行为。
最重要的是，主要优势是代码的模块化。当您直接从 "child" class 调用您的 "parent" class 时，您创建了一个 cyclic dependency。这实际上意味着您不能在不更改另一个的情况下更换一个。这种方法经常导致难以维护的意大利面条代码，更难扩展，如果不进行大量重构工作，几乎不可能替换。
关于您的示例：如果您直接从 Fragment 调用 Activity 的 public 方法，您将无法在其他活动中重复使用您的片段如果不实施 hacky 解决方案（如 if(getActivity() instanceof A) {...} else {...}），您也不能将 Activity 换成例如控制器-class，或您提出的任何其他解决方案。
如果你很难理解这门课，我强烈推荐你阅读这本书 Effective Java。
我认为基于接口的方法的主要优势在于其众所周知且可读的模块化以及从软件工程角度来看足够高的抽象级别。
假设你在一个团队工作中，每个团队成员负责其中一个组件，例如，假设你应该实现那个片段，我应该实现那个activity。因此，由于我们彼此相距太远，我们应该同意 共享接口 作为我们之间的标准，然后我们应该实现符合该标准的组件，在这种情况下是我们同意的接口。同样在软件工程考虑中，基于组件的软件系统由许多组件组成，这些组件彼此 独立 并且它们的交互仅通过标准共享接口完成，并且每个组件内部的材料对其他
因此，在您的情况下，Activity 和 Fragment 应被视为两个独立的组件，每个组件都不知道另一个组件的详细信息。这是 Java 界面。
在本文档 "Communicating with Other Fragments" 中，Google 告诉我们通信 Activity 和 Fragment 的最佳实践是 实现接口 。然后可以通过 Fragment 调用此接口并在 Activity.
中执行必要的行为但也有一种 hack 方法可以做到这一点。直接通过"getActivity()"的方法得到Activity，然后我们就可以使用它下面的所有"public method"了。
这让我很困惑。因为我真的想不出使用 hack 方法来做这件事有什么严重的缺点。
我想到的第一种方法的优点是：
- 我可以把"resource accessibility"限制在我的Activity下面。但是既然Fragment能够调用"getActivity()"，那么它其实是可以访问其中所有的"public"方法的。所以这真的不能说服我。
- 代码更具可读性和故事性。对于第一种方法，代码告诉我们 "this Activity only open these specific accessible area for the Fragment"。我们只要看Activity中的代码就可以直接知道"What inside the Fragment may interfere the Activity"。否则，我们需要打开Fragment下的代码，看看它做了什么。
好吧，我把这些总结出来后，自己也有点服气了。但坦率地说，我真的想要其他一些可靠的东西，并且必须有这样做的理由。任何想法或文件将不胜感激！！
除了
之外，这种方法没有固有的"advantage"- 这是一个可以识别的成语。使用接口是常见的方式 其中两个 类 在 Java. 中相互通信
- 相同的代码可以在许多不同的
Fragment和Activity中重复使用。 - 它遵循模块化和抽象的一般原则，其中
Fragment"tells"Activity表示它已经达到了某种状态，Activity决定了它的状态与此状态有关的自己的行为。
最重要的是，主要优势是代码的模块化。当您直接从 "child" class 调用您的 "parent" class 时，您创建了一个 cyclic dependency。这实际上意味着您不能在不更改另一个的情况下更换一个。这种方法经常导致难以维护的意大利面条代码，更难扩展，如果不进行大量重构工作，几乎不可能替换。
关于您的示例：如果您直接从 Fragment 调用 Activity 的 public 方法，您将无法在其他活动中重复使用您的片段如果不实施 hacky 解决方案（如 if(getActivity() instanceof A) {...} else {...}），您也不能将 Activity 换成例如控制器-class，或您提出的任何其他解决方案。
如果你很难理解这门课，我强烈推荐你阅读这本书 Effective Java。
我认为基于接口的方法的主要优势在于其众所周知且可读的模块化以及从软件工程角度来看足够高的抽象级别。
假设你在一个团队工作中，每个团队成员负责其中一个组件，例如，假设你应该实现那个片段，我应该实现那个activity。因此，由于我们彼此相距太远，我们应该同意 共享接口 作为我们之间的标准，然后我们应该实现符合该标准的组件，在这种情况下是我们同意的接口。同样在软件工程考虑中，基于组件的软件系统由许多组件组成，这些组件彼此 独立 并且它们的交互仅通过标准共享接口完成，并且每个组件内部的材料对其他
因此，在您的情况下，Activity 和 Fragment 应被视为两个独立的组件，每个组件都不知道另一个组件的详细信息。这是 Java 界面。