何となく Blog by Jitta
Microsoft .NET 考

目次

Blog 利用状況
  • 投稿数 - 761
  • 記事 - 18
  • コメント - 30587
  • トラックバック - 222
ニュース
  • IE7以前では、表示がおかしい。div の解釈に問題があるようだ。
    IE8の場合は、「互換」表示を OFF にしてください。
  • 検索エンジンで来られた方へ:
    お望みの情報は見つかりましたか? よろしければ、コメント欄にどのような情報を探していたのか、ご記入ください。
It's ME!
  • はなおか じった
  • 世界遺産の近くに住んでます。
  • Microsoft MVP for Visual Developer ASP/ASP.NET 10, 2004 - 9, 2011
広告

記事カテゴリ

書庫

日記カテゴリ

ギャラリ

その他

わんくま同盟

同郷

 

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

 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数を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全盛時代を生き残る方法論を論じる、くらいのレベルの高さがあって欲しいですね。

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

投稿日時 : 2010年5月28日 22:20
コメント
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    未記入
    Posted @ 2010/05/29 18:47
    センタリング→左寄せ?

    #内容には関係ないですが、コラムへコメントされているときも気になったもので。。。

  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Jitta
    Posted @ 2010/05/30 10:30
    あれ?私の環境(Opera)では、センタリングになって見えているのですが?おおっと、IE8 で見たら、左寄せだぁ~!Opera の、スクリプトや IFrame を切っているので、table 要素の終端が検出できていないのかなぁ?
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Soda
    Posted @ 2010/06/05 7:51
    staticにしちゃうのは、クラスを関数の集合だと考える、ライブラリ感覚じゃないかなぁ。
    全部を静的関数にすることで、インスタンスなしに使えるのが利点だと感じているわけですし。
    全てが変数だと考えてしまうと、構造体になってしまって、中間がない状態って感じ?

    構造体を引数にして、関数に放り込めば、結果がでるわけで・・・
    変数を関数を1つにまとめることで、汎用性を奪っていると考えているのかもしれない。

    初めてクラスをみたときの感想はそんな感じだったなぁ。
    仮想関数も、なんのためにあるのか、わからんかったしw
    派生というものを知って、初めて自分にとっての価値が生まれたんですよ。
    自分の作っていたものに使えるってな感じでw

    結局、自分にとって便利だと感じないものは、自分にとって価値が薄いんでしょうねぇ。
    少なくとも、筆者のプログラミング上では、不要なものだったのでしょう。
    だって、オブジェクトが存在していないんだから(^^;
    それにたいして、オブジェクトのありかたを説明するのは、筆者からするとズレた指摘というか、理解できない内容なのかもしれませんねぇ。
    根本的なところで、クラスを使っていること自体が間違いなのかもしれません。
    つーか、なんでクラスを使っているのか、わからなかったというのが私の感想w
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Jitta
    Posted @ 2010/06/07 18:37
    Sodaさん、コメントありがとうございます。


    > 変数を関数を1つにまとめることで、汎用性を奪っていると考えているのかもしれない。
    なるほどー。言われてみれば、確かにそんな感じでした。「これを変えたらどうする?」が続くのは、ずっと後からですね。
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    みながわけんじ
    Posted @ 2010/06/09 16:24
    何故インスタンスを作るの?

    メンバー変数をメモリ上に格納する領域を作るため。

    想像するに、もともとクラスってステートマシンをパクった考え方で作られている。メンバー変数は状態変数のパクり。でも学者さんは、パクりだって言えないから現実世界を表現したものだと崇高そうなダマシを言っているだけ。本当は、システムはステートマシンの集合で構成されるから、ステートマシン的な、状態変数であるメンバー変数と関数でクラスを構成したとと解釈するのが、システム的センスのある人には自然だ。

    同じクラス(同じタイプのオブジェクト)で複数のものを同時に制御するには、メモリ上に複数のメンバー変数を格納する領域を使わなければならない。だからインスタンスを生成するのだ。

    なお業務システムは状態をDBに書き込む、更新するの通常なので、メンバー変数はほとんど不要。メンバー変数がないクラスは単なる関数を集めたものにすぎない。
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Jitta
    Posted @ 2010/06/10 21:45
    みながわさん、コメントありがとうございます。

     どうも、「オブジェクト指向」に対する理解が足りていないように思われます。

    > 何故インスタンスを作るの?
    > メンバー変数をメモリ上に格納する領域を作るため。

     どのような意図があるのか、計りかねます。
     コンピュータでデータを処理する場合、必ず「メモリ上に格納する領域」を作らなければなりません。C 言語、Java、JavaScript、VisualBasic、C#、Perl、PHP、BASIC、FORTRAN、COBOL、Z80-Assembler など、どの言語も、インスタンスを作ります。データベースにおいても、Stored Procedure を使うなら、その言語ではインスタンスを作ります。もっとも、「インスタンス」という名称ではないかもしれませんが。

    > もともとクラスってステートマシンをパクった考え方で作られている。メンバー変数は状態変数のパクり。

     安易な想像で、知ったかぶりをするから炎上した、ということを、心にとめていただきたいと思います。
     では、「状態変数」ではない変数とは、どのようなものでしょうか。どのような変数であっても、処理中のデータの状態を示していると言えるのではないでしょうか。


    > なお業務システムは状態をDBに書き込む、更新するの通常なので、メンバー変数はほとんど不要。メンバー変数がないクラスは単なる関数を集めたものにすぎない。

     オブジェクト指向は、「変数」と「操作」をまとめて管理するところが味噌です。これを切り離して考えるなら、オブ
    ジェクト指向を習得することはできないでしょう。


    > 同じクラス(同じタイプのオブジェクト)で複数のものを同時に制御するには、メモリ上に複数のメンバー変数を格納する領域を使わなければならない。だからインスタンスを生成するのだ。

     データベースでも同じです。意味のあるデータの集合を複数作るために、「行」というインスタンスを生成しています。データベース内には「行」という概念はなく、意味のあるデータの集まりというインスタンスを人に見やすくするために「行」としてまとめているとも言えるでしょう。


     さて、オブジェクト指向が力を発揮するのは、「メンテナンス フェーズ」です。設計、製造の段階では、オブジェクトの切り出しや役割の分割など、手間がかかるだけです。この辺は、後でエントリを作るつもりですが、以前にエントリを作っているかもしれない。
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Soda
    Posted @ 2010/06/10 23:18
    >みながわけんじさん
    >なお業務システムは状態をDBに書き込む、更新するの通常なので、メンバー変数はほとんど不要。メンバー変数がないクラスは単なる関数を集めたものにすぎない。

    これが全てなんじゃないかな?
    オブジェクトとして考えているものが無いのだから、オブジェクト指向がピンとこなくても仕方が無いんじゃないかな。
    クラスを使っているからオブジェクトってわけでもないですしね。

    ただ、全てをstaticにしてしまうなら、グローバル関数というか、ライブラリと変わらないような気がします。
    あえてクラスを使う必要がなかったのではないかと(^^;

    C#は私が、よくわかってないので、説明できませんがー
    C++の感覚でコラムを読んだときに思ったのは、グローバル変数のように、インスタンスを作ればstaticにしなくてもいいんじゃないかなと。
    コンストラクタや、デストラクタが使えるし、なにより仮想関数が普通に使える。
    仕様変更があったりしても、派生させたクラスで変更を組み込んで差し替えることも簡単にできる。

    グローバルな場所で
    CHoge tool;
    と宣言して、使うときには、

    tool.使いたい関数

    仕様変更があった場合は
    CHage tool; //CHageはCHogeから派生してつくったクラス
    と、宣言を差し替えるだけで、呼び出している部分の変更はいらない。
    また、ポインタにすることで、動的に差し替えることも簡単ですね。

    グローバルな場所で
    CHoge *tool;
    として、実行時に

    if (Hogeな条件)
    {
     tool=new CHoge;
    }
    else
    {
     tool=new CHage;
    }

    みたいなー感じ?
    static宣言されているものよりも、簡単に変化を加えることができて、お得じゃないかな?
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    みながわけんじ
    Posted @ 2010/06/11 9:43
    >では、「状態変数」ではない変数とは、どのようなもので>しょうか。どのような変数であっても、処理中のデータの状態を示していると言えるのではないでしょうか。

    単なる関数は引数とローカル変数を用いてリターン値が決められるものであるから、関数の引数、ローカル変数、リターン値は状態変数とはいえません。

    その意味ではグローバル変数は状態変数です。オブジェクト指向の隠ぺい化とは、グローバル変数を使わずにメンバー変数で必ずしもpublic公開しなくても状態変数を実現したことに意味があるのです。

    古典的なステートマシンの深い理解なしで、クラスを作ってしまうことは非常に危険で、メンテナンス、可読性の点で難があるでしょう。

    > オブジェクト指向は、「変数」と「操作」をまとめて管理するところが味噌です。これを切り離して考えるなら、オブ
    ジェクト指向を習得することはできないでしょう。

    これってもろに状態変数そのものの説明なんですけど、ステートマシンのコンセプトがまったくわかっていないですね。

    > メンバー変数をメモリ上に格納する領域を作るため。
     どのような意図があるのか、計りかねます。
    >コンピュータでデータを処理する場合、必ず「メモリ上に格納する領域」を作らなければなりません。

    クラスライブラリを作る人と開発ツールを使う人は別人あることが普通です。クラスライブラリを作る人は、開発者が同じクラスで別のインスタンスを何個作るかわからないわけです。開発者が必要に応じて、ひとつ、または複数個のインスタンスを生成するわけです。

    開発者が必要に応じて、インスタンスをひとつまたは複数個生成する。インスタンス生成するごとに、必要なメモリ領域を確保できるということです。

    TO Soda さん

    インスタンスを生成するか否かは開発環境(フレームワーク、クラスライブラリ)によると思います。もっとも個人の好みもありますがね。Visual Studio の GridViewという表形式のオブジェクト(特にテンプレート列)についてはローカル関数かstatic関数で値算出し表示させたほうが圧倒的に手軽です。

    現状の私の認識では、クラスとはステートマシンであり、多種のクラスを作って、ほとんど共通のメンバー変数、メンバー関数があれば、既定クラスを作って、それから多種のクラスを既定クラスから継承させるのが望ましいという当然の結果です。

    社内SEとして実際のユーザーの仕様変更は頻繁にあり、ほとんどはロジック関数のアルゴリズムの変更によるもので、古い部分をコメントアウトして、新らしいプログラムを数行追加するようなものです。あるいはパラメータを追加したいということで、関数に引数を追加する変更もかなりあります。

    オブジェクト指向をやりたいならば、業務アプリケーションをやるのではなく、フレームワークやクラスライブラリを作る仕事を選ぶのが正解ですね。それならば、継承やポリもーフィズムなどの技法がふんだんに使えるはずですよ。
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Soda
    Posted @ 2010/06/11 22:10
    >みながわけんじさん
    こークラスに対しての感覚に温度差があるんじゃないかなぁ。
    私にとって、クラスは便利な変数であって、関数というか、動作するようなものというイメージは薄いです。

    int i;
    などと宣言するのと同じ感覚で、
    CHoge hoge;
    と使うし、クラスライブラリのクラスから派生させて、自分用にカスタマイズして使うことも多いです。

    上位互換にする必要があるときには、便利だったりします。

    >オブジェクト指向をやりたいならば、業務アプリケーションをやるのではなく、フレームワークやクラスライブラリを作る仕事を選ぶのが正解ですね。

    オブジェクト指向をやりたいのではないですね。
    やりたいことが、オブジェクト指向だと簡単だから、オブジェクト指向を選択するのですよ。
    まぁ、そういう設計思想の元で作っているというだけですね。
    ですから、それとは異なる設計思想ならば、オブジェクト指向など使わなくてもいいと思います。
    手段であって、目的ではありませんからね。

    人によって、設計思想が違いますので、みながわけんじさんが設計するアプリケーションにはオブジェクト指向が合わないのでしょう。
    今までの話から、オブジェクトと考えられるものが無さそうですし。
    おそらく、みながわけんじさんに違うぞーと言っている方々は、設計思想が異なるのですよ。
    そして、その設計思想では、オブジェクトが存在しているわけです。
    コラムの

    >staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。

    も、具体的な例を提示すれば、もう少し違う反応があったと思います。
    個人的な感覚では、staticは限定された目的で使われるので、オブジェクトとしてはわりと特殊なイメージがあります。
    おそらく、同じように感じた方々が、「そのようなstaticの使い方のほうが珍しい」と思ったのではないかと考えています。
    そうですねぇ、オート変数をいちいち宣言するのが面倒だから、staticにしてグローバル変数にしてしまったような感じでしょうか?
    そして、staticを使わないことをバカにしているような状態・・・かな?

    staticという書式があるのだから、どのように使うのかは、自由なわけです。
    しかし、自分が気がついていないだけで、もっと適切なものがあるかもしれないじゃないですか。
    使っている背景を提示しないことで、生まれる誤解は大きいと思いますよ。
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Jitta
    Posted @ 2010/06/13 19:27
    > 単なる関数は引数とローカル変数を用いてリターン値が決められるものである
    それは、「数学的な」関数ですね。CLR でも、Math クラスの“関数”は静的メソッドとして定義されており、関数としてあつかいます。
    しかし、業務では、何らかのデータの状態を扱います。う~ん、一般的な業務システムって、やったことないんだよなぁ。そうそう、「バグ情報管理システム」でいこうか。「バグ情報」には、バグが「発生した」ので連絡した状態、「調査している」状態、原因がわかって「修正した」状態、発見者が確認して「完了した」状態があります。この、「状態遷移」をさせるアルゴリズム(問題を解決するための手順)を、情報の中に閉じ込めよう、というのが、オブジェクト指向です。「指向」とは、「考えや思考を、一定の方向へ向ける」という意味があります。であるなら、オブジェクト指向とは、「考えを、オブジェクトの方向へ向ける」という意味になります。我々は「オブジェクト指向」で止めることが多いですが、英語では Object Oriented で形容詞であり、このあとに形容される名詞を付けるのが普通です。
    ちょっとずれましたが、オブジェクトに指向します。何故か。
    > 社内SEとして実際のユーザーの仕様変更は頻繁にあり、ほとんどはロジック関数のアルゴリズムの変更によるもので、古い部分をコメントアウトして、新らしいプログラムを数行追加するようなものです。
    まさに、このためです。
    まず、オブジェクトに指向された設計では、オブジェクトを切り分ける所から始まります。GUI の部品が使いやすいのは、何故でしょう?高度に部品化され、オブジェクト間の結合が粗だからです。ListViewItem は、ListView がなければ使い物になりません。そして、ListViewItem を変更すれば、それを表示させるための ListView にも変更が必要になるでしょう。この様な「変更の連鎖」の発生を最小限にとどめることを、まず、設計しなければなりません。

    おっと、携帯から投稿できる上限文字数が近いので、いったん切ります。
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Jitta
    Posted @ 2010/06/13 19:41
    あ、書いておくのを忘れていましたが、16年前、オブジェクト指向言語を勉強し始めた頃は、みながわさんと似たことを思っていました。ちょっと出かけることになったので失礼します。
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Jitta
    Posted @ 2010/06/13 23:16
    さて、と。

     私がオブジェクト志向言語の、プロセス志向言語(オブジェクト志向言語以前の言語のことを、こう呼んでいます)に対するアドバンテージは、「手続きと情報の統合」にあると考えています。このことによって、手続きの責任範囲が狭まり、コードの保守がし易くなると考えます。従って、このあたりの言葉には、賛同できません。

    > 単なる関数は引数とローカル変数を用いてリターン値が決められるものであるから、関数の引数、ローカル変数、リターン値は状態変数とはいえません。
    > 現状の私の認識では、クラスとはステートマシンであり、多種のクラスを作って、ほとんど共通のメンバー変数、メンバー関数があれば、既定クラスを作って、それから多種のクラスを既定クラスから継承させるのが望ましいという当然の結果です。
    > オブジェクト指向をやりたいならば、業務アプリケーションをやるのではなく、フレームワークやクラスライブラリを作る仕事を選ぶのが正解ですね。それならば、継承やポリもーフィズムなどの技法がふんだんに使えるはずですよ。

     まず、なぜ「コードの保守が容易になる」と考えるか、説明します。
     一般的に「オブジェクト志向」といわれますが、これは英語では Object Oriented であり、形容詞です。従って、この後ろに形容される名詞が無ければなりません。その名詞とは、「言語」であったり、「設計」であったり、「分析」「プログラミング」といった名詞が続くことが多いでしょう。おおっと、ここで「指向」ではなく「志向」の字を使うのは、「“考え方や意識を”オブジェクトに向ける」ことを強調するためです。
     さて、何に対する「考え方や意識」を、オブジェクトに向けるのでしょうか。まずは、設計です。
     では、「オブジェクト」とは、何でしょうか。たいていは「もの」と訳され、「鯛焼き」や「人間」が説明のために用いられます。しかし、そんなもの、プログラムするわけではないので全く参考になりません。
     では、私は何でたとえましょうか。
     具体的な仕事内容が出てきていないので、私の方の仕事内容を出します。勤怠管理で行きましょう。
     勤怠管理をするには、「出勤日」と、出勤日ごとの「出社時間」「退社時間」が必要です。簡便性のために、フレックスは考えないこととにします。それぞれの出勤日には「勤務開始時間」と、「勤務終了時間」があります。出社時間が勤務開始時間より遅れていれば「遅刻」、退社時間が勤務終了時間より早ければ「早退」として、10分単位でカウントします。また、退社時間が勤務終了時間より遅ければ「残業」として、1時間ごとにカウントすることとします。
     さて、これだけの中から、私ならどうするか。とりあえず、言語は C# を使うとしましょう。C# には DateTime クラスがあるので、時間はこれで表しましょう。時間間隔は TimeSpan クラスがあり、DateTime.Subtract で計算できますから、これをそのまま使います。
     すると、新たにクラスを定義しないなら、次のようになるでしょうか。
    DateTime 出社時間[31];
    DateTime 退社時間[31];
    uint 遅刻早退累計;
    uint 残業累計;
    static TimeSpan 遅刻時間を求める(DateTime 基準時間, Date 出社時間) {
      if (基準時間 < 出社時間) {
        return 出社時間.Subtract(基準時間);
      }
      return new TimeSpan(0);
    }
    static TimeSpan 早退時間を求める(DateTime 基準時間, Date 退社時間) {
      略
    }
    static TimeSpan 残業時間を求める(DateTime 基準時間, Date 退社時間) {
      略
    }

     しかし、私は、クラスを定義します。

    class 時間線分
    {
      DateTime 開始;
      DateTime 終了;
      public TimeSpan 経過時間() { return 終了.Subtract(開始); }
      public bool 完全に含んでいるか(時間線分 検査対象) {
        if (検査対象.開始 < this.開始 && 検査対象.終了 > this.終了) {
          return true;
        } else {
          return false;
        }
      }
      public TimeSpan 不足時間(時間線分 基準時間) { 略 }
      public TimeSpan 超過時間(時間線分 基準時間) { 略 }
    }
    class 一日のデータ
    {
      時間線分 勤務時間;
    }

     さて、先にオブジェクト志向言語のアドバンテージは、「手続きの責任範囲が狭まり、コードの保守がし易くなる」と書きました。どのように、コードの保守がし易くなるのでしょうか。
     見ていただければわかりますが、上の「仕様」は、「休憩時間」を考慮していません。「17:30~18:00, 19:00~19:30 は休憩時間なので、残業時間にカウントしない」という仕様が追加になったら、どうしましょうか。
     みながわさんは、次のように書かれています。
    > あるいはパラメータを追加したいということで、関数に引数を追加する変更もかなりあります。
    「残業時間を求める」に対して、「休憩時間1の開始時間」、「休憩時間1の終了時間」、「休憩時間2の開始時間」、「休憩時間2の終了時間」・・・を追加することになるのでしょうか。
     私の方法ならば、休憩時間1、休憩時間2、・・・の、時間線分オブジェクトを生成します。それぞれを勤務時間に対して含まれているか調べ、含まれているなら休憩時間の経過時間を引くことになります。どちらが、ミスをしにくいでしょうか。どちらが、修正が容易でしょうか。

     それとも、時間線分クラスを作ることは、「業務アプリケーションをやるのではなく、フレームワークやクラスライブラリを作る仕事」になるのでしょうか。しかし、業務アプリケーションにも、その業務に特化したフレームワークやクラスライブラリが必要ではないでしょうか。

     私は、いろいろな人の話を聞いていると、かなりのんびりした仕事しかしていないようです。開発期間が三ヶ月から、時には一年あるような業務しかしていません(“しか”ってことはないけれど、そういうのが多い)。なので、オブジェクト志向言語を使い始めてから16年ほどになりますが、その間にこなした業務は10あるかどうか、です(改造は含まず)。そんな数しかこなしていなくても、特に改造案件が入ると、「ああ、オブジェクト志向でやっていてよかった」と思います。まだまだオブジェクトの切り出しが甘いですが、甘いなりにも切り出しているからこそ、修正範囲が特定しやすく、影響範囲を限定しやすく、テスト範囲を絞ることができています。「社内SEとして実際のユーザーの仕様変更は頻繁にあ(る)」業務をされているのなら、もう少し身を入れてオブジェクト志向分析をされることを勧めます。
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Jitta
    Posted @ 2010/06/13 23:36
    日記カテゴリに、「オブジェクト指向」を追加しました。
    http://blogs.wankuma.com/jitta/category/2217.aspx
  • # オブジェクトを指向してみる/そもそも「オブジェクト」って、何?
    何となく Blog by Jitta
    Posted @ 2010/06/19 22:29
    オブジェクトを指向してみる/そもそも「オブジェクト」って、何?
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    VMAXON
    Posted @ 2010/07/14 22:53
    Jittaさん、こんばんは。

    Posted @ 2010/06/13 19:27 ~ Posted @ 2010/06/13 23:16
    の説明がとてもわかりやすかったです。

    同感です。クラスの結合は疎にしておきたいですよね。

    > みながわけんじ
    > 社内SEとして実際のユーザーの仕様変更は頻繁にあり、ほとんどはロジック関数のアルゴリズムの変更によるもので、古い部分をコメントアウトして、新らしいプログラムを数行追加するようなものです。

    結合が疎であればある程、みながわさんが望んでおられる仕様変更にも柔軟に対応できます。

    そのために、インターフェースや抽象クラスを使ったり、DIやAOPを使ったりもします。

    みながわさんは、インターフェースや抽象クラス、DI、AOPなどをお使いになったことがありますか?
  • # re: オブジェクトを指向してみる/何故インスタンスを作るの?
    Jitta
    Posted @ 2010/07/27 22:30
    とっても遅い返信でごめんなさい。

    > 説明がとてもわかりやすかったです。
    ありがとうございます!!
     一時期、天狗になっていただけに、とってもうれしいです。また天狗にならないように気をつけます!
  • # 7 The big band From their strategies 3
    Typicalcat20
    Posted @ 2019/12/31 22:13
    http://www.rgcjackson.co.uk/%ef%bb%bfsenior-online-dating-websites-for-relationships-free-month/ what dating online websites are no membership https://www.ajlegal.in/mature-best-serious-relationship-online-dating-site-blogs.wankuma.com.pdf 60's and older mature dating online websites
タイトル  
名前  
Url
コメント