内部変数がパブリックと宣言され、アクセス可能であるときに使用される用語はありますか？

ゲッター/セッターメソッドを使用せずに内部変数$ _fieldsにアクセスできるように誰かがコードを記述した場合、それを説明する適切な用語はありますか？

管理で使用するのに十分な丁寧なもの:)

プライベートメンバーを公開することは、礼儀正しい社会では決して良いことではありません...

この習慣は、カプセル化の欠如/不十分です。

Odedによって既に言及されているカプセル化の欠如に加えて、プログラミング言語とそのパラダイムによっては、「プレーンな古いデータ」である可能性もあります（必ずしもアンチパターンやコードの匂いではありません）。

「裸のオブジェクト」という言葉は以前聞いたことがある。

そのプロパティバッグと呼ばれます。

通常、関連する可能性のあるプロパティのセットを保持するために使用されます（それぞれが、適切なアクセス指定子を持つクラスオブジェクトである可能性がある場合）。しかし、周囲の構造はプロパティのバッグにすぎません。

「特定のコーディング標準に従っていない」と呼ばれています。

OPは書きました：

内部変数$ _fieldsは、getter / setterメソッドを使用せずにアクセスできます

それはあなたの標準に反するかもしれません、そしてそれはそれがコード臭いかもしれません。しかし、それは必ずしも不十分なカプセル化ではありません。ゲッターとセッターを介して内部変数（「内部使用のみ」など）を外部に公開すると、さらに悪くなります。

問題は$_fields、外部からアクセスできるようにする必要があるかどうかです。

もしそうなら、getter / setterメソッドを追加するケースがあります。これらのメソッドは何もカプセル化しませんが、それ$_fieldsはある種の変数であるという事実（その場で計算/フェッチなどされるものとは対照的です）。言語にもよりますが、おそらく型（実装の詳細）を外部に漏らしてしまうでしょう。常にゲッター/セッターが必要かどうか、または「必要」な場合のみコーディング標準の問題。

アクセスできないようにする$_fields必要がある場合は、アクセスしないでください。他の人が言語レベル（プライベートや友達）でアクセスできないようにする必要があるかどうか（特定の状況でのデバッグが容易になる可能性があります）は、コーディング標準の問題です。

カプセル化の問題はこれと完全に直交しています。ゲッターとセッターを使用すると、カプセル化の違反が完全に可能になります。それもあります簡単にコード一見のベストプラクティスを、次のだ-彼らはゲッターとセッターの束を見たときにほとんどの人々の警鐘を鳴らしていないので、にスリップします。コードは、$_fieldsたまたまとして指定されていないと呼ばれる変数よりも、内部の実装の詳細にはるかに多くの依存関係をもたらす可能性がありますprivate。

私は悪いアナロジーのファンです。不十分なカプセル化は、銃を構えている誰かを殺人者と呼ぶようなものです。

このような変数をパブリックメンバー変数と呼びます。

あなたのセッター/ゲッターメソッドが何もない場合

void setfoo(bar){foo=bar;}
foo getfoo{return foo;}

次に、pubic変数を作成するだけで、違いが問題となるいくつかのエッジケース以外の入力を節約できます。