「オブジェクトの設計力」 スキルアップ講座やります

私が講師をさせていただく、技術講座のご案内です。

2月23日(土)14:30−17:30
東京・品川 楽天タワー2号館
5000円

お申し込みはこちらから。
オブジェクト設計エクササイズ

この講座は、実務経験が3年程度ある技術者で、

● プログラミングはだいぶ覚えたが、設計といわれると自信がない
● ある程度、設計はできているつもりだが、不安

という方むけに「実務で役に立つ」オブジェクト設計の考え方・やり方を知ってもらおう、という講座です。

その設計は手続き指向では?


Java, C#, Rubyなどは「オブジェクト指向」のプログラミングも「できる」言語です。
いっぽう「手続き型」だけで書けちゃう言語でもあります。

業務アプリケーションの開発で、Java は相当使われている言語です。
しかし、多くのコードは手続き型の考え方と習慣で書かれているようです。

そういう手続き型があたりまえの環境で育ってしまうと「オブジェクト」を設計するという発想やスキルを身につける機会がないのが実情だと思います。

この講座は、若手の技術者のみなさんに、「オブジェクトを設計する」という発想と、実際の設計のやり方に触れてもらい、現場に持ち帰って役立ててもらおう、という主旨で開催します。

現場で生かせるオブジェクト設計力


講座の内容は、日常のプログラミングの時に、ちょっと気にするだけで、みちがえるようにオブジェクトの設計力がアップしていく魔法のような(笑)テクニックの紹介です。

設計に唯一の正解はありません。
いろいろな考え方・やり方があります。
実務で役に立つ設計力とは、いろいろな設計の考え方・やり方を、必要に応じて適切に、使い分けたり、ミックスする力です。

この講座で説明する設計力アップのテクニックは、最初は奇妙に見える以下のルールを使ったプログラミングの実践のススメです。

1.ひとつのメソッドのインデントはひとつまで
2.else 句は使わない
3.すべてのプリミティブ型と文字列型はラッピングする
4.ファーストクラスコレクションを使う
5.1行につきドットは1つまで
6.名前は省略しない
7.クラス50行以内、メソッド3行以内
8.1クラスにインスタンス変数は2つまで
9.getter/setter は使わない

手続き型の発想だと、これらのルールは不思議、あるいは悪い書き方かもしれません。
でもオブジェクトの設計力のスキルアップには、効果絶大の練習方法なんです。

講座では、

● そもそもどういう意味?
● なぜこのルールでプログラミングするとオブジェクトの設計力があがるの?
●(ルールはわかるけど)こういう時は具体的にどうすればいいの?

というあたりをサンプルコードを見ながら、具体的に説明します。

Q&Aの時間もたっぷりとります。

極端すぎるのでは?


この9つのルールは、コミュニティの勉強会でなんどかお話をさせていただきました。
スライドも公開しています。
オブジェクト指向の設計と実装の学び方のコツ

おおむね良い評価をいただけたと思っていますが、極端すぎるとか、現場では無理、非現実的、というフィードバックもそれなりの数がありました。

「これがオブジェクト指向だというなら、私はオブジェクト指向をやっていないし、やる気もない」というように(言外に)これは「にせもの」のオブジェクト指向である、という意見の方もいらっしゃいます。

オブジェクト指向に一つの明確な定義があるわけではないので、私は、それもオブジェクト指向、これもオブジェクト指向、という感じで受け止めていますが、「極端」であることは、その通りだと思います。

意識的に極端にして、ある「意図」を伝えようとしているルールだからです。

ルールの意図


このルールの背景にある考え方は、次の2点に集約できます。

◎ 名前たいせつ
◎ 小さいほうが扱いやすい

この2点は、総論としてなら、みなさん賛成いただけると思います。

でも現場で実際にプログラミングするとなると、

● 名前をいちいち考えているのはたいへん
● 小さく分割しすぎると、見通しが悪くなり、かえってわかりにくくなる

という意見が多くなってきます。

この現場感覚が、実は「手続き型」プログラミングの発想や習慣に、知らないうちに、しばられている。
この手続き型の発想や習慣とは「異なる」発想である「オブジェクト」の発想や習慣を知ることで、設計力が格段にアップしますよ。


これがこの講座の狙いなんです。

「手続き型」の発想や習慣を捨てる必要はありません。
そうではなくて「手続き型」とは別の「オブジェクト」の発想や習慣を増やしていけば、設計力が格段にアップしますよ、ということなんです。

