オブジェクト

オブジェクトとは

オブジェクトとは、物、物体、対象、目的、目標対象のこと。
コンピュータのシステムでは、要件定義で具体的に人間が認識する登場人物(登場物)のことをオブジェクトという。
オブジェクトには下記の4つの特性がある。

1.リレーション(関係):
オブジェクトは単独で存在することはない。必ずほかのオブジェクトと関係を持つ。

2.属性:
オブジェクトは、固有の姿・形・性質などを持つ。これらのうち、文字列とか数値で表されるものは、新たなオブジェクトを立てるのではなく、属性として扱う。

3.操作:
各オブジェクトは固有の(仕事)振る舞いを持つ。これを操作と呼び、動詞で表現する。

4.アイデンティティ(識別):
各オブジェクトは、ほかのオブジェクトから自らを識別できるアイデンティティを持つ。

オブジェクトを抽象化(共通化/分類化)したものをクラスという。

オブジェクト指向は、対象であるみんなに仕事をやってもらう指向である。
反対にサブジェクト指向は、主体が仕事を自分でやる指向である。
つまり、サブジェクトがオブジェクトに仕事の依頼を行って初めて、システムが成り立つ。

オブジェクト指向システムは確かに魅力的であるが、大規模開発には適さない。

オブジェクト指向

「オブジェクト指向とは」の前に・・・

オブジェクト指向ってなに?」と思われている方は、たくさんいます。オブジェクト指向を理解しようとすると

といった、3つの考え方について理解し、比較した差分で考えるのがよいでしょう。
しかし、この3つはどの方法で行っても、最後は同じプログラムにたどり着きます。
オブジェクト指向ってなに?」と思われている人は、
システム開発は、どう行えばよいか?」を気にしている人です。
方法論は、あくまでも方法論で学校の勉強のレベルです。
方法論は、アプローチの方法が違うだけで、良いシステムの結果は同じです。
大切なことは、最終的にどれだけ何と何が同じで、何と何が違うのかを洗い出してシステムを作り上げるかということである。
その手段として、プロセス指向データ指向オブジェクト指向
しいては、アスペクト指向、サービス指向、ビジネスプロセス指向があります。
結局、どれでやっても、システム開発/メンテナンスが良いものを作りたいのです。
これを踏まえた上で、ここでは、他の方法論と比較しながらオブジェクト指向について記述していきます。

オブジェクトとは(1)

Objectとは、物、物体、対象、目的、目標対象のこと。
そんなことは、みんなわかっているし、調べればわかる。
システムを設計する際、まずはじめに要件定義を行います。
この要件定義で登場する具体的に人間が認識する登場人物のことをオブジェクト指向でのオブジェクトといいます。
たとえば、組織を管理するシステムを作るとします。組織内には、社長の鈴木さん、部長の佐藤さん、田中さんなどがいます。この人たちの管理職や各部門、各課の関係を登録して管理するシステムを作成するとします。
上記の文章で、オブジェクトにあたるのはどれでしょうか?
オブジェクトは具体的に人間が認識する登場人物、つまり
鈴木さん、佐藤さん、田中さんです。
具体的な登場人物でない(つまりオブジェクトではない)ものである抽象的な名詞も登場しています。
組織、管理職、部門です。
勘がいい人ならこれで、オブジェクトがなにかニュアンスをつかめたでしょう。しかし、いまいちよくわからないと思うので、別の例を次に上げます。

オブジェクトとは(2)

業務システム開発をしていると、知らないですまないデータベース。プロセス指向(POA)でシステムを開発しようとしても、昔のようにSAMファイルにデータを書き込むのではなく、リレーショナルデータベース(RDB)にデータを書くようになった。
よって、POAで開発を進めようとしても、データベース設計が必要となり、データ中心指向(DOA)でも、設計する必要が出てきました。
ここで、スケジュール通りにすすまない状態が発生する。なぜなら、POAでシステム設計する人とDOAでシステム設計する人が別々に設計するので、意思疎通が難しくなるのである。こんなトラブルにならないように、優秀なシステムアーキテクチャは、先にER(エンティティリレーション)設計(DOA設計の一部)をしてしまう。そのあとで、業務手順に沿ってPOA指向で機能設計する。
「なんやぁ、オブジェクト指向してるやん。」
で、本題なんですが、このようなシステム開発されている方々なら、オブジェクトというのは、データベース内の1レコードと思っていただけば良いのです。
テーブル(エンティティ)設計した際の、実際にテーブルに入るレコードのことです。社員テーブル内の1レコード(鈴木さんとか佐藤さん)のことです。
そういう風に理解していただければ、一番わかりやすいと思います。
どうです? ニュアンスつかめました?
ただ、テーブル内の1レコードはオブジェクトなんですが、テーブルに書き込まないオブジェクトってのが他にあるだけです。
次は、そのようなオブジェクトについて上げてみます。

