私は、アクセス修飾子とカプセル化を使用して、間違って実装された場合にクラスが壊れないようにするという一般的な規則を常に使用してきました。しかし、OOP は実際にはカプセル化を必要とせず、アクセス修飾子を使用すると実際にはメリットよりも頭痛の種が増えることに気付きました。さらに、アクセス修飾子を使用しないことで、より OO プログラマになります。私の推論を以下に示します。
Python は OOP をサポートしていますが、アクセス修飾子やカプセル化は使用していません。OOP 言語ではアクセス修飾子が必須ではないことを示します。
コンパイラはより高度ですが、アクセサメソッドと変数アクセスの使用にはまだナノ秒の違いがあります。このような制限されたシステムで
Androidは、ゲームの FPS に大きな影響を与えます。(ただし、メソッドで final 修飾子を使用すると、ほとんどの場合、ナノ秒の差が大幅に減少します)プライベートまたはパッケージ修飾子を使用しないことで、元のコーダーにとってコーディングがより簡単かつ高速になります。クラスの将来のユーザーは、クラスの実装を壊したりいじったりすることなく、パブリック インターフェイスを使用できます。さらに、クラスを変更またはアップグレードしたい場合は、それを行い、プライベート モディファイアにアクセスすることができます。例えるなら、車を改造しようと決めたとき、何かを壊す可能性があることはわかっていますが、リスクを冒して何をしようとしているのかを知っていれば、クリアなロックを開くことが許可されます。 (自分の責任で開いてください) というサインは、変更したい部分をロックして、壊れないロックを交換するよりも優れています。
私が今行っているのは、パブリック インターフェイスの public 修飾子と実装の詳細の protected 修飾子を組み合わせて、ユーザーがサブクラス化によってリスクを負うことができるようにすることです。従来のカプセル化の代わりにこれを行うことを再考する必要がある理由はありますか?