asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

コード進化パターン:Viewコードの変更

3年以上前から続けてる「Java におけるコード進化パターン」を更新。今回は、「Viewコードの変更」を追加してみた。

このパターンを簡単に言えば、いわゆる Model-View-Controller (MVC) のビューに関するコードを変更するということ。

今までと同じように、下の図では一般化して表してはいるけど、昨日プログラミングしているときに実際に出くわした変更(進化)のパターン。

change_view_code_before.jpg



言うのは、簡単に見える。でも、色々と疑問はある。

まず、「Viewコードの変更」ということで、View の存在を仮定してる。正確に言えば、View というクラスではなく、View という役割(ロール)を持ったクラスが存在することを仮定してる。

View の役割がどこからでてきたかといえば、既に書いたように、MVC における View を指している。

したがって、この「Viewコードの変更」は、MVC (アーキテクチャ)パターンが適用されてることを前提にした進化パターンなのかということになる。

そうすると、MVC が適用されてるかどうかを どこまで厳密に 前提とするのかが問題となる。

そのため、僕は POSA 本と PoEAA 本を見てみた。

MVC のようなアーキテクチャパターン限らず、あるアーキテクチャ・デザインパターンが適用されているのか(したのか)を判断することは、人手でも難しい。通常、パターンの記述に、あるパターンの全てのバリエーションを書くことはできない。

MVC も同様で、どこまでが MVC かを判断することは難しい、と思う。たとえば、POSA 本では、MVC の実装するとして、Publisher-Subscriber デザインパターンを用いている。しかし、僕が「Viewコードの変更」を行ったときの設計・実装では、Publisher-Subscriber は適用していない。


また、場合によっては、View と Model が分離されていないかもしれない。その場合は、もう MVC とは呼べないかもしれないけど、別の見方をすれば、あるクラスは Model と View の二つの役割を持っているともいえるかもしれない。とすると、「Viewコードの変更」パターンは、MVC 以外でも存在することになる。


一つ目の疑問をまとめると、ある進化パターンを表現する場合、どんな前提を置くかということになる。


二つ目は、「Viewコードの変更」パターンの "Viewコード" の部分。書き方としては、view メソッドとも書けたかもしれない。でも、コードとしたのは複数のメソッドを変更する場合があったかもしれないため。



スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/86-ac65ab32
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。