オブジェクトとは(3)

システム設計でデータベース設計を行う場合は、静的情報のみを洗い出します。たとえば、社員というテーブルには、社員番号、社員名、性別、生年月日、住所、電話番号といったように属性を持ちます。このように、属性をもつものしかER設計では注目しません。
しかし、該当システムの開発においては、このような属性は持つ必要がないオブジェクトが存在します。仕事しかしない、つまり動的情報しかもたないオブジェクトです。
このオブジェクトも一緒に考えることがオブジェクト指向ですね。
組織を管理するシステムでは、鈴木さん、佐藤さんという実際に組織に属しているオブジェクトは、データベースに登録されます。しかし、この組織に対する操作は、データベースに保存されません。
人事部の人が行っている仕事に、組織図を作るという仕事があります。組織を管理するシステムでは、この仕事も(を)システム化します。そうです、「2005年第三クオータ時点の組織図」もオブジェクトです。データベースには、もととなる情報のみ保存されればよく、データベースに保存されたデータをもとにつくられた図などは別途考えます。
しかし、オブジェクトとして考えれば、データベースに保存されようがされなかろうが、関係ありません。
なんでもかんでも、まず同じという観点で考えることが大切だと私は思います。
同じであるということは、1度設計すれば、その他では「あれと同じです」で説明が済むということです。
プログラムも同じです。1つ書けばあとは、それを呼ぶだけでよいということになります。
次は、いよいよ何と何が同じで、何と何が違うのかの考え方第一弾について書いてみます。

クラスとは(1)

Classとは、 共通の性質を有する部類,種類のこと。型。
そんなことは、みんなわかっているし、調べればわかる。
ソフトウェアを設計するということは、どれだけ何と何が同じで、何と何が違うのかを洗い出すことである。洗い出したオブジェクトの共通点をクラスといいます。
前述のオブジェクトとは(1)で鈴木さん、佐藤さん、田中さんは、具体的に存在するものであり、それがオブジェクトだということを学びました。
そして、その際登場した抽象的な名詞である組織、管理職、部門がクラスです。
鈴木さん、佐藤さん、田中さんというオブジェクトの共通点に注目すると、その会社で働いている人で社員番号、社員名、性別、生年月日、住所、電話番号といった情報を保有するものであると気づきます。
これらの共通事項に名前をつけて、従業員と呼ぶとします。
この従業員という型(共通の性質を有する部類,種類)が、クラスです。
クラスの特徴は、抽象的な名詞であることです。
オブジェクトである鈴木さんは、具体的に人間が認識(存在)する登場人物であるのに対し、
クラスである従業員や、上述の組織、管理職、部門は、実際には存在しないが、共通点に人間が名前をつけたものであることに気づきます。
そして、オブジェクト指向では、このクラスのネーミングがとても大切です。システム全体では、たくさんのオブジェクトが登場します。また、それらの共通点であるクラスもたくさん登場します。
このとき、自分以外の人が誤解をしないように、共通点を的確に表現する一般的な名前をつけることが大切です。
だれがどうみても、組織を管理するシステムで、鈴木さん、佐藤さん、田中さんは従業員だと思うなら、それは正しくクラスを見つけられたことになります。
次は、データベースの場合で考えてみます。

クラスとは(2)

前回で大体理解していただけたと思うのですが、ER(エンティティリレーション)設計の場合だとテーブル(エンティティ)は、クラスだと思って頂くとわかりやすいです。
オブジェクトとは(2)で登場した社員テーブルがクラスで、社員テーブルにデータとして入るレコード(鈴木さんとか佐藤さん)がオブジェクトです。
社員テーブルの社員番号、社員名、性別、生年月日、住所、電話番号に具体的な値をセットするとレコードになります。
つまり、従業員というクラスに社員番号1番で、社員名鈴木一郎で性別男性で・・・・という具体的な情報が付加されることでオブジェクトになるともいえます。
どうでしょう?
何と何が同じで、何と何が違うのかの考え方第一弾を理解していただけたのではないでしょうか?

