汎用のフレームワークがあれば業務アプリ実装にオブジェクト指向は不要という考え方は適切でないと思う - 達人プログラマーを目指して
前回のエントリいまさらですが、職業Javaプログラマーなら理解しておいてほしい「継承」の意味についてのブクマのコメントで、 すごく今さら感がｗ 最近の開発はフレームワーク使うことが多いようだから知らなくても作れちゃうと思ってたけど違うのかなあ。 という感想をいただきました。実際に、SI業界で多くの方々、特に、アプリケーション開発の下流工程を担当しない層の方でこのように考えている方はほんとうに多いのではないかと思います。確かに最近ではSalesforceなどの製品もありますし、CRUD処理を行うような見栄えの良い業務アプリケーションは非常に簡単に開発できるようになっているということはあります。また、Visual BasicやMS Accessなど気軽にアプリケーションを開発できるツール類は昔からありました。そして、業界構造などの理由からやむを得ない側面があるとはいえ、SIerの提供する多くの
俺がポリモーフィズムだ！ - はてなかよっ！
Twitterで一瞬盛り上がった．俺の中のポリモーフィズムは簡単に言えば「一つの識別子が複数の型を持てる」というもの．オーバーロードもポリモーフィズムに入ると思っていたのだけど，「ﾜﾛｽｗｗｗｗメッセージに応答するオブジェクトが実行時に決まることなんだから入らないだろjkｗｗｗ」(誇張あり)とreplyを貰った．俺自身はプログラミング苦手なのでこの辺よく分かってないのだけど，実行時に決まるのはあくまで動的束縛などを利用したポリモーフィズムの一つでしかない，と思っているのだけどどうなんだろうか？ 「動的(実行時)なものがそうだ！」というのもあったけど，同じコードでもフローによって静的/動的が変わってしまうかもしれないし．とすると違う人から，それは擬似ポリモーフィズムですよ，静的ポリモーフィズムですよ，ともう皆さん本当プログラミングが好きですね，と． 言いたいことは何かというと，ここの説明を信
集約とコンポジションの実装方法:アーキテクト360
.NETアプリケーションのアーキテクチャやフレームワーク、設計に役立つ情報を中心に紹介しています。また業務システムに役立ちそうなユーティリティやノウハウをサンプルコードつきで公開しています。言語はC#とVB.NETを扱っています。 UMLでクラス間の関係が集約とコンポジションである場合の実装例をC#とVBで紹介する。集約は白抜きのひし形を付けた関連で、コンポジションは黒塗りのひし形を付けた関連であり、どちらも関連の一種である。その違いを簡単に説明すると、集約が弱い結びつきであるのに対して、コンポジションは一心同体の強い結びつきを表す。集約は、関連する先のオブジェクトが最初からある場合もあるし、外したり、後から追加されたりするような関係である。一方、コンポジションはオブジェクトが生成されるときに、関連する先のオブジェクトも同時に生成され、破棄されるときは同時に破棄されるような関係である。 実
究極のインターフェース指向設計
オブジェクト指向言語では、メソッドを定義しただけで中身を実装しない、インターフェースが登場します。 インターフェースを使うと、クラスやメソッドの再利用性が高まります。インターフェースさえ同じなら、同じコードを、いろいろなクラスに適用できるためです。 しかし、インターフェースを使うのは、コードを再利用するためだけではありません。たとえ再利用しなくても、敢えてインターフェースを作ることもあります。むしろ、再利用するか否かに関わらず、インターフェースを使うべきだ、という考えもあります。 ここでは本屋さんのシステムを例に、インターフェースの存在意義について考えてみます。 本屋さんのクラス設計 本屋さんですから、まずは「本」クラスが必要です。「本」クラスは、下記のようないろいろな属性を持ちます。 題名 著者 発行者 値段 重さ ページ数 次に、本を購入するための「会計システム」を作りましょう。 レジ
疎結合がソフトウェア開発を変える（1）
図1●オブジェクト指向の問題点を解決する オブジェクト指向技術が浸透するにつれ，その問題点が明らかになってきた。これを解決するキーワードが「疎」である。 図2●部品化のメリット システムを分割してうまく部品化できれば，さまざまなメリットが生まれる。中でも重要なものは，同じ部品を他のシステムで再利用できること，変更を加えたときに影響が及ぶ範囲を部品内に限定できること，部品を別のものに入れ替えることでシステムの変更や拡張が容易になること，である。 オブジェクト指向言語の考え方が登場してから30年余。オブジェクト指向は，ソフトウェア開発の現場にようやく定着してきた＊1。システム・インテグレーションの現場では「案件のほぼすべてが，オブジェクト指向開発」（日本ユニシス・ソリューション AD CoE コンピテンスセンタ統括部長の川口真一氏）。「システムを発注する側が，設計情報をUML（Unified
オブジェクト指向プログラム言語としてのJavaScript
このページでは、JavaScriptのオブジェクト指向言語としての側面を研究します。 JavaScriptは、HTMLの拡張という側面が注目されていますが、 プログラム言語として見た場合にも、興味深い独自の特徴がたくさんあります。 このページでは、これらJavaScriptの言語としての特性、 特にオブジェクト指向言語としてJavaScript を見た場合の特徴について詳しく研究を試みます。 JavaScriptは、ほぼ完全なオブジェクト指向言語です。プログラマによるクラス定義、プロパティ定義、メソッド定義ができます。継承は、言語の基本機能としては用意されていませんが、基本機能の組み合わせにより実現できます。 メソッドのバインディング(binding)はレイトバインディング（late binding）です。これは、JavaScriptが変数の型のない言語だからです。 JavaScriptに
DIって本当に必要? - ひがやすを技術ブログ
DIって本当に必要?たまにそう思うときがあります。DIによって開発は本当に楽になったのか。 DIのメリットでよく語られることとして、インターフェースと実装を分離し、機能の利用者側はインターフェースを通じて機能を利用することで、実装に直接依存しなくなり、後で実装を変更しても影響を受けなくなるということがあります。 実際後から、実装クラスを変更するということはめったにないので、よくあるのは、テストのために実装クラスをモックに変えることです。 でも、別にそれだけならDIContainerなんていりません。たとえば、次のようにServiceクラスに直接依存したClientがあるとします。 class Client { Service service = new Service(); void setService(Service service) { this.service = service;
分析手法のキホン：「分解と分類」
第8回「分析から設計へのモデル変換などについて」はシステム開発プロセスで「分析・設計」と隣り合わせで使われるが、本来全く異なる概念である「分析（analysis）」と「設計（design）」について考えてみました。分析は複雑で理解困難な対象を単純な構成要素に分解して本質を見極める科学（science）の範疇（はんちゅう）に入ります。一方設計は、人工物を合成する工学（engineering）の範疇です。システム開発では分析と設計の間に大きなギャップがあります。 実際、このモデル変換という作業はとても大変で、機械的にできるものではありません。例えば、大学の学部でいえば分析は、（対象が自然現象なら）「理学部」か、あるいは（対象が社会現象なら）「社会科学系の学部」に属し、設計は「工学部」に属すくらいの差があるといえるでしょうか。なお、ある時期から、理工学部という、科学と工学の橋渡しを行うような存在
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Martin Fowler's Bliki in Japanese - FrontPage