タグ

関連タグで絞り込む (277)

タグの絞り込みを解除

OOPに関するkiyo_hikoのブックマーク (216)

  • Webアプリケーション設計・実装のためのフレームワーク活用の技術 | SEshop.com

    フレームワーク活用の「ツボ」がわかる! 書はWebアプリケーションの設計・開発におけるフレームワークの利用について解説したものです。Webアプリケーション開発では、MVC(Model/View/Controller)や3層アーキテクチャなどを採用した開発の枠組み(フレームワーク)が用いられます。書はそのフレームワークの思想に沿ったアプリケーションの設計とプログラミングを実践的に解説するものです。フレームワークの狙いはどこにあるのか、効率的な開発と改修のためにはどう考えていくべきなのかを学ぶことができます。また、サンプルとしてS2StrutsによるJavaのアプリケーションを提供していることも書の大きな特徴です。 筆者のシステム開発者、インストラクターとしての経験を活かし、さまざまな現場で応用可能な基的技法をやさしく身に付けられます。 第1章 イントロダクション―エンジニアのスキルと

    Webアプリケーション設計・実装のためのフレームワーク活用の技術 | SEshop.com
    kiyo_hiko
    kiyo_hiko 2011/04/19
    Java Webアプリの仕事で参考書に買ったもの。フレームワークの単なる使い方に終始するのではなく、「どう考えた」結果がそのようなフレームワークになっているのか、そのような利用をするのかを解説した良書でした
  • 分析手法のキホン:「分解と分類」

    第8回「分析から設計へのモデル変換などについて」はシステム開発プロセスで「分析・設計」と隣り合わせで使われるが、来全く異なる概念である「分析(analysis)」と「設計(design)」について考えてみました。分析は複雑で理解困難な対象を単純な構成要素に分解して質を見極める科学(science)の範疇(はんちゅう)に入ります。一方設計は、人工物を合成する工学(engineering)の範疇です。システム開発では分析と設計の間に大きなギャップがあります。 実際、このモデル変換という作業はとても大変で、機械的にできるものではありません。例えば、大学の学部でいえば分析は、(対象が自然現象なら)「理学部」か、あるいは(対象が社会現象なら)「社会科学系の学部」に属し、設計は「工学部」に属すくらいの差があるといえるでしょうか。なお、ある時期から、理工学部という、科学と工学の橋渡しを行うような存在

    分析手法のキホン:「分解と分類」
    kiyo_hiko
    kiyo_hiko 2011/04/18
    has-aの◇がなかなか覚えられなかった。「piano->鍵盤楽器」「piano◇-鍵盤」でかい方が◇で、その要素はより小さいので-みたいに覚えとこう・・・。
  • - デザインパターンによる進化的設計

    このプログラムでは全体の処理の流れが決まっています. その中で,youGotMailPopup()の部分のみの動作が変更できることが望まれています. ここで利用できるパターンを考えてみます.振舞に分類されるパターンのなか で,TemplateMethod と呼ばれるパターンがあります.GoFを参照すると, TemplateMethod 目的: 1つのオペレーションにアルゴリズムのスケルトンを定義しておき,そ の中のいくつかのステップについてはサブクラスでの定義に任せることにする. TemplateMethodパターンでは,アルゴリズムの構造を変えずに,アルゴリズ ムの中のあるステップをサブクラスで再定義する. とあります.今回の例では,全体の処理の流れを規定するrun()メソッドが上 記の「スケルトン」に当たります.また,youGotMailPopup()が「いくつかの ステップ」に当ては

  • CD-ROM版インターフェース2006

    173 Jan. 2006 ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ s ¡ 174 Jan. 2006 ¡ ¡ s ¡ ¡ s ¡ ¡ s ¡ ¡ s ¡ ¡ s s s s ¡ ¡ 175 Jan. 2006 176 Jan. 2006 177 Jan. 2006 178 Jan. 2006 179 Jan. 2006 180 Jan. 2006 181 Jan. 2006 http://pw.tech-arts.co.jp/pw/index.html Column

    kiyo_hiko
    kiyo_hiko 2011/04/11
    「UML の概要と UML2.0 で拡張された部分」・・・要約すると、1.UMLが望まれた背景、2.UML2.0は、よりMDA(モデル駆動アーキテクチャー)の実現に近づけたかったらしいという話、3.各ダイアグラムの概観→まとめ。概要を掴む。
  • UML2.0で変わるモデリング作法

    UML2.0の仕様についてはこれまでさまざまなメディアで解説されてきたが、サポートするツールが存在しない状況では、それがどんなに便利なものであっても、絵に描いた(もち)に過ぎなかった。しかし、ようやくUML2.0に対応したUMLモデリングツールがいくつか登場し始めた。ツールの登場により、UML2.0で拡張された機能の意味を身をもって体験できるようになるだろう。テクノロジックアート 代表取締役社長 長瀬氏に、UML2.0の仕様拡張とそれらがモデリングに与える影響について、簡潔に語ってもらった。(アットマーク・アイティ編集局) UMLが登場して8年が経過した。その間に、システム開発の環境も大きく変化した。かつて、オブジェクト指向開発といえば、SmalltalkやJavaでの単体プログラム作成を指していたが、今日では、単体プログラムだけではなく、フレームワークを利用した大規模システム開発もオブ

    UML2.0で変わるモデリング作法
    kiyo_hiko
    kiyo_hiko 2011/04/11
    「UML2.0ではコラボレーション図からコミュニケーション図と名称を変更し、機能も大きく変わった。」
  • Amazon.co.jp: デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns series): アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章: 本

    Amazon.co.jp: デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns series): アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章: 本
    kiyo_hiko
    kiyo_hiko 2011/04/11
    Bridgeパターンの説明がすぐれてるらしい
  • オブジェクト指向のプログラムに込める「意図」 - 都元ダイスケ IT-PRESS

    その昔、プログラムを覚えたての頃、プログラムってのは単に「処理」を記述するものだと考えていた。処理を1ステップごとに記述し、場合によってはサブルーチンに切り出し、再利用する。 今振り返ると、オブジェクト指向を覚え始めてしばらくして、その意識は変わっていた。当然「処理」を落とし込まなければプログラムは動かない。だから「処理」はプログラムに込める。ただ、オブジェクト指向言語を使うと、これに加えて「意図」を落とし込むことができる。 オブジェクト指向を学び始めた当初、Javaのインターフェイスの存在意義がわからなかった。プログラムは「処理」を記述するものだという視点で見ると、インターフェイスには「処理」を書くことができない。インターフェイスだけでは何も起こらないからだった。 さらに、IDEを使ってコードを追っていると、途中でインターフェイスのソースを開くことになり、「なんだよ、中で何やってっかわか

    オブジェクト指向のプログラムに込める「意図」 - 都元ダイスケ IT-PRESS
    kiyo_hiko
    kiyo_hiko 2011/04/11
    Javadocで意図を残す…「「意図の落とし込み」が有効に作用するためには「ドキュメンテーションコメント(Javadoc)がきっちり書かれている」場合に限る。このインターフェイスの「責務」を明示する必要がある。」
  • JavaやC++(オブジェクト思考)のソースから、設計を理解するために、 必要なポイントを教えてください。…

    JavaC++(オブジェクト思考)のソースから、設計を理解するために、 必要なポイントを教えてください。フレームワークの解析に必要な観点とか を教えてください。

    kiyo_hiko
    kiyo_hiko 2011/04/06
    自分のプロジェクトも設計文書もAPI仕様書(javadoc)もないのだが、試しにdoxygenを使ってみよう→doxygenはコメントが書かれてないと実力が発揮できない・・・ツールとしては期待度高し
  • UMLモデリングツール 調査メモ - KABOSU

    UMLモデリングツール 調査メモ UMLモデリングツールの調査メモです。オブジェクト指向設計やデザインパターンを勉強してみたので、せっかくなので試しにちょっとしたWebサービスでも設計してみようかなと思ってUMLモデリング始めました。そこで、どのUMLツールがいいか調査したメモを残しておきます。 JUDE http://jude.change-vision.com/jude-web/ ・ジュード ・私がいま使っているツール ・スタンドアロン ・日製で使いやすさに定評 ・有償版と無償版(Community)がある ・無償版は簡単なユーザー登録が必要 ・無償版でも8種類の図が作成可能 ・無償版にER図はない(DBモデリングは別途ツールが必要) ・ソースコードの生成・読込には対応しているが、同期はできない模様。 Eclipse UML http://www.omondo.

    kiyo_hiko
    kiyo_hiko 2011/04/04
    UML2Java、Java2UMLなツールの比較まとめ記事。参考になる。
  • オブジェクト指向設計の原則 - それはBooks

    アジャイルソフトウェア開発の奥義」を読んで第二弾。オブジェクト指向設計の原則に関するメモです。自分で読んで思い出せるくらいの内容しかメモってないと思われるので、もっと詳しい解説が欲しければ書を買ってください。 書には、クラス設計の原則として5つの原則が載っています。 単一責任の原則 (The Single Responsibility Principle: SRP) オープン・クローズドの原則 (The Open-ClosedPrinciple: OCP) Liskovの置換原則 (The Liskov Substitution Principle: LSP) 依存関係逆転の原則 (The Dependency Inversion Principle: DIP) インターフェース分離の原則 (The Interface Segregation Principle: ISP) パッケー

    オブジェクト指向設計の原則 - それはBooks
    kiyo_hiko
    kiyo_hiko 2011/03/23
    原則について、クラス図+GoFとの対応など
  • Proxy パターン - Wikipedia

    UMLで表した Proxy パターン Proxy パターンは、プログラミングにおけるデザインパターンの一種。Proxy(プロキシ、代理人)とは、大まかに言えば、別物のインタフェースとして機能するクラスである。その「別物」は何でもよく、ネットワーク接続だったり、メモリ上の大きなオブジェクトだったり、複製がコスト高あるいは不可能な何らかのリソースなどである。 Proxy パターンのよく知られている例として、参照カウント付きポインタオブジェクトがある。 複雑なオブジェクトの複数のコピーが必須となる状況では、Proxy パターンに Flyweight パターンを加えることでメモリ使用量を抑えることができる。通常、複雑なオブジェクトのインスタンスは1つだけ生成し、プロキシオブジェクトを複数生成する。それらプロキシオブジェクトは唯一の複雑なオブジェクトへの参照を含む。プロキシへの操作は、オリジナルのオ

    Proxy パターン - Wikipedia
  • オブジェクト指向の概念の発明者は誰ですか? - Smalltalkのtは小文字です

    忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。(ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない) アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現(オブジェクトにメッセージ送信)するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ(前後して抽象データ型を発案したリスコフ人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている)による、ユーザー定義型(抽象データ型)を SIMULA67 にあった「クラス」という言語機能を使って実現(カプセル化、継承、多態性)するアイデアに基づく「抽

    オブジェクト指向の概念の発明者は誰ですか? - Smalltalkのtは小文字です
  • ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して

    ドラゴンボールといえば、大変に人気の高い国民的、いや世界的な漫画、アニメですが、昨日匿名ダイアリーでドラゴンボールをネタにしたオブジェクト指向の解説がホッテントリに入っていました。 ドラゴンボールで学ぶオブジェクト指向 多くの人に親しみやすい題材でオブジェクト指向の考え方を解説するというのは非常に興味深い試みなのですが、オブジェクト指向の説明としては不適切なところがあり、ちょっと残念な内容になっています。私自身ドラゴンボールの専門家(ドメインエキスパート)ではないため、不正確なところがあるかもしれませんが、ストーリーを思い出しながら、私なりにドラゴンボールをネタとしたオブジェクト指向の解説にリトライしてみたいと思います。 なお、オブジェクト指向でもプログラミング言語によって表現できる内容が異なるため、当然設計技法は違ってきます。ここではJavaC++、C#、Visual Basicといっ

    ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して
  • オブジェクト指向再入門/皆様からのご意見(1)

    kiyo_hiko
    kiyo_hiko 2011/03/04
    Javaやってたころ、継承フィールドにsuperを好んでつけるという規約があって、それにムカついて「継承はOOPの本質じゃない!」と思って検索したらたどり着いた。とりあえずsmalltalkはいつか通るべき道だ。JavaやC++ではない
  • 業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して

    Java: The Good Partsののタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は当にGood Partなのか? - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす

    業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して
    kiyo_hiko
    kiyo_hiko 2011/03/02
    Javaは強固な言語設計をバックに現在の地位を得た印象があるけど、強固に具象化されたものは互換性の維持と相入れにくいんだと思う。古い皮袋的印象がある。Groovyの記事読むと、新しい皮袋としては中々よさそう。
  • COBOLコンソーシアム - COBOLのファイル仕様は、オブジェクト指向?

    飯島 裕一(NEC 第二システムソフトウェア事業部) 前回は、COBOLのファイルは大量データ処理向けに最適というお話しをしました。 今回もCOBOLのファイルについてお話しをしたいと思います。 つねづね思っているのですが、「COBOLのファイル」機能は、オブジェクト指向的な考え方で、言語仕様の中に組み込まれたのではないか、ということです。 どういうことか、もう少し説明をします。 オブジェクト指向は、ひとことで言うと、ソフトウェア対象領域の中から、データと、そのデータに関連する手続きとを抽出し、それらをひとくくりにして「オブジェクト」として捉える考え方です。 COBOLの言語仕様が作られた40数年前、その当時は、当然ながらオブジェクト指向というパラダイムも知られていなかった時代ですが、事務処理には欠かせないファイルおよび、そのファイルに関する手続き(入出力操作)を「オブジェクト」として捉え

    kiyo_hiko
    kiyo_hiko 2011/02/27
    先日本屋でCOBOL入門書をチラ読みしてきたけど、実はそんなに悪い言語じゃない気がする(サンプルコードの変数名がローマ字で萎えたけど)。2002年からは言語そのものにオブジェクト指向が入ってるし。
  • 多重ディスパッチ - Wikipedia

    多重ディスパッチ(英: Multiple dispatch)は、多重定義された関数やメソッド(マルチメソッド(英: Multimethods)などと呼ばれる)などについて、そこで呼び出されるべき1つの定義を動的に選んで実行する(動的ディスパッチする)際に、2個以上の複数の引数が関与してどれかひとつを選ぶこと(特殊化)がおこなわれるものである。 多重定義を許すプログラミング言語では、同一の名前の(すなわち、多重定義された)関数やメソッドのうちのどれを呼出す(ディスパッチする)かを決定する、ということをしなければならない。 多くのオブジェクト指向プログラミング言語は単一ディスパッチである。すなわち、メソッド呼び出し(Smalltalkなら「メッセージ送信」、C++なら「メンバ関数呼び出し」)において、引数の1つが特別に扱われ、呼び出すべきメソッドの特定に使われる。構文上もその引数を特別に扱い、

    kiyo_hiko
    kiyo_hiko 2011/02/25
    多重ディスパッチとか、マルチメソッドとか言われるもの。
  • Common Lispのイコール(eq eql equal equalp) - ありの日記

    どの言語にも2つの値(オブジェクト)が等しいかどうかという判断が必ずあると思う。例えばxとyの値が等しいかどうかっていう処理はよくでてくるはずである。当然Common Lispにもその判断を行うための方法が用意されていて、Common Lisptでは「EQ、EQL、EQUAL、EQUALP」という関数で定義されている。 名前で区別つかないので、絶対忘れる系。なので、メモっておく。また、Common LispではNILが偽で、それ以外のものはすべて真となる。ただ、空のリスと'()もNILと同等のようだ。 EQ(オブジェクト同一性) CL-USER> (eq 10 10) T ただし、この式が真になるか偽になるかはLispの処理系によるらしい。うーん。とりあえずこいつはあんまり使うこと無いのかな。 EQL 比較するオブジェクトのクラスと値までみて同じかどうか判断する CL-USER> (eql

    Common Lispのイコール(eq eql equal equalp) - ありの日記
    kiyo_hiko
    kiyo_hiko 2011/02/25
    コメント欄がディープで楽しすぎる。
  • Javaが創成期に目指したオブジェクト指向とは(1)~導入 | URIN HACK

    Javaは創成期に何を目指し何を解決したかったのか ― を考えることで、オブジェクト指向(プログラミング)に対する理解を深めることができます。 連載は、非オブジェクト指向言語が持つ問題をJavaがどのように解決したかを知ることで、オブジェクト指向の質を理解することを目的としています。非オブジェクト指向の代表格としてC言語を主として扱いますが後半ではC++の問題にも触れます。 (JavaC++のように静的な(固い)オブジェクト指向プログラミング言語の問題を、Rubyなどの動的な(柔らかい)言語が、どのように解決したのかについて、別の連載テーマとして取り上げる予定です。) 「オブジェクト指向」という言葉(の少し歴史的な話) Java以前のオブジェクト指向はソフトウェア開発に直結する技術でしたが、Javaによって爆発的に「オブジェクト指向」という言葉が広まって以来、徐々に設計や要求定義と

    kiyo_hiko
    kiyo_hiko 2011/02/19
    構造化とOOは相反しない、延長線上・・・分かる気がする。自分はCからPerlに進んだ者だけど、Perlで構造化しまくったら、いつの間にか全部クロージャーになってた(クロージャーはオブジェクトと非常によく似ている)
  • Practical Scheme

    ->English 10/5/2001 初出 5/30/2002 追記 6/10/2002 英語版へのリンク追加 「プログラミング言語は満載した機能を特色の第一とするものではない。 あとになって機能の追加が必要と判明するような弱点と制限を取り除いて設計すべきである。」 (アルゴリズム言語Schemeに関する第五改訂報告書、犬飼 大訳 [1])。 言語の機能とライブラリ ポピュラーな言語に親しんできたプログラマの多くは、 Schemeに触れた時、こう感じるんじゃないか。 「一体こんなに機能の少ない言語で、どんなプログラムが書けるっていうんだ。」 Schemeの規格書はほんの50ページしか無い。 Schemeプログラマはそれを言語の簡潔さの証とかなんとか言ってるけど、 入出力は最低限のものしかないし、作ったファイルを消すことさえ出来ない。 文字列処理もC言語の標準ライブラリ以下じゃないか。 ス

    Practical Scheme
    kiyo_hiko
    kiyo_hiko 2011/02/17
    Schemeはオブジェクトシステムないのか。その気になればすぐ実装できてしまうんだろうけど。