DOAとOOAの違いとして

共通点であるクラス探しから行うか、具体的なオブジェクト探しから行うかの思考の違いが一番大きな違いだと私は思っています。
話は変わるのですが、リレーション(関係)が大切です。
クラスをただ単に見つけ出すだけで満足してはいけません。オブジェクトオブジェクトの関係の共通点を見出し、クラスとクラスの関係を洗い出す。この点も常に考えておく必要があります。
組織と部門と従業員の関係。つまり、佐藤さんはシステム部に所属しており、A社という組織は、システム部を含む他の部門から構成されているという関係です。
この関係を折角考えているのだから、設計書に記述しておきたいですね。この関係を記述する方法として現在主流なUML法のクラス図で表してみましょう。
※無償のJUDE-Communityを利用(Rose が好きだけど高くて個人では買えない・・・)

リレーションとは(1)

オブジェクトオブジェクトには関係があります。
そして、その関係を大きく三つに分けることができます。

  • 具象と抽象の関係
  • 継承の関係(抽象と抽象の関係)
  • 保有の関係

の三つです。

1つ目の具象と抽象の関係は、クラスとオブジェクトの関係です。
佐藤さんは従業員です。(AというオブジェクトはBというクラスです。)
佐藤さんと従業員は、具象と抽象の関係です。
これまでで、ニュアンスをつかめているでしょう。
2つ目の継承の関係は、is-a関係とも呼ばれます。
A is a B. といえる関係です。
佐藤部長は、従業員です(管理職は従業員です。)
といえるので、管理職と従業員は継承の関係です。
3つ目の保有の関係は、has-a関係とも呼ばれます。
C has a D. といえる関係です。
A社はシステム部を保有します。(組織は部門を保有します。)
システム部は、佐藤さんを保有します。(部門は、社員を保有します。)
日本語としておかしいですが、そうともいえなくないので、
組織と部門、部門と社員は保有の関係です。
それから、従業員は、社員番号、社員名、性別、生年月日、住所、電話番号を保有します。
これらも保有の関係です。
しかし、保有の関係で保有されるクラスを、
クラスとして設計せずに属性という言い方をしていきます。
ここで、何と何が同じで、何と何が違うのかの考え方第二弾です。
つまり、社員番号、社員名、性別、生年月日、住所、電話番号といったものの場合は、
クラスにするか属性にするか検討します。
属性にできる基準は、
今から作るシステムの環境で決まります。
「社員名は文字列です」
といえるので、継承の関係です。
言語に標準で用意されている文字列クラスにマッピングできます。
ソフトウェア開発する環境(言語やライブラリ)に
既に存在するクラスと継承関を見つけ出し、
単に属性としてしまうことで、
クラスを共通化してしまうのです。
このようにして、共通化していきシステムを簡単にしていくのです。
プロセス指向データ指向オブジェクト指向
アスペクト指向、サービス指向、ビジネスプロセス指向
といったどのようなアプローチを取ったとしても、
システム差分を設計するのです。
こうすることで、何を流用して、
何を作らなければならないかを整理(設計)していきます。
ここでシステム化を考えるときに重要なのが

  • 具象と抽象の関係
  • 継承の関係(抽象と抽象の関係)

の切り分けです。
この切り分けを間違えてシステムを複雑化しかねないのです。
オブジェクト指向を学者がするのなら、
どんどん複雑になってもかまわないでしょう。
何が正しいのかを追求し、
時間を使って解決すればよいのです。
しかし、ソフトウェア開発の場では違います。
ポリモフィズム(次回触れます)を利用し、シンプルにしなければなりません。

ポリモフィズムとは(1)

