※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。
原文
What is Encapsulation - DEV Community
意訳+要約
カプセル化とは？
ブログ「What is Encapsulation?」では、オブジェクト指向プログラミングにおける「カプセル化」に焦点を当てています。以下はその要点をまとめたものです。
- カプセル化とは、オブジェクト指向プログラミングの基本的な概念の一つであり、データとそのデータを操作するメソッドをひとまとめにすることを指す。
- カプセル化を実現するために、クラス内でデータに対する操作を定義するメソッドを定義し、そのメソッドを通じてのみデータにアクセスできるようにする。
- カプセル化により、データの不正な変更や不用意なアクセスを防ぎ、データの整合性を保つことができる。
- カプセル化によって、コードの再利用性が向上し、メンテナンス性が向上する。
- カプセル化は情報の隠蔽（情報隠蔽）とも関連しており、クライアントはオブジェクトの内部構造について知る必要がなく、公開されたメソッドを通じてのみオブジェクトとやり取りする。
このように、カプセル化はオブジェクト指向プログラミングにおいて重要な概念であり、データの保護やコードの整理に役立つ。
ChatGPTへのQA
Ｑ：単純setter/getterをカプセル化としている実装がありますが、これは本当にカプセル化なのでしょうか？
単純な setter/getter をカプセル化としている実装は、一般的には完全なカプセル化とは言い難い場合があります。以下はその理由です。
アクセス制御の欠如: 単純な setter/getter はデータへのアクセスを提供しますが、そのデータに対する適切な制御がない場合があります。つまり、外部から直接値を設定したり取得したりでき、意図しない値の設定や取得が発生する可能性があります。
隠蔽の不足: カプセル化は、データの内部構造を隠蔽することも重要です。しかし、単純な setter/getter では、内部データ構造への直接アクセスが可能な場合があり、これは情報の隠蔽が不十分であることを意味します。
振る舞いの欠如: カプセル化は、データとそれを操作するメソッドをまとめるだけでなく、オブジェクトの振る舞い（behavior）も含みます。しかし、単純な setter/getter は通常、データへの操作だけを提供し、オブジェクトの振る舞いについての情報は提供しません。
したがって、単純な setter/getter をカプセル化としている実装は、本質的なカプセル化の概念を十分に満たしていない可能性があります。完全なカプセル化を実現するためには、アクセス制御、隠蔽、そしてオブジェクトの振る舞いを含める必要があります。
Ｑ：なぜ単純な setter/getter をする実装が増えるのでしょうか？
単純な setter/getter をする実装が増える理由はいくつかあります。
簡易性と速度: 単純な setter/getter は、実装が簡単であり、素早く記述できます。特に、プロトタイプや小規模なプロジェクトでは、このような簡易な方法が採用されることがあります。
既存コードとの互換性: 既存のコードベースにおいて、setter/getter メソッドが既に多用されている場合、新しい実装でも同様の手法を採用することが一貫性を保つ上で適切と考えられることがあります。
継承と拡張性: サブクラスが親クラスの setter/getter メソッドをオーバーライドすることで、振る舞いをカスタマイズすることができます。このような柔軟性は、多くの場合、コードの拡張性や保守性に役立ちます。
外部からのアクセス制御の柔軟性: 単純な setter/getter を使用すると、外部からのデータへのアクセスを柔軟に制御できます。たとえば、特定のデータへのアクセスを制限したり、データの変更時に特定の処理を実行したりすることができます。
言語やフレームワークの制約: 一部の言語やフレームワークでは、カプセル化を完全に実現するための機能や仕組みが限られている場合があります。そのような状況下では、単純な setter/getter を使用することが一般的です。
以上の理由から、単純な setter/getter をする実装が増えることがあります。しかし、これらの手法は必ずしも最適な解決策ではないため、状況やプロジェクトの要件に応じて適切なアプローチを選択する必要があります。
Ｑ：単純な setter/getterを拡張する機会は、ほぼないと思うのですが、拡張の考慮が必要なものなのでしょうか？
単純な setter/getter はそのままでは拡張性が乏しいため、一般的には拡張の考慮が必要です。以下に、その理由を示します。
ビジネスロジックの変更に対する柔軟性: ビジネスロジックが変更された場合、単純な setter/getter ではその変更に対応するための柔軟性が低いため、拡張性が求められます。例えば、データのバリデーションや特定の操作を追加する場合、setter/getter を拡張する必要があります。
ポリモーフィズムの実現: サブクラスで特定の動作をカスタマイズする場合、単純な setter/getter だけでは不十分です。拡張性を持たせるために、オーバーライド可能なメソッドやインターフェースを設計する必要があります。
セキュリティやアクセス制御の強化: データへのアクセスを制限したり、セキュリティを強化するためには、単純な setter/getter だけでは不十分です。拡張性を持たせることで、より細かなアクセス制御やセキュリティポリシーを実装することが可能です。
フレームワークやライブラリの拡張: 外部のフレームワークやライブラリを使用する場合、その拡張性を考慮する必要があります。単純な setter/getter を使用している場合、フレームワークやライブラリが提供する機能を活用するための拡張が制限される可能性があります。
したがって、単純な setter/getter を拡張する機会は少ないかもしれませんが、拡張性を考慮することで、柔軟性や保守性を向上させることができます。特に、長期的なプロジェクトや大規模なシステムでは、拡張性の重要性がますます高まります。
感想＋雑記
単純な setter/getterをする実装には反対の立場だが、少し意見が変わったな。
今までは絶対反対だったけど、外部システムと連携する箇所は、getter/setterありかもなと思った。理由としては、アクセス制御や、ふるまいの拡張をする可能性が高いから。
内部だけであれば、不要だと思ってる。理由は、"Ｑ：単純setter/getterをカプセル化としている実装がありますが、これは本当にカプセル化なのでしょうか？"の回答の通り。
特に振る舞いの欠如。今まで現場でいろいろ実装してきたけど、Dtoにgetter/setter書いた箇所で、99.9%は振る舞いがなかった。簡単にできるからと言って、getter/setterを書くのは、ただコード量を増やしているだけなので、FWの制約やプロジェクト方針が無い限りいらなくね？って思う。
進撃の巨人のザックレー的にいえば、実は好きなのかも知れない。
