C#でのアクセシビリティ

C#にはアクセシビリティというものがあり
private
internal
publicなどがあります。
そのほかには
protected
protected internalがあります。

 

 

publicであれば同一アセンブリと
そのアセンブリを参照しているアセンブリから参照できます
（要するにすべて）

privateはそのクラスのみ
internalは同一アセンブリのみ
protectedは同一クラスと派生クラスからのみ参照可能
protected internalはprotectedとinternalの両方の効果があります。
プログラミングに慣れていない方は
一見publicを使えばどこからでも参照できて
全部これでもいいように思います。

しかし全くそういう事はありません。

このアクセシビリティをうまく使わないと
とても分かりにくい，改造しにくい，
ダメダメなプログラムが出来上がります。

そういう私も昔はそんなダメダメな
プログラムを書いていました。

では，なぜだめなのか，一緒に考えていきましょう。

例えばWindowsフォーム画面を作って
そこにボタンを一つ置いたとします。

C#のデザイン画面を見てみましょう。

こんな感じでボタンが宣言されています。
これがもし

だったらどうですか？
違いはボタンのアクセシビリティだけです。
publicに変更しました。

この瞬間からこのボタンがあるプロジェクト内とこのプロジェクトを参照する
すべてのコードでこのボタンの値を変更できるようになりました。

これってすごく怖いですよね。

このプログラムをリリースした後にもし
このボタンに対して何か修正を加えるたびに
どこに影響するかを調べる必要がありますが，
どこからでも値を変更できる時点で
ものすごい量のコードをチェックしないと
いけなくなります。

要するにアクセシビリティというのは非常に大切で
publicにすればどこからでも見られて便利な気もしますが
とても見通しの悪いプログラムになってしまいます。

アクセシビリティはできるだけ
外から見えないほうがいいです。
とはいえ，クラスなどはprivateのクラスでは
誰も使えないクラスになってしまい意味がありません。
C#でもクラスを作成したらデフォルトはinternalになっています
（アクセス修飾子を省略するとC#では変数はprivate，
クラスはinternalになります）
なので，魅せる必要のある最小のアクセシビリティにしましょう。
その上で，必要になった時にpublicに昇格させるという
設計がよいかと思います。

簡単ですがアクセシビリティに関しては以上です。
最後までお読みいただきありがとうございました。

トップページへ戻る

オブジェクト指向の原則 単一責務の原則

C#を正しい3層構造で造れてますか？

非売品コースを受け取る

#00_はじめに
#01_単一責務の原則とは
#02_原則違反の例
#03_変更理由単位でクラスを分ける
#04_3層構造の例
#05_修正箇所を最小にできる
#06_修正する場所が明確になる
#07_共通化しましょうという話ではない
#08_少々悪いコードでも問題視しない理由
#09_探しやすいコード
#10_クラスは機能ごとに小さく作る
#11_小さなクラスがそれぞれに協調して目的を達成させる
#12_多数の部品群のなかから摘まんで作る
#13_クラスはどこまで小さくすればいいのか
#14_アンダーソン式単一責務の原則
#15_最小カプセルの検証_監視タイマークラス
#16_最小カプセルの検証_受注画面クラス
#17_最小カプセルの検証_ユーザークラス
#18_最小カプセルの検証_商品マスターデータアクセス
#19_登場人物に合わせたモデリングの四角と線
#20_四角と線を最小カプセル化する
#21_アンダーソン式手順
#22_パターンを見つけ出す
#23_プログラミングの自問
#24_さいごに