polymorphismとは、多くの形態という意味で、
多態性または多相性と訳されている。
オブジェクトは、関係をもち、関係を整理すると属性をもつと学びました。
オブジェクトは、さらに仕事をもちます。
オブジェクトをすべて擬人化して考えることで、
オブジェクトがもつ仕事を見出すことができます。
この仕事をオブジェクト指向では、操作といいます。
組織を管理するシステムの範囲で
従業員が保有する操作を考えてみます。
*異動する(所属、昇任、降任)
*変更届けを出す(引越、婚姻)
*働く
*給料をもらう
があります。
オブジェクトは(1)で登場した
課長の田中さんとヒラの山本さんがそれぞれ、給料をもらうとします。
管理職である田中さんは、会社から管理職手当てがでており、
ヒラの山本さんよりも給料は高くなります。
これは、同じ給料をもらうという操作なのに、結果が違うということです。
同じ操作なのに、オブジェクトごとに振る舞いが変わることをポリモフィズムといいます。
平社員が給料をもらうのと
管理職が給料をもらうのは
違うと考えるか同じと考えるかで、
ソフトウェアの作りが変わってきます。
まず、同じと考えて、ここだけ違うと考えられることが大切です。
これをするために、視点をいつも高いところにもっていくよう心がけます。
確かに管理職は、管理職手当てがつくので一見、計算方法が違うように思いがちですが、
ヒラの管理職手当てが0円であると考えれば、
同じ計算方法ですみます。
設計やプログラムでもし何々だったらというIF文を考えるのではなく、
こう考えればすべて同じというふうに解決していくことで、
シンプルなソフトウェアを構築していきます。
継承だ、インターフェースの共通化だだけで、ポリモフィズムを設計するのではなく、
何と何が同じで、何と何が違うのかをしっかり見極めてこそポリモフィズムです。
複雑なソフトウェアは、心配性なひとが
「この業務ではこういう場合にこれが違うあれが違う」
と違いばかり気になって同じことに気が付かないことで失敗してしまいます。
そもそも、プログラムなんて、
「入力データを加工して出力データを作成するだけ」
のもの、または、そうなるようにもっていく
ものだと考えます。
まずは、すべて一緒の視点を持っていきたいと思います。

システムは芸術!?

今日は、システム芸術かどうか考えてみたいと思います。
絵とか彫刻とかプラモデルって、実物にまねて作ったものです。
コンピュータで作られるシステムも実物にまねて作ったものです。
芸術を辞書で調べると
芸術…鑑賞の対象となるものを人為的に創造する技術
とあります。
私は、システムとは現実のビジネスの対象となるものを人為的に想像するものと思います。
フランスの彫刻家ロダンは、
芸術とは、自然が人間に映ったものです。大事なことは、鏡をみがくことだ」
と言っています。
私は、システムとは自然にまたは、ルールにしたがって人間が行うことだと考えています。
大事なことは、鏡をみがくことではないでしょうか。
プラモデルは、別として、
絵や彫刻は、見た目だけでなく動きや感情をその創造物に込め、
モデル化しようとしています。
システムは、絵や彫刻とは違うけれども、ビジネスを
モデル化しようとしています。
上記から考えてある意味、システム芸術といえるのではないでしょうか。
良いシステムを作るためには、
高い視点(システムの全体像)から物事をみて
モデル化する必要があると思います。
「それはセンスを必要とされる。」
真のシステムというものは、真の知恵と同じく、
大変簡明で誰にも分かりやすいものでなければならない
と思います。

システムの全体像をシンプルな1枚の図で表現できなければ、
良いシステムではないでしょう。
この感覚を身につけたいものです。
芸術的センスがないと、良いシステム設計はできないと思います。

リレーションとは(2)

あなたが街を歩いていて
とても好みの女性(男性)を見かけたとします。
するとあなたの頭の中では
「あ、あれは初恋の彼女(彼)に似ている」
もしくは
「あ、あれは3番目の彼女(彼)に目元が似ている」
と記憶をたぐり寄せます。
この時のあなたの脳内を見てみましょう。
*好みのタイプの人を見かける(五感が刺激される)
*びびびっとくる(脳内細胞シナプスに電気信号が伝わる)
*以前の彼女(彼)を思い出す(シナプスによってニューロンが刺激される)
過去に見たり聞いたり触ったりしたことというのは
必ずニューロンという神経細胞に記憶されます。
あなたが以前好意を持った異性もしっかり記憶されています。
思い出せなくてもニューロンには必ず記憶されているのです。
しかしながらニューロン間を伝達するシナプスがないニューロンは
どこからも呼ばれないため、死んだ記憶となってしまいます。
また困ったことに、変にニューロン同士を結ぶシナプスが出来てしまっても
思考できなくなってしまいます。
つまり、恋多き人は何番目の異性と似ているのか思い出せないのです!!
・・・いや、そんな話ではなく
思考とはつまり、過去の記憶をどれだけ思い出せるかという単純なことです。
だから、脳のシワ(シナプス)が多い人ほど頭がいいと言われます。
あらためてニューロンをオブジェクト、シナプスをリレーションと考えてみます。
オブジェクト指向のブログなので。
オブジェクトオブジェクトの関係は、さまざまあります。
しかし、直接関係しているものはそんなに多くはないです。
そして、関係がないオブジェクトもありません。
オブジェクトは(1)で登場した鈴木さんと佐藤さんには
直接の関係はありませんが
「鈴木さんはシステム部を統括しており、システム部の責任者として部長の佐藤さんがいる」
というつながりで関係が発生しています。
どのオブジェクトオブジェクトが関係もっているのかを正しくみきわめる必要があります。
リレーションを間違うととんでもないシステムが出来上がってしまいます。
(新たに創造されたなにかができておもしろいかもしれませんが・・・)
今作りたいシステムとは違ったシステムが出来たり、
複雑になって難しいシステムになってしまったりします。
システム設計において、リレーションが正しいか正しくないかでプロジェクトの成否は決まります。
まとめ:歴代の彼女(彼)を間違えて声をかけると大変なことになる。ということ・・・なのか?

オブジェクトとは(4)

これまでで
オブジェクトには、3つの特性があることを
学びました。

リレーション(関係)

オブジェクトは単独で存在することはありません。
必ずほかのオブジェクトと関係を持っています。

  • 継承の関係
  • 保有の関係

のいずれかです。

属性

オブジェクトは、固有の姿・形・性質などを持っています。
これらのうち、文字列とか数値で表されるものは、新たな
オブジェクトを立てるのではなく、属性とします。

操作

オブジェクトは固有の(仕事)振る舞いを持ちます。
これを操作(operation)と呼び、動詞で表現します。

本当は、もうひとつ特性があります。

アイデンティティ(識別)

オブジェクトは、ほかのオブジェクトから自らを識別できる
アイデンティティを持っています。
鈴木さん、佐藤さんというのは、必ず、個別に識別できます。

(注)オブジェクトから、識別性を取り払うとクラスになります。
オブジェクトは(1)で登場した
鈴木さん、佐藤さんというのは、従業員というクラスです。
これらの4つの特性があるものをオブジェクトといいます。

!!!同じ仕事を2度人間がしなくてよい?
Bruce A. Tate氏が 書いている本で「軽快なJava」という本があります。
「黄金のハンマーは危険である」と・・・。
この本でかかれていることはシステム開発者(特にプログラマー)にとっては、
とても勉強になる内容でした。
(著者のJ2EE嫌いの偏見を飛ばして読めばですが・・・)
私も黄金のハンマーは危険だと思います。
黄金のハンマーとは、過去にやってきた自分の技術にこだわり、
どのプロジェクトでも適用しようとすることです。
過去の経験というのは、過去の失敗を糧に次の成功を
導き出すというのに大変良いものですが、
過去の成功にこだわると歪が生じます。
過去成功したそのとき以上に成功できるようにしたい
と思っていれば、問題ないのでしょうけど、
そこにあぐらをかくと
百害あって一利なしです。
で、私も過去にしてきたことを振り返ると、
同じ仕事を2個のプログラムにさせる設計をしてしまったと
後悔することが多々あります。
でも、言語や環境によって、同じプログラムが2個できてしまったりすることは、
しょうがないとあきらめています。
人間が同じ作業を2回しないことが大切だと・・・。
人間は、単純作業だとどうしても、ミスしがちです。
(気を抜いたり、手抜きをしちゃうんですよねぇ。)
結果そういう個所にバグが潜みます。
COBOLであろうが、
Cであろうが、
VBであろうが、
JAVAであろうが
言語や環境は関係なく、
同じ仕事を2度人間がしなくてよい
そんな仕組み作りを
私は、いままでもしてきたし
これからもしていきたいと
おもっている。
そのための考え方の1つにオブジェクト指向も勉強してきた。
皆さんは、何のためにオブジェクト指向を勉強されていますか?

