ユビキタス世界までの道の駅

> Sharedを使うことによって、スタティックメンバとしたことで、どういうメリットがあるのですかね？

メリットではなく型の性質ですね。
ですので「どちらがよいか」という問題ではありません。

Stringクラスの
Public Shared Compareメソッド
Public CompareToメソッド
を比較してみるとよいです。
型がメソッドを持つ感覚がわかると思いますよ。

ありがとうございます。
見てみます＾＾

> たべもんだから、変なものが入っていては困るから、口に入れるまでにちゃんと検査したものを、正式なクッキーと呼ぶんだよ。それがクッキーなんだよ

実に興味深い問題です。
Ibutuに渡すのがCookie型である時点で、それは「ちゃんと出来上がったクッキー」ではないのか、という問題が考えられます。
異物が混入していないものだけがクッキーであるならば、とりあえず焼きあがったけれど未検証のものはまだクッキーではないわけで、じゃあその「未検証の焼き菓子」の型は何なのさ？　と。
「Cookie型である＝食べられるクッキーである」ということを保証するのなら、コンストラクタの最後に検証をして、ダメだったらコンストラクタから例外を投げてしまうという設計もあり得ます。

static / shared にはいくつかの使い道があると思います。
例えば…

１：本当に「クラスがメソッドを持っているべき」な場合。
いい例を考えるのが難しいです。
例えば、社員クラスの静的メンバとして、総社員数を持たせるということが考えられます。
しかし、この場合、社員コレクションクラスのインスタンスを作って管理した方が適切だと思います。

２：シングルトンな場合。
見た目は静的ですが、その実、「そのクラスのただひとつのインスタンス」に対する操作です。
例えば Console.WriteLine とか MessageBox.Show とか。
Console.WriteLine は、コンソールはアプリに１つしかないので、２つ以上 new されては困るからこうなっています。
MessageBox は別に new されても困らないんですが、インスタンスをたくさん作っても仕方がないのでこうなっているんでしょう、たぶん。

３：インスタンスを必要としない場合。
例えば Directory.CreateDirectory。
Directory クラスは既に存在するディレクトリを表すクラスですが、それをこれから作ろうとしているわけですから、インスタンスメソッドにすることができません。
ただ、この Directory の例は、Directory クラスの静的メソッドにするより、FileSystem クラスでも設けて、そのメソッドにする方が適切なのにと思います。

静的メンバの使い道

>Console.WriteLine は、コンソールはアプリに１つしかないので、２つ以上 new されては困るからこうなっています。
>MessageBox は別に new されても困らないんですが、インスタンスをたくさん作っても仕方がないのでこうなっているんでしょう、たぶん。
なるほどと思います＾＾

自分で上げている例はよくないですね・・・・。
正しく理解していなかった、イメージできなかったので、
ありがとうございました。