今回の講座では、キーワードとして「オブジェクト」にフォーカスしていますが、「関数型」の発想や習慣も、設計力アップにとても役に立ちます。

また講座の中では「宣言型」とか「論理型」という言葉そのものは使いませんが、そういう考え方を隠し味として使っています。

そうやって考え方の幅を広げることが「設計力アップ」のコツなんです。

高い?


私としては5000円は破格の安値だと思っています(笑)。

でも払う側からすれば「5000円払って、休日つぶすだけの価値があるのか?」と思うのが普通の感覚ですよね。

価値がありそうかどうかは、このブログの過去記事や、公開しているスライド を参考にご判断いただければと思います。

<補足>
ブログ過去記事で「関数型プログラミングってエクセル方眼紙だよね」は、しょうもないネタ記事です。まじめに受け止めないでください。
それ以外のエントリは、まじめに書いている(つもり)。

関数型プログラミングってエクセル方眼紙だよね

業務アプリケーションの開発をしていると、エクセルで、ひとつのセルを全角一文字分の小さな正方形にした、いわゆる方眼紙スタイルで書かれたドキュメントにお世話になることがある。

エクセル方眼紙


第一のメリットは、どんな内容でも、縦や横をそろえて見た目をきれいにできること。

箇条書きをインデントして書くのも楽だし、ドキュメントの一部に小さな表とか画面イメージとか、罫線使って簡易な図形表現が手軽にできるのもメリット。
図の貼り付けの位置合わせとかも、他の部分ときっちりそろえることができて超便利。

日本語の組版の基本は「全角」「半角」に象徴される「等幅」の文字を並べること。
日本語のドキュメントを作るときエクセル方眼紙は、理に適っている。

パソコン普及前は、薄い青線の入った方眼紙に文章と図を手書きしてコピーするのが当たり前だったらしい。
エクセル方眼紙は、この電子版というわけだ。

「エクセルの本来の使い方ではない」という意見もあるようだけど、エクセル方眼紙も、ひとつの使いかたでしょう。

エクセル方眼紙は、個別の行や列を意味は持たせないところがポイント。
固定サイズのセルの集合という、均質で高度に抽象化(簡略化)したモデル。だから、どんなドキュメント作成にも使える。

加筆や変更がしたい時も、行や列に意味を持たせていないから、つまらない副作用を心配しなくて良い。

A列、B列、C列が大中小の分類で、D列が説明で、E列が重要度のマーク、...
1行目が見出し、2行目はそれを分割したサブの見出し、サブの見出しが無い列はセル連結で大きなセルとして見せる、...

とかやりだすと、

× 行や列の意味を考えながら、高さや幅を細かく設定・調整しないときれいにならない。
× 行の高さや列の幅を個別に設定してしまうと、後からドキュメントの一部に、違う高さや幅の内容を挿入するのがとてもたいへん。

行ごと列ごとに個別の意味を持たせるから、プログラミング的に言えば独自の「型」を宣言するから、こういうめんどくささが起きてしまう。

セルは全角一文字サイズの正方形。
方眼紙は、均一サイズのセルの二次元の配列。
エクセル方眼紙のメリットは、こういう徹底した抽象化・単純化により実現できているわけだ。

抽象化・単純化は、プログラミングの極意でもるある。

関数型プログラミング


関数型プログラミングは、まさにエクセル方眼紙と同じ発想で、多くのメリットを生み出す。

オブジェクト指向のプログラミングは、なんでもかんでも、独自の「型(クラス)」を宣言していくスタイル。こういうスタイルが有効なシーンもあるだろうけど、ほとんどのプログラムは、入力データを出力データにマッピングする「関数」として単純化して考えたほうが手っ取り早いことも多い。

データの意味とか入り組んだ構造とかは捨て去って、思い切って抽象化・単純化したデータの集合としてしまえば、ほとんどのプログラムは驚くほど簡単にかける。

UML でドメインモデリング、Java でデータとロジックを「意味のある」型として宣言、それぞれの独自の型の意味を適切に表現する「名前」を一生懸命考える。

このやり方では、生産性があがらないし、部品、特にロジックの再利用がすすまない。
独自の型宣言しまくった後に、何か変更しようとするとコンパイラ型の言語だとコンパイラがいろいろ文句いうし、動的な言語だと、わけのわからない副作用に悩むことになる。

