タグ

Object-orientedとinterface-orientedに関するoanusのブックマーク (6)

  • オブジェクト指向システム分析設計入門

    はじめに このはオブジェクト指向技術を利用してソフトウェア開発することを目指す技術者および管理者のために書かれたです。プログラムのコードや難しい数式などを排除してあり,図と文章によって基概念や適用技術を平易に解説しています。オブジェクト指向技術数学(形式)ぬきで探求する試みといえるでしょう。 来,オブジェクト指向技術を,瓶から瓶へ水をもらさぬように,正確に伝えるには,数学(型理論)を必要とします。数学的形式化が行われていないと,オブジェクト指向で表面化する問題の議論がかみ合わず空転することが多いからです。あの時はこうだっだ,この時にはああだったと経験則の披露になりかねないのです。やはり何かしらの形式化は必要でしょう。しかし,数学的形式化の苦しみときたら並大抵ではありません。特に,後述するインヘリタンス(継承) や並列などが絡んだあかつきには残酷なのです。私だけかもしれません

    oanus
    oanus 2009/07/14
    理解するとはどういうことか,オブジェクト指向とはどのような理解の仕方なのか,という話など / 「鳴け」「ワン」「ニャー」的解説が理解できない人とそうでない人に超オススメ
  • ソフトウェア設計私論

    7. 保守しやすい設計が良い設計だ 保守容易性 EoM: Ease of Maintenance テスト容易性 EoT: Ease of Testing 変更容易性 EoC: Ease of Changing EoM = EoT + EoC 「ずっと設計し続ける」から保守が重要! リファクタリングしやすい設計を保つべし × 再利用性 参考: An Agile Way > 「保守しやすい」ことが、良い設計 (EoM = Ease of Maintenance) : ITmedia オルタナティブ・ブログ : http://blogs.itmedia.co.jp/hiranabe/2005/08/eom__ease_of_ma_8db3.html

    ソフトウェア設計私論
    oanus
    oanus 2009/02/16
    見えているのは interface だけ.
  • プロトコルとインターフェースの比較 - usagidropの日記

    プロトコルとインターフェースの比較 http://d.hatena.ne.jp/carver/20071202#p1 やっぱり両方を使っている人の意見は参考になる。 ただ、ここで指摘されている「interfaceとprotocolの違い」は、正確には「JavaとObjective-Cの違い」ではないだろうか。また指摘されている違いは、「interfaceとprotocolの質的な違い」と言えるだろうか。 以下、詳細。 定義できる要素 ・インターフェース 定数、メソッド、ネストしたクラスとインターフェース ・プロトコル メソッド インターフェースはクラス-2(インスタンスを生成できない、メソッドを実装できない)の機能を持つ。インターフェースと強く関連するクラスやインターフェースを、ネストすることで定義できる。 一方プロトコルはメソッドしか定義できない。Javaと異なり、ObjCのクラスとプ

    プロトコルとインターフェースの比較 - usagidropの日記
  • 今風の型理論入門(本編) - 檜山正幸のキマイラ飼育記 (はてなBlog)

    前ふりは「型→代数→…それから:型理論入門(の前半)」にあります。これは編(後半)。1回読み切り(長いけど)で、比較的新しい*1型理論を紹介します。「入門(門に入る)」というよりは門の外から中を覗いてみる程度。 説明用コードはJavaの構文を使います。ただし、パッケージ宣言は書かないし、publicはなるべく省略。 内容: インターフェースなんて、所詮こんなもの 心理的効果とか、人間-人間コミュニケーションとかは、別問題 わけわからんインターフェースに制約を付加する もっと制約を足してみる 謎のインターフェースに意図されたもの で、それが型理論にどうつながるの? インターフェースなんて、所詮こんなもの まず、次のインターフェースを見てください。 interface AB { int a(); void b(); } これスゴイでしょ。何がスゴイって、これを見てもなんのことやらサッパリわか

    今風の型理論入門(本編) - 檜山正幸のキマイラ飼育記 (はてなBlog)
  • 抽象化と具体化と比喩(の断片)

    「わかりやすいように、抽象的に話してください」 野崎昭弘「数学的センス」 例えばデータを考える。 データを抽象化する事によって、 データの具体的な実装の詳細を意識しなくて良くなる、と言われる。 抽象データ型では、データの内部構造の定義だけでなく、 そのデータに対する操作も同時に定義される。 このデータを使用する場合、 内部構造を直接に参照・変更するのではなく、 同時に定義された操作を介して行なう。 これにより、データの具体的な実装を意識するのではなく、 「そのデータに対してどのような操作が行なえるのか」という、 より抽象化されたレベルでプログラムを見る事ができる。 また、データの内部構造とその使用が分離されているので、 使用する側への影響無しにデータの内部構造を変更できる (変更を局所化できる)といった利点もある (例えば、配列で実装されたスタックを、リストによる実装に変えるとか)。 似

    oanus
    oanus 2008/07/23
    http://bit.ly/cbwZgq わかりやすいように、抽象的に話してください / 抽象的な場所には設置できません (略) 具体的な場所に設置して下さい / 私が作り上げるもの、それは、新しい比喩だ
  • 青木淳「オブジェクト指向システム分析設計入門」

    はじめに このはオブジェクト指向技術を利用してソフトウェア開発することを目指す技術者および管理者のために書かれたです。プログラムのコードや難しい数式などを排除してあり,図と文章によって基概念や適用技術を平易に解説しています。オブジェクト指向技術数学(形式)ぬきで探求する試みといえるでしょう。 来,オブジェクト指向技術を,瓶から瓶へ水をもらさぬように,正確に伝えるには,数学(型理論)を必要とします。数学的形式化が行われていないと,オブジェクト指向で表面化する問題の議論がかみ合わず空転することが多いからです。あの時はこうだっだ,この時にはああだったと経験則の披露になりかねないのです。やはり何かしらの形式化は必要でしょう。しかし,数学的形式化の苦しみときたら並大抵ではありません。特に,後述するインヘリタンス(継承) や並列などが絡んだあかつきには残酷なのです。私だけかもしれません

  • 1