Part4 方式設計で利用できる「パターン」を知る
高品質で変化に強いシステムは，アーキテクチャの良し悪しに依存する。だがアーキテクチャの設計は，外部システムとの連携や性能・信頼性の確保など考慮すべき点が多く，困難を極める。そこで利用したいのが，先人たちが生み出した方式設計のひな型である「パターン」だ。 ここ数年で，「パターン」という言葉がよく使われるようになった。読者も耳にしたことがあるだろう。 そもそも「パターン（Pattern）」とは，ある問題の解決策をテンプレート（ひな型）として記述したものである。問題を解決する手順や方法が記されているため，パターンを利用することで，迅速かつ確実に問題を解決できる。採用したパターン名をお互いに伝え合えば，メンバー間のコミュニケーション・ギャップも少なくなる。ただし，何でもパターンになるわけではない。再利用の価値があるものだけがパターンとなる。 パターンそのものの起源は古く，1970年代に米カリフォル
プログラマが仕様を決めればいい - GoTheDistance
最近よく思います。 システム開発の上流工程においてはコードは出てこない。言葉や図解で埋めつくされて、最終的には日本語でしかない。設計書とか仕様書とか。で、この大抵上流工程ではこれらのドキュメントに対するレビューなるものがあるのですが、これが実に無益なものだと感じることが多い。こんな所でPDCAまわして何が面白いんだろうとよく思う。 ここでチェックする多くのことは、言葉の解釈に関することがほとんどです。 この言葉はプロジェクトで使われていない 書き方が統一されていない 誤字脱字が多いので直せ。 この文章ではこのように解釈される恐れがある ここではこのような話になっていたがどうなのか こんなんばっか。どこもそうだと思う。解釈の違いは、要件の違い。なんちゃって。 で、結局こういうことを繰り返していくうちに段々とドキュメントがグダグダになっていく。そして繰り返していっても前提が変わってしまえば全部
オブジェクト指向設計とRDBの狭間で - Geek Not Found
ソフトウェア開発SIerで作られる業務アプリケーションでは、オブジェクト指向設計ではなくRDBベースの設計が主流です。一方で、オープンソースのアプリケーションでは積極的にオブジェクト指向設計を取り入れているものは少なくありません。このギャップは一体何でしょうか。データベースへの依存度が高いアプリケーションは、オブジェクト指向設計を適用するのが難しいように思います。オブジェクト指向設計の前身はER設計なのでどちらも考え方は共通していますが、データアクセスの方法がまったく異なります。オブジェクトに対する操作をSQLに置き換えようとすれば、オブジェクトの性質に矛盾するのは明白です。それゆえ、データベースへの依存度が高いアプリケーションはRDBのデータアクセス方法に影響されてしまいます。今時のプログラマにはオブジェクト指向は必須、常識、みたいな言説はよく聞きます。しかし、煽りでもなんでもなく、実の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