プログラミングの世界に現実世界の意味や構造をマッピングしようという発想がまちがいの元。

プログラミングのコツもエクセル方眼紙ですよ。
データ(行や列)に意味づけ(独自の型宣言)しちゃいかんのです。

全角一文字を表現した「セル」という単純で美しくさえある基本ユニットと、どの基本ユニットも [x,y] だけで参照する構造の明快さ。

この明快さ、美しさが、関数型プログラミングの基本だし大きなメリットを生む。

コンピュータのプログラミングって、ようするにバイト(ビットのかたまり)を、どう操作するかという仕組み。
バイトは固定の順番で配置され「アドレス」というシンプルな方式でのみ参照可能。

情報の意味や構造を考えようとか、独自の型を宣言して意味のある名前を付けようなんてことは無意味な世界。

データは整数のリスト。文字データも整数のリスト。
だから、整数のリストを扱いやすいプログラミング言語でデータを扱うのが、もっとも自然。開発も楽。どんなデータや要求に出くわしても、整数レベルまで抽象化、単純化しておけば、同じロジックとテクニックであらゆるデータを簡単に操作できる。

関数という部品を、あちこちで手軽に使いまわすことができる。

※ あちこちで安全に使いまわすために、関数型プログラミングでは、データを破壊しない(変更しない)ことは、とても大切な原則。手続き型はデータを変更しまくるけど、関数型では破壊的代入は、ご法度。

Hadoop とか、ビックデータを並列的に効率よく処理できるのは、CPUとメモリの劇的なコスト低下と、関数型プログラミングの考え方や仕組みがうまくマッチして実践できているから。

データとはようするに整数の集合。
関数型プログラミングは、そういう数学的な感覚で扱えるレベルまで徹底的に「情報」を抽象化・単純化するところに成立する。

世の中の多くのデータ処理は、この単純化感覚で対処すれば、それで十分。
やってみて、結果が思わしくなければ、関数をちょこっと書き変えるか、別の関数を前後に追加してやれば、だいたい解決する。

ドメインの意味を深く理解するために、言葉にこだわって分析・モデリングする。
そのドメインのモデルを独自の型として設計・実装して、独自の名前づけにこだわる。

そんな手間暇かけるから、プログラム開発に時間がかかる。
しかも、結果は、独自の型だらけ。開発した本人すら意味がよくわからないコードのかたまり。変更しようとしても、どこで何がおきるか予想できない。

そんな回り道するより、データは「整数のリスト」「文字のリスト」という単純化・抽象化によって、さっさと関数型でプログラミングしたほうが、圧倒的な生産性を生み出すことができる。

エクセル方眼紙の発想ですよ。
エクセル方眼紙も、関数型プログラミングも「単純な美しさ」を追及すれば、おのずとこうなるはず。
「美しい」だけでなく、作るの簡単、直すの簡単、再利用が簡単、という現実のメリットにあふれたプログラミングのやり方が関数型プログラミングの世界。

現実世界の情報の意味をあれこれ考えたり、名前づけに苦しんだり、独自の型を宣言しまくって、何がなんだかわからないプログラムと格闘するオブジェクト指向スタイルから抜け出したかったら

余計なことは一切無視して整数重視の汎用的なデータ構造にすること

につきる。

コンピュータやデータ通信は、情報を「ビット」まで徹底的に抽象化・単純化したことで成立している世界。

プログラムだって、そっちの世界の住人。だからそういう単純な世界に振り切りにいくのが、プログラマとしてあるべき姿。

均一なセルがきれいに並んだエクセル方眼紙。うっとりするほど美しい。
整数のリスト操作のコンパクトな関数表現。とってもエレガント。
世の中、エクセル方眼紙と関数表現だけになれば、もっとすっきりするのに。
。。。


はあー、やだやだ。

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

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

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

アルゴリズム



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

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

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

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



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

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

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

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

オブジェクト指向



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

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

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

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

目覚め



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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

うーん、わからないか



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




関連の設計と実装



オーダーと明細のモデル。

明細は、最低一行ないといけない、というのがビジネスルール。(構造ルール)




Java で実装すると、 Order クラスが、 List コレクションへの参照を持つ。
明細が最低一行必須、というビジネスルールは、メソッドで実装する。




同じモデルをテーブルで実装する。
参照が逆転しちゃいますね。

Java だと、Order クラスが List を知っている。 List は、 Order クラスを知らない。

