OOP言語は、プログラマーにクリーンで高品質のコードを書くように強制するために、「保護された」キーワードを排除すべきですか？
私は保護された使用を避けるための強い理由があるいくつかの投稿を見ました：
なぜプライベートフィールドがあり、十分に保護されていないのですか？
なぜClean Codeは保護された変数の回避を提案しているのですか？
そして、実際には継承が必要ないことを示唆する他のいくつかの投稿があります：
そして、他のいくつかの投稿は、継承が代替を持つことができることを示唆しました：
「継承より構成」ルールをクラスメンバーに強制する必要がありますか？
だから私はどちらかといえば「モダン」な考えを持っています：「保護された」フィールドが非常に有害である場合、OOP言語はキーワード「保護された」を排除して、プログラマにクリーンで高品質のコードを書くように強制する必要がありますか？答えは 'NO！'ですが、 '保護された'フィールドを許可する理由は何ですか？例：実際に '保護された'フィールドが必要なのはいつですか？
それはすべて、ノイズを回避し、スコープを狭く保つことです。子孫が親メンバーにアクセスする唯一の方法は、それらのメンバーをパブリックにアクセス可能にすることです。これにより、これらのメンバーがクライアント（クラスのユーザー）にも公開されます。これは役に立たず、不可解で危険です。それは最も確かにきれいではないでしょう。ポイ捨てはWordで、名前空間全体のクラスの内部機能をポイ捨てすることになります。それはとても厄介です。
それらのアドバイスは保護されたfieldsに対してのみです。メソッドにはprotectedが必要です。それは公共の場に対する一般的なアドバイスに関連しています。実際には、フィールドは常にプライベートであり、ゲッター/セッターを通じてのみ公開される必要があると主張しています。
それは一般的に賢明なアドバイスですが、パブリックフィールドまたは保護フィールドが最も単純で最も簡単なアプローチである場合があり、ゲッター/セッターを追加することは不要なコードの肥大化になるため、コンパイラーによって強制されることは望ましくありません。それはすべてコンテキストに依存します。
継承は、壊れやすい基本クラスの問題など、多くの問題に悩まされており、密な双方向の結合を作成し、カプセル化を弱めています。さらに、必要以上にテストを困難にする可能性があります。 （上記のすべての詳細については 継承：すでに使用を中止してください！ を参照してください[免責事項：私が作成]）。
インターフェースの設計とコンポジションの使用を組み合わせて使用するより継承がうまく機能する場所を見つけることができたユースケースはありません。
したがって、現代の言語が継承をまったくサポートしていないのは良いケースです。ただし、サポートしている場合は、protectedが引き続き必要です。それがなくても、フォークは継承を使用しますが、サブクラスがオーバーライドするメンバーpublicを作成することにより、カプセル化をさらに弱める必要があります。そして、既存の言語から継承を削除するだけで既存のコードが壊れてしまうので、残念ながらそれはスターターではありません。