回答。

問題の背景:

可視性修飾子（visibility modifiers）は、Javaに比べてKotlinで強化された重要な特徴です。これにより、クラス、関数、およびプロパティへのアクセスを制限し、カプセル化とモジュール性のベストプラクティスをサポートします。

問題:

可視性の不適切な使用は、アーキテクチャの層に違反する可能性があり、実装が外部に漏れたり、逆に必要な場所でクラスやメソッドがアクセス不能になったりします。このエラーはしばしば遅れて発見されます。

解決策:

Kotlinには4つの可視性修飾子があります：

public — どこでもアクセス可能（デフォルト）
internal — 同一モジュール内のみアクセス可能
protected — クラスとそのサブクラス内でアクセス可能
private — ファイル、クラス、またはオブジェクト内でのみアクセス可能

コード例：

open class Base {
    private fun onlyBase() {}
    protected fun baseAndDerived() {}
    internal fun insideModule() {}
    public fun anyone() {}
}

class Derived : Base() {
    fun test() {
        baseAndDerived() // アクセス可能
        // onlyBase() — エラー
    }
}

重要な特徴：

internal はKotlin特有であり、Javaには存在しません
トップレベル要素への修飾子は特別な動作をします：privateはファイルでの可視性を制限します
インターフェースではすべてのメソッドとプロパティがデフォルトでpublicです

騙しの質問。

ライブラリ公開時のinternal修飾子の動作はどうなりますか？

internalは同一モジュール内で要素を隠しますが、ライブラリをjar/aarにコンパイルすると、internal要素はリフレクションを通じて可視化されます。

クラスのプロパティとトップレベル関数のprivateの違いは何ですか？

クラスのプロパティに対するprivateは、そのクラス内でのみ可視性を制限しますが、トップレベルでは、その要素が宣言されているファイル内でのみ制限されます。

トップレベル関数にprotectedを適用できますか？

いいえ、protectedはクラスまたはインターフェースのメンバーにのみ許可されます。トップレベルにprotectedは使用できず、コンパイルエラーになります。

一般的なエラーとアンチパターン

不必要にオープンクラスと関数（必要のないpublic）
独立したコンポーネントを統合するモジュールでのinternalの使用
トップレベル関数やプロパティに対するprotectedの使用を試みること

日常の例

ネガティブケース

大規模なライブラリがほぼすべてのAPIをpublicとして宣言し、ユーティリティやヘルパーを含めた結果、ユーザーが実装の詳細に依存するようになった。

利点:

誰にでも使いやすい

欠点:

後方互換性やリファクタリングの難しさ

ポジティブケース

必要なクラスのみをpublicとして宣言し、残りはinternalまたはprivateにし、可視性のレベルを明確に分けている。