Order テーブルは、Item テーブルへの情報を持たないけど、Item テーブルは、Order Number を参照している。(外部キー参照)

参照の逆転

マーチンファウラーのPoEAA にでてくる外部キーマッピングですね。
もっとも、PoEAA では、このパターン(コレクションへの単方向の参照)は、依存マッピングを推奨している。

このテーブルモデルは、Item の主キーである object_oid の扱い方の問題。

依存マッピングでは、
・object_oid での検索はしない。( Item を単独で検索はしない )
・テーブルの主キーの object_oid は、 Java のオブジェクトでは持たない ( 一意フィールドを持たない)
という実装をする。

同じモデルを、Java で実装するのと、テーブルで実装するのでは、参照関係が逆転。この逆転構造を、マッピングする課題を検討しているのが、PoEAA 12章 O-R 構造パターン、というわけだ。

ドメインオブジェクトの粒度 : XML とのマッピング

小さなオブジェクト

このモデルを XML ドキュメントにマッピングすると、1ファイル。

<employee id="4822" >
ここにオブジェクトをツリー上に並べていく
</employee>

基本的に、システム間のデータ送信に使うので、一回の送信単位としては、こんな感じでしょう。

インタフェース用のオブジェクト

XML ドキュメントは、基本は、画面の単位と同じと思っている。

ユーザとのインタフェースが、画面。
システム間のインタフェースが、XML。

こういうインタフェースの粒度は、大きな単位にまとめるのが普通ですね。

画面やXMLに限らず、RMI やデータアクセスでも、小さなオブジェクトを、DTO ( Data Transfer Object ) という入れ物にまとめて、大きな単位で処理する。

JAR や WAR も、考え方としては同じですね。
小さなオブジェクトの集まりを移動して配置するために、扱いやすいように、大きな単位にまとめる

Java < テーブル < XML

結局、同じモデルを実装する粒度は、

Java : とても小さく分割 (7 つのクラス)
テーブル : まとめる (2つのテーブル)
XML : 1つにまとめる

という違いがでてくる。

UML のクラス図との比較で言えば、私の場合は、UML のクラスアイコン数より、Java のクラスの方が多い。

例えば、上の図だと、Money オブジェクトを、アイコンとして記述しているけど、クラス図では、普通は、ここまで書かない。給与オブジェクトの中で表現しておしまい。

String が登場するたびに、クラス図に String をクラスアイコンとして書いていたのでは、仕事になりませんからね。 作業が面倒というより、図にノイズが増えて、モデルの本質がどこかにいっちゃうから。


ドメインオブジェクトの粒度 : テーブルとのマッピング

ひとつ前の記事で書いた、ドメインモデルをテーブルに実装すると、こんな感じ。

データモデル

クラス図とJava の実装ではクラスの数は、7つだったけど、テーブルは2つにした。

オブジェクト指向設計だと、ドメインのオブジェクトは、とても小さな単位になる。String や Integer などプリミティブなオブジェクトレベルまで、ドメインの用語のオブジェクトを作るのが基本。

それぞれのオブジェクトの役割が明確になり、ロジックの置き場所の見通しが良くなるから。

この小さなオブジェクトたちを、1対1でテーブルにマッピングすると、扱いにくいのは直感的にわかる。
オブジェクトとテーブルのマッピングの考え方は?

Aggregate(集約)

Evans のドメイン駆動設計(DDD:Domain-Driven Design)の基本パターンのひとつに Aggregate(集約)の設計がある。
いくつかのオブジェクトをまとめて、ひとかたまりで考える。

DDD の説明では、Aggregate パターンを、オブジェクトのライフサイクルの文脈で説明している。

・オブジェクトを新規に生成する
・オブジェクトを保存する
・保存したオブジェクトを取り出す
・オブジェクトを消去する

こういう時に、いつも、一つのグループとして扱うべきオブジェクトのかたまりを見つけることが、ドメイン駆動設計の基本テクニック。

DDDの本では、このオブジェクトをひとかたまりに扱う感じを、ブドウの房の写真で象徴している。

どういう単位が Aggregate として、ひとかたまりとして扱うべきかの議論が、ドメインを深く知るための重要な手がかりになる。

オブジェクトのテーブルへのマッピングは、この Aggregate の設計を反映するのが基本。

大きさの制限

ただし、テーブルも、基本は役割別に小さくしておくべき。
なんども繰り返しているけど、関心事の分離は、設計の基本中の基本。

