protected変数(プロテクテッドへんすう)とは | 意味や読み方など丁寧でわかりやすい用語解説

オブジェクト指向プログラミングにおいて、「protected変数」とは、クラスのメンバ変数に対するアクセスレベルを制御するためのアクセス修飾子の一つである。このアクセス修飾子は、その変数が宣言されたクラス自身と、そのクラスを継承した子クラス（派生クラス）からのみ直接アクセスを許可するという特性を持つ。クラスの外部、つまり継承関係にない他のクラスからはアクセスできないようにすることで、カプセル化の原則を部分的に維持しつつ、継承による機能拡張の柔軟性も確保することを目指している。

詳細に説明すると、オブジェクト指向プログラミングには、データとそれを操作するメソッドをひとまとめにして外部から隠蔽する「カプセル化」という重要な概念がある。このカプセル化を実現するために、多くのプログラミング言語では「アクセス修飾子」という仕組みが提供されている。主なアクセス修飾子には、「public」「private」「protected」の三種類が存在する。

まず「public」修飾子は、その変数が宣言されたクラスの内部だけでなく、クラスの外部からもどこからでも自由にアクセスできることを意味する。これは最もオープンなアクセスレベルであり、クラスのインターフェースとして公開されるべき変数やメソッドに適用される。

次に「private」修飾子は、その変数が宣言されたクラスの内部からのみアクセスできることを意味する。クラスの外部からは一切アクセスできないため、最も厳格なカプセル化を実現する。これにより、クラスの内部実装の詳細が外部に漏れることを防ぎ、クラスのデータの一貫性や整合性を保証しやすくなる。外部から内部状態を変更したい場合は、通常、publicなメソッド（セッターメソッド）を介して間接的に操作することになる。

そして「protected」修飾子は、publicとprivateの中間的なアクセスレベルを提供する。protected変数は、その変数が定義されたクラス自身からは当然アクセス可能だが、さらにそのクラスを「継承」して作られた子クラスからも直接アクセスできる。しかし、継承関係にない完全に独立した他のクラスからは、private変数と同様にアクセスが許可されない。

このprotected変数の存在意義は、「継承」と「カプセル化」という二つの概念のバランスを取る点にある。継承とは、既存のクラス（親クラス、基底クラス）の性質や振る舞いを引き継ぎ、それを拡張したり変更したりして新しいクラス（子クラス、派生クラス）を作成する仕組みである。子クラスは親クラスの機能を再利用できるため、コードの重複を避け、効率的な開発が可能になる。

もし親クラスの内部状態がすべてprivate変数で管理されている場合、子クラスは親クラスの内部状態を直接参照したり変更したりできない。子クラスが親クラスの特定の内部状態にアクセスして、それに基づいた独自の処理を行いたい場合、親クラスにpublicなメソッドを用意してもらうか、あるいは子クラスでその内部状態を再度定義し直すなどの手間が発生してしまう。これは、継承によるコードの再利用性や拡張性を損なう可能性がある。

ここでprotected変数が役立つ。親クラスの設計者が、特定の変数はクラスの外部には公開したくないが、将来的にこのクラスを継承する可能性のある子クラスにはアクセスを許可して、より柔軟な拡張を可能にしたいと考える場合にprotected修飾子を使用する。例えば、特定のオブジェクトの内部IDや、計算の中間結果、特定の内部的な設定値など、親クラスと子クラス間で共有すべき共通の内部状態をprotected変数として定義する。これにより、子クラスは親クラスの内部状態を直接利用して、より詳細な処理や特化した振る舞いを実装できるようになる。

しかし、protected変数の使用には注意も必要である。private変数に比べてアクセス範囲が広がるため、カプセル化の度合いは低くなる。もし子クラスがprotected変数を不用意に変更してしまった場合、親クラスが想定していない状態になり、不具合を引き起こす可能性がある。また、親クラスの内部実装が変更された際に、そのprotected変数を直接利用しているすべての子クラスも影響を受ける可能性があるため、コードの保守性が低下するリスクも存在する。

したがって、変数をprotectedにするかprivateにするかの判断は慎重に行うべきである。基本的には、可能な限りprivate修飾子を使用して厳格なカプセル化を保つことが推奨される。そして、子クラスが親クラスの内部状態に直接アクセスする必要がある、かつそのアクセスが設計上正当であると判断される場合にのみ、protected変数の利用を検討するというのが一般的な設計指針となる。これにより、コードの再利用性と堅牢性を両立させることが可能になる。