カプセル化とは(1)

capsuleとは、要約、概要のこと。
そんなことは、みんなわかっているし、調べればわかる。
でも、オブジェクト指向では、
隠蔽と訳されます。
あなたが何か仕事をしようしたとき、
自分がわからないことは、人に頼むでしょう。
自分がわからなければ、知っている人に依頼する。
たとえば、自分のプロジェクトでメンバー不足が発生し
部長に要員手配を依頼します。
部長が何をしているか知らないけれど、
数日後、自分のプロジェクトにメンバーが増員された。
カプセル化とは、知ってる人を最小限にすることで、
ルールが変わったときに一人だけが知っていれば
良いようにするための考え方です。
上記の場合、要員手配のルールが変わったときに
部長だけがルールが変わったことを覚えればよいですね。
現実社会では、モチベーション等の問題があるため、
透明感をもたせメンバーにも知らせると思います。
しかし、システム化(モデル化)するときは、
本来どうであるべきかという
視点で考え最小限にルールを知らせるだけで、
仕事が進む形に設計します。
そもそも、薬をカプセル化したことから
このようにいわれています。
どんな症状のときに
どの物質とどの物質を
どんな配合で飲まないと
いけないかは、しらなくても
こんな症状の時はこのカプセルを飲めばよい
頭痛がしたら、このカプセル
下痢をしたら、このカプセル
こういうルールにしておけば、
もっとよく効く配合を見つけたとしても、
薬屋さんは、
「こんな症状の時はこのカプセルを飲んでね」
っていうだけでよいのです。
システムも同じです。
仕様変更がはいったら、
「このプログラムもこのプログラムも変更しなければいけないんです」
なんて作りは、
薬の良い配合がみつかったからって、
「全国民に配合を伝えないといけないんです」
っていってるみたいな
カプセル化とは、
どんな要望にも柔軟なシステムを作るための考え方です。

あいつに聞く

オブジェクトの洗い出しに没頭し、無我夢中になってクラスはどれかと考えることがあります。
物理的に、様々な具体例を洗い出し、オブジェクトというオブジェクトを洗い出したのはいいが、いざクラスをどれにすべきかというときになって、悩むのです。クラス設計こそが、プログラミング工数、メンテナンス工数にもっとも左右するからです。
悩んでも悩んでもいい方法が思いつかない場合に、ふと一服したときに、そうだこうすべきだとひらめく。
タバコを吸いにいったときが、一番問題解決します。
ふと一服しているとき、自分の頭の中にいる別の人が教えてくれるような感覚になります。
その自分の頭の中にいる別の人のことをあいつと私は、呼んでいました。
それで、今日改めて、あいつが何者か知ったので、ここに記しておきたいのです。
「メタ認知」というそうです。
メタ認知とは、自分を改めて客観的にみることだそうです。
(こういう風に、記号化(言語化)されていることだったんだ。)
あいつという認識だと他人にうまく表現できないノウハウでした。
しかし、メタ認知というクラスを知ったことで、WEB検索することもできるし、他人に伝えやすくもなったので、今日、このブログに書いてみました。

色って何?

みんなが赤と言っている色は、本当にみんな赤く見えているのだろうか?
信号機の一番右にあるのが赤と習ったので
私もあなたも赤と言っていいます。
見えている内容が人それぞれ個人差があるのは、確実です。
色盲のひともいるのだから・・・。
あなたが見てる青が私にとって赤かもしれない。
あなたが見ている赤が私にとって青かもしれない。
人それぞれ、その色が、この色と教えられることによって
その色を、何色って覚えます。
要は、人が共通に認識できるように、ものごとを記号化しています。
(ことばや文字も記号の一種である。)
クラスだってそうだ。オブジェクトを人間が共通に認識できるように記号化されたものですね。

DOAとOOAとPOA