乱暴だけど、テーブルのサイズは、属性を5つくらいまでを目安にしている。

主キー、外部キー、タイムスタンプなどの監査列を除いた、値を持つ列が、5つを超えたら、テーブルの分割の可能性を考える。

もちろん、情報のかたまりの意味を優先するけど、データ列が10を超えたら、完全に、アンチパターン(肥大化したテーブル)と判断している。

テーブル設計の手がかり

実践的には、テーブルの単位は、画面上の「ブロック」を参考にしている。

例えば、画面の氏名の入力フィールドが、

・姓
・名
・セイ
・メイ

4つあると、デザイン的に、4つのフィールドを枠線で囲ったり、背景色を変えたり、「氏名」という見出しをデザインしたりして、ひとかたまりに見せる工夫をする。

このグループが テーブルの単位の第一候補。

業務上、意味があるかたまりだから、そういうデザインにする。そういう論理的なかたまりは、当然、モデリングに反映すべきだし、Aggregate の実装、テーブルの実装でも、意識すべき論理構造。

オブジェクトの粒度:小さなオブジェクトに分ける

役割が明確な小さなオブジェクトに分けるのが、基本中の基本。

小さなオブジェクト

従業員を表現するために、従業員オブジェクトをルートとして、

・個人
・氏名
・電話番号
・生年月日

・期間
・給与

という小さなオブジェクトで構成する。

個人

氏名や電話番号のサブのルートクラス。

氏名

姓、名、セイ、メイを保持
バリデーションや、"姓名(セイメイ)"などのフォーマット出力を担当

電話番号

電話番号のバリデーションとか、フォーマット出力を担当

生年月日

生年月日を保持して、年齢計算も担当

期間

開始日と終了日を保持。
ある期間とある期間が重なっているかとか、期間演算を担当

給与

マネークラスのサブクラス。
将来は、給与計算ロジックを追加する場所。

---

オブジェクト指向の分析設計の発展形である、ドメイン駆動設計のオブジェクトの構成はこんな感じなる。

Evans の Domain-Driven Design のパターンでいえば、

・従業員オブジェクトは、Entity.
・その他のオブジェクトは Value Objects.

・従業員オブジェクトが、Aggregate のルート

この Aggregate の単位で、オブジェクト群を生成するために、 Factory パターンを使う。
Aggregate の単位で、保存と取り出しをするために、Repository パターンを使う。

Java の実装イメージ

class Employee
{
 Person person ;
 DateRange range ;
 Salary salary ;
}

class Person
{
 PersonName name ;
 PhoneNumber phoneNumber ;
 BirthDate birthDate ;
}

class EmployeeFactory
{
 Employee createEmployee() { }
}

class EmployeeRepository
{
 Employee find() { }
 List search() { }
}



---

オブジェクト指向の分析設計で、Java で実装すると、まあ、このくらいの粒度が良い感じ。

かなり小さい。
  • それぞれクラスの役割は単純
  • ドメインロジックをどこに置くかも、単純明快(ロジックが関連する情報を持つクラス)
  • ドメインのロジックに追加や変更をする時、対象のオブジェクトは、すぐわかる
  • 変更の副作用の影響範囲は、特定のオブジェクトに限定される

オブジェクトの粒度 最小単位

ドメインオブジェクトは、どの程度の大きさに設計するか?

小さくする

Java の場合は、できるだけ小さくしている。 単一で明快な責務を持たせるのが原則。

では、

テーブルは?
XML は?
UML のクラス図は?

Java と同じ粒度まで、テーブルやXMLを小さくしてしまうと、扱いにくくてしょうがない。

クラス図も、ひとつひとつのクラスを箱に書き出すと、モデルとして役に立たないくらい、図が複雑になっちゃう。

大きくする(まとめる)

一つのテーブル、ひとつのXMLにたくさんのオブジェクトをぐちゃっと詰め込むのは、明らかにアンチパターン。
設計原則「関心事の分離」に違反している。

かといって、分割しすぎるのも問題。
マーチンファウラの PoEAA の「組込みオブジェクト」パターンの議論で、ここらへんが書いてあったような気がする。
後で調べてみよう。

不一致

どうやら、Java 、テーブル、XMLは、同じ粒度で扱うのは現実的ではなさそう。
不一致が発生するわけだ。
この不一致をどうやって吸収するかも重要な設計問題になる。

ここらへんの実践的なやり方を、少し検討していきたい。

calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM