タグ

OOPとdesignに関するkiyo_hikoのブックマーク (17)

  • Part4 Eiffelに学ぶ「正しいオブジェクト指向」

    ソフトウェア開発コンサルタント。(有)デザイナーズデン代表取締役。要求記述やシステムモデリング,既存システムのリエンジニアリング,リファクタリング,フレームワーク設計,テスト,構成管理,文書化,プロジェクト管理などに関するコンサルティング,教育,開発,著述,翻訳等を手がける。対象ドメインはエンタープライズ・システムから,組み込み機器まで多岐に渡る。最近の関心事は信頼性の高い仕様記述手段の普及と実践。 オブジェクト指向言語といえば,現在ではC++Javaを思い浮かべる人が多いでしょう。こうした言語で正しいオブジェクト指向プログラミングを行うには,よく考えてクラスの設計を行う必要があります。ただ,正しい設計を行う能力は一朝一夕には身に付きません。こうした訓練に適した言語はないのでしょうか。あります。それがEiffelです。Eiffelは,正しいクラス設計をプログラマに強制します。 Eiffe

    Part4 Eiffelに学ぶ「正しいオブジェクト指向」
  • C# Tips: interface を 抽象クラス (abstract class) とどう使い分けるか (プログラミング C# - 翔ソフトウェア (Sho's))

    # 久々に技術ネタを書いてみる。 # と言っても、某掲示板で使ったネタの使い回し。 C++ にはなかった新しいキーワードとして、C# では interface というものが出てくる。 interface は、Java ではおなじみのキーワードだ。 例. interface ICloneable { object Clone(); } interface では公開されているメソッドとプロパティの外見 (名前、パラメータ、戻り値) だけが宣言されていて、実装部分が定義されていない。実装部分は、その interface を実装するクラスによって定義される。 例. class Employee : ICloneable { private string name; public string Name { get { return name; } set { name = value; } } p

    kiyo_hiko
    kiyo_hiko 2012/04/17
    「実際の設計では、State/Strategyパターンを使おう→じゃinterface を使おうとはならない」 / ConcreteStrategyに状態を持たせるならAbstractStrategy書いて共通のフィールドは書いてしまうかな。それが設計としていいのかダメかは謎い
  • ステートマシン図を用いたプログラムの自動生成支援 | CiNii Research

    kiyo_hiko
    kiyo_hiko 2011/12/08
    そのうち読む
  • Strategy パターン - Wikipedia

    Strategy パターン(ストラテジー - )は、コンピュータープログラミングの領域において、アルゴリズムを実行時に選択することができるデザインパターンである。 Strategyパターンはアルゴリズムを記述するサブルーチンへの参照をデータ構造の内部に保持する。このパターンの実現には、関数ポインタや関数オブジェクト、デリゲートのほか、オーソドックスなオブジェクト指向言語におけるポリモーフィズムと委譲、あるいはリフレクションによる動的ダック・タイピングなどが利用される。 このパターンは、関数が第一級オブジェクトである言語では暗黙のうちに使用されている。例として後述のPythonコード例を参照のこと。 Strategy パターンは、アプリケーションで使用されるアルゴリズムを動的に切り替える必要がある際に有用である。Strategy パターンはアルゴリズムのセットを定義する方法を提供し、これらを

    Strategy パターン - Wikipedia
    kiyo_hiko
    kiyo_hiko 2011/11/29
    「このパターンは、関数が第一級オブジェクトである言語では暗黙のうちに使用されている。例として Python コード を参照」・・・おお、見落としてた。コンストラクターに関数オブジェクトをバンバン渡してる感じ?
  • 詳細設計 - 技術情報Wiki

    設計・デザイン一般† オブジェクト指向の複雑性を軽減する、データ指向プログラミング入門 2023.10 概念モデリングや設計原則は進化しているのか: プログラマの思索 2023.10 概念モデリングや設計原則は以前よりも変化していないように思う。 Iframeを使いこなそう。~ EC決済のセキュリティ対策に関連して ~ - GMOインターネットグループ グループ研究開発2023.10 クレカ決済にみる外部システム連携する際の堅牢な設計 - GMOインターネットグループ グループ研究開発2023.10 今さら聞けないログの基と設計指針 - Qiita 2023.9 いいねとその通知機能をDynamoDBで設計したら思ったよりムズい - エムスリーテックブログ 2023.8 『ソフトウェア設計のトレードオフと誤り』を読んで、”日付や時刻”を扱うことの難しさについて考えた - Ma

    kiyo_hiko
    kiyo_hiko 2011/11/29
    会社で見るオブジェクト設計が常々クソだと思ってたが、ここのヒントで何故ダメかが1つわかった。感謝 / 「フローチャートがダメな3つの理由」に付け足したいのは、レイヤーや、分割統治する方針を表現できないこと
  • 集約とコンポジションの実装方法:アーキテクト360

    .NETアプリケーションのアーキテクチャやフレームワーク、設計に役立つ情報を中心に紹介しています。また業務システムに役立ちそうなユーティリティやノウハウをサンプルコードつきで公開しています。言語はC#とVB.NETを扱っています。 UMLでクラス間の関係が集約とコンポジションである場合の実装例をC#とVBで紹介する。集約は白抜きのひし形を付けた関連で、コンポジションは黒塗りのひし形を付けた関連であり、どちらも関連の一種である。その違いを簡単に説明すると、集約が弱い結びつきであるのに対して、コンポジションは一心同体の強い結びつきを表す。集約は、関連する先のオブジェクトが最初からある場合もあるし、外したり、後から追加されたりするような関係である。一方、コンポジションはオブジェクトが生成されるときに、関連する先のオブジェクトも同時に生成され、破棄されるときは同時に破棄されるような関係である。 実

  • 分析手法のキホン:「分解と分類」

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

    分析手法のキホン:「分解と分類」
    kiyo_hiko
    kiyo_hiko 2011/04/18
    has-aの◇がなかなか覚えられなかった。「piano->鍵盤楽器」「piano◇-鍵盤」でかい方が◇で、その要素はより小さいので-みたいに覚えとこう・・・。
  • ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して

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

    ドラゴンボールで学ぶオブジェクト指向 改 - 達人プログラマーを目指して
  • Javaが創成期に目指したオブジェクト指向とは(1)~導入 | URIN HACK

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

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

    javablack さんが最近とりあげ、 ちょっとだけ話題再燃したの憂 こと「憂なプログラマのためのオブジェクト指向開発講座」。以前借りて読んだことがあるのですが、「酷いわ」と思ったこと以外具体的なことは何も覚えていません(^^; で、具体的になにが酷かったのかのかな?とザザッとWebを流してみたのですが、見つからない。というか「これはいいだー」という感想ばっかりで、予想以上に「酷い」というレビューがないのに改めてビックリです。 むー、これはネチっこいレビューの需要があるかな?とスケベ心をだして買ってしまいましたョ。 憂なプログラマのためのオブジェクト指向開発講座 (DDJ Selection) 作者: Tucker出版社/メーカー: 翔泳社発売日: 1998/05/31メディア: 大型購入: 10人 クリック: 508回この商品を含むブログ (78件) を見る で、改めて読み

    憂鬱本を買ってみました - みねこあ
    kiyo_hiko
    kiyo_hiko 2011/01/20
    OOPをきちんと説明できる人が周りにほとんどいない・・・自分もイマイチだけど。
  • 依存関係逆転の原則

    チェストの依存関係 私たちの身の回りにあるものは、たいてい細かいオブジェクトが大きなオブジェクトに依存しています。 たとえばチェスト。 チェストには枠と引き出しがありますね。 引き出しは、チェストの大きさによって3つくらいだったり、7つくらいだったりします。 これ、枠と引き出しの依存関係はどうなってるんでしょう? 枠が引き出しに依存してるんでしょうか? 引き出しが枠に依存してるんでしょうか? 先に枠があって、それにあわせて引き出しが作られたんでしょうかね? とすると、引き出しが枠に依存しているといえそうですね。 んー、先に引き出しがあって、それに合わせて枠を作るってのは、なんか不自然なカンジですね。 とすると、やっぱり引き出しが枠に依存してるのかな。 と、ちょっと待ってください。 この問題、そもそものスタートから間違ってます。 誰も、なんにもなしでいきなりチェストの枠を作り出したり、引き出

    依存関係逆転の原則
    kiyo_hiko
    kiyo_hiko 2010/12/07
    関連する2つのオブジェクトの間には抽象があって、抽象によって関わり合っているので、依存関係はその抽象を引っ張り出して、それにおまかせしよう、というOOPデザインの話らしい。
  • Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して

    プログラミングと設計は来切り離せないものなのではがすごい反響だったのですが、結局この記事で私が言いたかったことは、 Java EEなどの現代的な開発環境はCOBOLなどの古い言語を使った開発とは根的に設計の手法が異なる 多くの現場では未だに古い設計手法を使っているため、オブジェクト指向などの最近の開発環境のメリットが活用できず、低い生産性にとどまっている。 ということに要約できると思います。ただし、どうして、Javaではオブジェクト指向で開発しないといけないのか、どうして昔ながらの伝統的なやり方を改め、新しい設計手法を採り入れないといけないのかと疑問を持たれた方もいらっしゃるかもしれません。ここでは、開発手法と生産性の問題について、もう少し掘り下げて検討してみたいと思います。 レガシー言語の生産性 最近のCOBOLでは、オブジェクトやスタック変数すら使えますが、ここではCOBOL85の

    Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか? - 達人プログラマーを目指して
    kiyo_hiko
    kiyo_hiko 2010/12/04
    本質を理解出来ない奴にどんなに素晴らしい道具(言語やOSS)を与えても無駄。そんな上流が多いのが問題。http://gihyo.jp/lifestyle/serial/01/software_is_beautiful/0004の「大切なのは開発言語やツールではない」に通じるものを感じた。
  • IBM Developer

    IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

    IBM Developer
  • Administrative Quarantine

    Your system administrator has blocked your computer or device. Please contact the system administrator.

    kiyo_hiko
    kiyo_hiko 2010/11/29
    「インヘリタンスは、 基本クラスの『特殊な例』を作成する目的にのみ使われるべき機能である。 」
  • 業務システムでオブジェクト指向は必要か? - 達人プログラマーを目指して

    半年前に爆発的に盛り上がったネタで今更ですが、 実はオブジェクト指向ってしっくりこないんです!:気分はstatic!:エンジニアライフ について。多態性(ポリモーフィズム)やGoFのデザインパターンなどの常識を知らない筆者が、C#でpublic staticメソッドを使えば*1インスタンス化が不要などと知ったかぶりの口調で説明したところ、コメント欄やその他のブログで爆発的に議論(多くは反論)が巻き起こったという、伝説的な内容の記事です。多くの方が既にコメントしているので、ここでは筆者の無知や態度については繰り返し言及しないことにします。ユーザー企業のIS部門という業界のピラミッド構造のかなり上の方に属する立場のSEにはこの程度の見識しか持たない人もいるのか、井の中の蛙の技術者とはこのようなものなのかという事実をあらためて世に知らしめたという意味で、(炎上した多数のコメントも含めて)非常に貴

    業務システムでオブジェクト指向は必要か? - 達人プログラマーを目指して
    kiyo_hiko
    kiyo_hiko 2010/11/29
    Springは未習得なので後半はあまりわからなかったけど、前半は面白かった。余裕があればspringも今後学習してみよう。。。
  • 開放・閉鎖原則

    今回は、開放・閉鎖原則のお話です。 これも、リスコフの置換原則と同じかそれ以上に、ソフトウェア開発者の方には有名な原則ですね。 これも、開発の現場では、みんな知ってるにもかかわらずないがしろにされがちな原則です。 英語でopen・closed principleですので、OCPと略されたりもします。 ソフトウェア開発者でない方には、この原則の概念を理解していただきたいと思います。 この原則によって、あなたの生活からストレスが軽減される…かもしれません。 ソフトウェア開発者の方には、この原則の重要性を再認識していただきたいと思います。 コンテンツ計画は、細かければ細かいほど失敗しやすい例: 旅行計画オープンでクローズドオススメ計画は、細かければ細かいほど失敗しやすい 何か重要なやるべきことがあるとします。 すごく楽しみにしてた観光だとか、失敗できない仕事だとかそういうことです。 そんなとき、

    開放・閉鎖原則
    kiyo_hiko
    kiyo_hiko 2010/11/24
    これは座右の銘レベル「計画は、細かければ細かいほど失敗しやすい」
  • リスコフの置換原則(LSP) - Strategic Choice

    リスコフの置換原則(LSP:the Liskov Substitution Principle)派生型はその基型と置換可能でなければならない。どういうこと?使う側から言うと、基型を引数にとる関数に、どんな派生型のインスタンスをもらっても気にしないで使えないとダメ。実装側から言うと、派生クラスがその基クラスで使われるところにおいても、正常に動作することを保証しなければならない。なんで?使う側に意識させるということは、OCPに違反することになるから。つまり、LSPに違反すると、必然的にOCPにも違反してしまう。たとえば?ではまず、簡単な例。Shapeクラス、そしてその派生クラスCircle/Squareがある。Shapeにabstract関数を使わない。Circle/Squareにそれぞれ独自のDraw関数がある。ここでShapeを受け取ってDrawする関数を作ろうとすると、、、、 v

    kiyo_hiko
    kiyo_hiko 2010/11/24
    RectからSquareを継承すべきではない理由がこの法則・・・だったと思う。
  • 1