実はオブジェクト指向ってしっくりこないんです！（システムエンジニア 生き残りの極意）より：

　「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。

　staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。

向こうでコメントしようかと思ったけど、もったいないのでエントリーにする。

さて、コメントに、コラム著者のサイトSE WORLD システムエンジニアの世界 IT技術というサイトへのリンクがありました。そしてそこには、「ASP.NET ASP.NETのサンプルコードです。典型的なコードパターンを列挙してみました」というのがあるので、ここを見ます。…だって、MVP for ASP.NET なんだもん、一応。その中で、これを取り上げてみる。

ファイルアップロードコントロール（SE WORLD システムエンジニアの世界 IT技術）より：

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
public partial class _Default : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
    }
    protected void Button1_Click(object sender, EventArgs e)
    {
        if (FileUpload1.HasFile) {
            //string strSaveAs = "C:/test/" + FileUpload1.FileName;
            string strSaveAs = "//マシン名/フォルダ名/" + FileUpload1.FileName;
            FileUpload1.SaveAs(strSaveAs);
        }
    }
}

　リモートマシンにも保存できるが、アクセス権がeveryone 書き込みになってないと難しい。ちなみにIIS6.0のASP.NETのプログラムアカウントのデフォルト値はNetwork Serviceです。

センタリングされていて見にくいので、見やすいように修正しました。

さて、この中で、FileUpload1 というのが、FileUpload クラスのインスタンスです。そして、HasFile とか、SaveAs というのは、FileUpload クラスのメンバーです。では、いちいちインスタンス宣言しているので笑ってしまうということなので、インスタンス宣言しなくてもいいように（インスタンスを作らなくてもいいように）、FileUpload クラスのメンバーが全て pubulic static宣言されていると仮定します。つまり、「pubulic static宣言だと、こんなに使いにくいぞ」ということを示すことで、なぜインスタンスを作るのかを理解してみよう、という試みです。

FileUpload クラスのメンバーが全て静的なので、1ページからは1度に1つのファイルしか、アップロードできなくなります。複数のファイルをアップロードしようとすると、FileUpload クラスから導出して、FileUpload1 クラス、FileUpload2 クラス、FileUpload3...と、インスタンスの代わりにクラスを複数作らなければなりません。これは、「コードを書く手間」を考えると、とても不便ではないでしょうか。また、それぞれでクラスが違うのですから、最初に配列を宣言して、インスタンスを作るというわけにもいきません。これも、不便ではないでしょうか。

// 配列を宣言して、インスタンスを生成する
FileUpload[] fileUp = new FileUpload[10];
foreach (FileUpload f in fileUp) {
    f = new FileUpload();
}
// メンバーを静的にすると、上記のように出来ず、
// クラスを10個作らなければならない
class FileUpload01 : FileUpload {};
class FileUpload02 : FileUpload {};
class FileUpload03 : FileUpload {};
...
// その後、配列に登録する。
FileUpload[] fileUp = new FileUpload[10];
fileUp[0] = FileUpload01; おおっと、クラスは登録できないや！！

これで、「static にせずにインスタンスを作るのはなぜ？」の答（のひとつ）になるかな？

それでは、反論も考えてみましょう。

2010年4月28日 (水) 08:53

むしろC言語の構造体はいやになるほど書いたから、逆にビジネスロジックのクラスの優位性についてピンとこないのです。

なるほど。

FileUpload は、データだけを持つ構造体であるとすると、どうなるでしょうか。例えば、こんな定義がどこかにあって、それを使って保存することになります。

public class StaticFunctions {
    private StaticFunctions() {};
    public static void SaveAs(const FileUpload fu, const string saveFileName) {
        // 処理は省略
    }
    public static void SaveAs(const FileStream fs, const string saveFileName) {
        // 処理は省略
    }
    public static void SaveAs(const MyStructure ms, const string saveFileName) {
        // 処理は・・・おおっと、オーバーロードさせてよかった？
    }
}

私は、似て非なる構造体を多数書いたので、クラスの方がいい、と思いましたね。

様々なコメントが付いていますが、このコメントがもっとも秀逸だと思います。

2010年4月27日 (火) 16:14

OOPは理解できないから使わない、と主張されるのは結構だと思います。

しかし、自分が理解できないからといって「知ったかぶってOOPするヤツら笑っちゃう」というような論調で話を進められるのは宜しくないですね。

変数が隠蔽できるか否かはOOPの本質ではないんです。そもそも言語仕様としてクラスやプロパティがあるかどうかも本質ではないのです。言語仕様はよりOOPしやすくするための道具にすぎません。

極意を示すコラムなのですから、OOPを理解したうえで「俺はOOPしない！」と主張する生え抜きのロートルエンジニア（＜良い意味で言っています）が、その経験と技術でもってOOP全盛時代を生き残る方法論を論じる、くらいのレベルの高さがあって欲しいですね。

こんな風に、簡単にまとめられる技量が欲しいです。。。