DOA(データ指向)とOOA(オブジェクト指向)って
デジタルとアナログと似てるっておもうんですよね。
デジタルな人とアナログな人という言い方をたまに聞きます。
どういうときに使われるかというと
デジタルな人っていうのは、決断をてきぱきできる人
しかし、許容範囲が狭く周りを取捨するような人ってかんじかな。
効率のいい人ってかんじやね。
アナログな人は、決断をあいまいにしてしまう人
しかし、許容範囲が広く周りを受け入れる人ってかんじやな。
っておもっています。
効率は悪い人ってかんじやね。
アナログとは、大小の程度で,データを表現することです.
デジタルデータは,数値の列で表現されたデータです.
ということから考えると本来、
デジタルな人は、世の中を記号化、言語化して理解する人。
つまり、何でもオブジェクトをクラスで表現して理解する人かな。

アナログな人は、世の中をそのまま理解する人。

つまり、オブジェクトオブジェクトのまま覚えちゃう人ちゃうかな。
でっ
システム設計するときに、DOA設計するかOOA設計するかの違いをかんがえると
DOA設計は、
まず、対象業務のエンティティ(クラス)を洗い出して、
そのクラスとクラスの関係を考えていく。
考えるときに具体例として、オブジェクトを上げる。
こんな設計方法ですね。
OOA設計は、
まず、対象業務のオブジェクトを洗い出して、
そのオブジェクトの共通点を言語化し、
クラスを見つけ出す。
オブジェクトオブジェクトの関係がそのまま、
クラスとクラスの関係となる。
POA(プロセス指向)設計は、
処理だけに注目して、業務の手順(業務フロー)どおりにプログラムしていきます。
このとき、同一の処理が見つかると共通処理として洗い出していきます。
このやり方で、共通処理をきちんと洗い出すためには、
かなり賢い人でないとできないと思いますが、
すごい人は、この方法できっちり共通処理を洗い出して、
結果オブジェクト指向システムと同じ結果になっています。

どの設計手法であっても、
何と何が同じで、何と何が違うのか
同じ処理を2箇所でしなければ、
それは、メンテナンス性のよいシステムになり、
求めるシステムになるわけですが、
アナログな人は、OOA設計が
デジタルな人は、DOA設計が
天才は、POA設計が
向いているんじゃないかなぁと私は思います。

以前経験したシステムと同じであれば、以前のクラスを
再利用します。

つまり、経験範囲に応じて、
OOAからDOAへ
または、DOAからPOAへ指向をかえて
設計していけばよいと思っており、
そのように行っています。

皆さんは、システム設計するときどのように
設計されていますか?

JAVAでポリモフィズム

ポリモフィズムを実現するには、

リフレクションを使うことが必須になる。

ということで、リフレクションサンプル。

/**
* インスタンス生成
* @param strClassName
* @param args
* @return Object
*/
private Object getInstance(String strClassName, Object[] args) {
Object rc = null;
    Class[] clss = new Class[args.length];

    for(int i=0; i
        if(args[i]==null) {
           clss[i] = null;
        } else {
            clss[i] = args[i].getClass();
       }
    }

    try {
        Class cls = Class.forName(strClassName);
        java.lang.reflect.Constructor constructor = cls.getConstructor(clss);
        rc = constructor.newInstance(args);
    } catch (Exception e) {
        log.error(“getInstance error”,e);
    }
    return rc;
}

サブジェクトとは(1)

サブジェクトとは、哲学用語で オブジェクトの反対の意味。
主体,主観,自我 のことである。
初版のオックスフォード辞典では、オブジェとは「その神を邪魔するもの」という意味。サブジェクトとは、そのしもべになること。
本来は主語がサブジェクトにあるわけでも、目的がオブジェクトにあるわけでもない。むしろ隷属しているサブジェクトがあって、邪魔をする関係として「オブジェクト」があった。現在は、オブジェクトサブジェクトの位置と意味をひっくり返してしまっている。
現在の考え方でいうと
サブジェクト指向は、主体が仕事を自分でやる指向である。
反対にオブジェクト指向は、対象であるみんなに仕事をやってもらう指向となる。

プログラムとは(1)

コンピュータにさせる仕事の手順書のこと。
コンピュータでプログラムを作る作業をプログラミング(programming)と呼ぶ。
プログラミングでは、最初にコンピュータで行いたい仕事のために、プログラマがコンピュータになったつもりで、アルゴリズムを作る。
作ったアルゴリズムに従い、それを特定のプログラミング言語で記述する。
その記述された手順書がプログラムである。