如果您搜索如何解决循环依赖关系，答案几乎总是“使用接口”。我知道如何使用这种技术来使循环依赖起作用，但我不明白这是如何解决循环依赖的。
假设我有 2 个类 View 和 Presenter，它们相互引用。现在我应用“解决方案”并创建接口 IView 和 IPresenter。View不再引用Presenter，而是引用IPresenter；Presenter引用IView而不是View。
圆圈变大了，但它仍然存在。View 和 Presenter 仍然相互依赖，只是不是直接依赖。然而，我看到的每一个答案都绝对肯定循环依赖现在已经解决了。我在这里有什么误解？
我收到错误消息
java.lang.SecurityException: uid 10178 cannot explicitly add accounts of type: net.roughdesign.swms
即使是我可以创建的最基本的示例。它包括：
strings.xml 中的帐户类型
<string name="accounts__account_type">net.roughdesign.swms</string>
验证器.xml
<?xml version="1.0" encoding="utf-8"?>
<resources>
<account-authenticator xmlns:android="http://schemas.android.com/apk/res/android"
android:accountType="@string/accounts__account_type"
android:icon="@drawable/ic_add_black_24dp"
android:smallIcon="@drawable/ic_add_black_24dp"
android:label="@string/global__authenticator_account_label"
/>
</resources>
SwmsAccountAuthenticator.kt
class SwmsAccountAuthenticator(val context: Context) : AbstractAccountAuthenticator(context) {
override fun addAccount(
response: AccountAuthenticatorResponse, accountType: String, authTokenType: String?,
requiredFeatures: Array<out String>?, options: Bundle?
): Bundle? {
return null
}
override fun confirmCredentials(response: AccountAuthenticatorResponse, account: Account, options: Bundle?)
: Bundle? {
return null
}
override fun editProperties(response: AccountAuthenticatorResponse?, accountType: String?): Bundle? { …默认情况下，C＃中的方法是非虚拟的。这个对另一个问题的答案解释了这样做的好处：
应该为继承设计类，以便能够利用它。默认情况下，将方法虚拟化意味着可以将类中的每个函数插入并替换为另一个函数，这并不是一件好事。
甚至Anders Hejlsberg 似乎也给出了相同的原因：
当我们在API中发布虚拟方法时，我们不仅承诺在调用此方法时还会发生x和y。我们还承诺，当您重写此方法时，相对于其他方法，我们将以特定的顺序调用它，并且状态将处于此不变状态。[...]您不希望用户在API中的任意点上重写和挂接，因为您不一定会做出这些承诺。
我同意这种推理：通常，当我创建一个非私有方法时，我只想创建可以从类外部的某个地方调用的代码。通常，不考虑其他人如何覆盖此方法以及将产生何种效果。对于特殊情况，我可以用virtual信号表示确实以覆盖有意义的方式创建了代码。
但是，默认情况下仍未打开类。该默认假定我花确保继承一个类有意义的额外的努力。
在这方面，有什么使类不同于方法的吗？
编辑
我真的不知道要更改的内容-基于意见的内容。我从没问过意见。也许我必须明确地说出来？
我不要意见
正确的答案将提供类与方法不同的示例，或者声明在这种情况下没有区别。
假设我的 NuGet 服务器上有版本 1.1.0。
然后我继续开发并推送1.2.0版本。
然后我在1.1.0版本中发现了一个bug并想修复它。
现在还可以推送1.1.1版本吗？