<< エンタープライズアプリケーションの例 | main | ドメイン駆動設計(DDD)のココロ >>

手続き的な発想、オブジェクト指向的な発想

ずいぶん長い間、業務アプリの開発をやってきた。

最近、ようやく手続き的な発想から、オブジェクト指向的な発想に自分の頭がシフトした気がする。

アルゴリズム



プログラミングに目覚めたころ、プログラムとは「データ構造とアルゴリズム」である、に没頭。

ネットワーク(ノードとエッジ)構造を扱うプログラムを、C 言語でうまくかけて実践できたときは、「オレすげー」と思ったのを思い出します。

そのために、ループ構造、関数呼び出し、再起呼び出しなどを駆使して、メモリ上のデータ操作の手続き記述に、どっぶりはまっていた。

データフロー、業務フロー、画面遷移、エンティティのライフサイクル



業務アプリがメインの仕事になってからは、データフロー、業務のフロー、画面遷移、エンティティのライフサイクルなんてことばっかりやっていた。

業務系のアプリケーションは、基本的に、情報分析して、それをデータベースに実装したら、あとは、

  • 情報の流れる順番
  • 業務の流れる順番
  • 画面の遷移する順番
  • エンティティの CRUD の順番
...

処理を順々に記述していく、という「業務の手続き」を考えることに、どっぷり。

オブジェクト指向



ここ10年くらい、Java 中心で、UML とかもつかって、「オブジェクト指向系」の技術は使ってきた。
でも、いまにして思うと、やっていることは、アルゴリズムであり、業務手順のコード化(トランザクションスクリプト)。

まあ、StringTokenizer を見つけて、「すげー、自分でループ書かずに、文字列が分割できる」とか、Collection フレームワークで、「おお、for 文なんて使わなくても配列(集合)操作できるじゃん」というあたりで、オブジェクト指向的な発想に目覚め始めてはいた。

「オブジェクト指向ごっこ」はやらなかった。
実装で、継承なんて使うべきではないし、ポリモフォーイズムもだめだと思っている。
GoF のデザインパターンも、業務レベルの設計パターンとしては、ろくでもない。

わかりにくい、変更しにくい、副作用が恐い、...

目覚め



最近、業務のモデリングをしていて、突然「オブジェクト指向の発想」に目覚めてしまいました。
(オブジェクト指向プログラミングではないです。ねんのため)

手続き型の発想は、アルゴリズムにしても、データフロー、業務フロー、画面遷移にしても、一定の手順で、順々にステップをこなせば問題が解決する、という考え方。

だから、分析とは、正しい手順を発見すること・理解すること、を目指す。

分析していけば、かならず、「正しい手順」「いつでも有効な手順」がある、という価値観。

でも、オブジェクト指向の発想はまったく別。
もともとは、「熱力学の分子の動き」の研究用に作られた言語が、オブジェクト指向の原点の一つらしい。

この分野は、単純明快な動作のアルゴリズムがあるわけではない。
水蒸気になった、水の分子がどういう動きをするか、アルゴリズムや、業務手順があるわけないですよね?

でも、なんらかの論理的な動きはするはず、それをどうやって、研究するか?

そこででてきた発想が、「分子」というオブジェクトに、振舞を与えて、いろいろまわりから刺激を与えた時に、どんな挙動をするか、(ソフトウェア上の架空の世界で)実験してみよう、という発想。

全体のロジックはわからないが、「分子」という存在と、「熱エネルギー」という刺激はわかっているので、それを、実際の動作させながら、挙動を調べようと。

この知識と、仕事でやっている、業務アプリのモデリングが、ある日突然結びついた。

手順や構造やよくわからん。まず、何が存在するかの分析中心でいこう。



どうやって処理すべき情報かは、まだ、明確じゃないけど、こういう情報を扱う、という「情報」というのが、いってみれば、分子。 あるいは、情報そのものより、ヒトやモノとしてモデル化する。

業務手順とか、ビジネスルールとかはあるけど、実は、「熱力学」の世界といっしょ。 今の振舞が、いつでも再現する振舞ではない。
ヒトの振舞・判断は、いちおうビジネスの決め事があるけど、例外も多いし、そもそも、しょっちゅうかわる。
業務手順やビジネスルールは、実験的なルールの一つで、これから、いろいろ変えながら、全体としての振舞を解明していくという、熱力学のシミュレーションモデルが、業務アプリの世界でも有効な発想なんだ!

まずは、どんなオブジェクトが存在するかを分析する。
オブジェクトの振舞のルール、オブジェクト間の関係は、固定で強固なものではなく、いろいろ変動するもの。

こういうものの見方で、業務を捉えていくのが、オブジェクト指向的な発想なんだ。

うーん、わからないか



ちょっと読み直したけど、他のヒトには意味不明なんだろうなあ。
読み手を考えるべきなんだろうけど、とりあえず、自分の目覚めの記録、ということで、このままにします。




コメント
コメントする









この記事のトラックバックURL
トラックバック
「オブジェクト指向発想」の目覚め
増田さんの「手続き的な発想、オブジェクト指向的な発想」を読みました。 オフィスでも、勉強会でこのことについて話しました。 話をして思い出したのは、昔金融コンサルと組んで、...
  • system-enablers日記
  • 2009/11/07 1:30 AM
calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< August 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM