オブジェクト指向設計（2016年度）
コンテンツ 第1章 基本的な用語 第2章 オブジェクト指向開発 第3章 設計の問題 第4章 オブジェクト指向設計の原則 第5章 単一責任の原則 第6章 Visitor パターン 第7章 LSP、DIP、ISP 第8章 パターン技術 第9章 ユースケース 第1章 基本的な用語 クラスとオブジェクトの違い 第2章 オブジェクト指向開発 オブジェクト指向開発 オブジェクト指向分析 機能外要求 User インタフェース Student クラスとTeacher クラス Student クラスのソースコード Teacher クラスのソースコード 演習2-1 UserLocator クラスのソースコード 演習2-2 演習2-2 の解答 Teacher.java UserLocator.class 第3章 設計の問題 演習3-1 演習3-1 の解答1（返却値を利用した方法） 演習3-1 の解答2（条件分岐
Ruby のココがダメ - Qiita
タイトルは釣りです。Ruby に盲目的に惚れている迂生には Ruby の痘痕（あばた）はエクボです。 それはともかく。 メソッド名の別名がありすぎ 「あなたは map 派？ それとも collect 派？」っていう問いがまず嫌い。 いや，別名にも意義があるとは思うんだけど，記憶の負担が大きい。 自分では map しか使わなくても，他人のコード読むんだったら collect を知っていなくちゃならない。 しばらく前に reduce っていうメソッド見て，そんなのあったっけ？と思ったら inject の別名だった。 map/collect と inject/reduce の名前とその背景にある発想については，Rubyist Magazine に良い記事がある： そうかと思えば，Array#delete_if と Array#reject! みたいに，働きは基本的に同じだけど，削除が行われなかっ
関数型・オブジェクト指向なプログラミングパラダイムについて思うところ - 技術memo
動機 イメージ論でない言語パラダイムに関する話を書きたかった。*1 まともな意見をインターネット空間に1つでも多く残しておきたかった。*2 要約 オブジェクト指向プログラミングはデータに対する操作をオブジェクト*3として抽象化する。 関数型プログラミングでは関数による抽象化を基本とする。 言語設計の問題と概念の問題は、混同すべきではない。 オブジェクト指向プログラミング 題材 Consというデータ構造を考えてみます。 Consは任意のデータのペアから成り、その片方をCar、もう片方をCdrと呼びます。 それはJava風に書けば次のようになるでしょう。 public final class Cons{ private Object car; private Object cdr; public void setCar(Object x){ this.car = x; } public voi
オブジェクト指向入門読み終わった - はこべにっき ♨
ちまちま読んでたオブジェクト指向入門を読み終わった。だいたい入門と言っているが、原題は"Object-Oriented Software Construction"で入門感はないし、上下巻あわせて2000ページくらいあって読みきるのが大変だった。 原著は18年前に発売された本だが、内容のほとんどは今でも有益で、全体を通してためになる。オブジェクト指向が解決しようとしている課題や、背景にある理論や考え方について解説してくれるだけではなく、実際にソフトウェアを設計する際にどのようにクラスを見つけ、どんな場面で継承を使い、ソフトウェア全体をどのように形作っていくのかという実践的な議論も充実している。 本の序盤では、ソフトウェアの品質の様々な側面についての解説や、オブジェクト指向以前から使われていたモジュールや型の概念のがもつ諸課題について詳しく解説してくれる。それらの問題をふまえ、次に、ソフトウ
なぜ日本人はオブジェクト指向をなかなか理解できないのか？：新刊ピックアップ
JavaやJavaScript，PHPなど，現在人気のプログラミング言語のほとんどは「オブジェクト指向言語」という種類の言語です。ですがこのオブジェクト指向，日本人には理解しにくいと言われています。その原因は様々ですが，一番の悪者は，日本のIT教育ではないでしょうか。 変数は「箱」じゃない！ 皆さんは，プログラミングの授業で「変数」について，どのように教わりましたか？ おそらく，「変数とはデータを代入する“箱”のようなものです」といった説明を受けたと思います。実はこの説明，まったくの大嘘なのです。 この「変数」や「代入」という用語ですが，数学用語からそのまま転用されています。なぜなら，プログラミングでも数学でも，同じ記号を使って数式を書くからです。例えば次の数式は，「xという変数に1を代入する式」または「xという名前のついた箱に1を入れる式」だと教わります。 x = 1
Haskellでの合成可能なオブジェクトの構成とその応用
Haskellでの合成可能なオブジェクトの構成とその応用 木下郁章, 山本和彦, 2015 Haskellで状態を管理する際は、 一般的に代数データ型や型クラスが用いられるが、 データが拡張できないか、動的な性質を持たない。 そのためHaskellは、 複雑な状態を扱う問題領域には適していないと考えられてきた。 一方で、一般的なオブジェクト指向言語では、 オブジェクトを提供することでこの問題領域で成功を収めている。 本論文では、Haskellの言語仕様を変更することなしに、 オブジェクト指向言語から着想を得たオブジェクトを実現する。 本論文で提案するオブジェクトは圏を構成し、合成を用いて継承を表現できる。 また、終了する運命にあるオブジェクトやストリーミングなどに応用でき、 複雑な状態を扱うゲームの実装にも使われている。 論文をダウンロード(PDF) PPL 2015 発表スライド ここに
オブジェクト指向vs関数型プログラミングの壮絶な宗教戦争っていつしてたの……？ - Qiita
なんか荒れてますが、私も一言いいたいです！！ オブジェクト指向がそうであるように、関数型も銀の弾丸ではありません！！！ - 参照透過性はすばらしい この記事をぼやーんと眺めてました。 高精度煽り除去フィルタを通して読むと、関数型のアプローチがよい、と言う話ですね。 実際コードを書いてると、自分の書いたコードに関するバグは、体感、８割くらいが副作用に起因するものです。 副作用があると、呼び出し元が考慮すべきパターンが増えます。Mの状態を持つオブジェクトと、Nの状態を持つオブジェクトをつなぐと、MxNのパターンになるわけです。これはつなぐたびに積算されるため、爆発します。 副作用が無い場合、状態数は1なわけです。1x1は？1です！！よって、状態の組み合わせ爆発は起きません。考慮すべきは、入力値のパターンだけで十分なわけです。 他にもいろいろメリットが！！ すばらしき参照透過性！！関数世界最高で
インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか？（Rubyの場合） | mah365
Rubyといったオブジェクト指向言語を学ぶと、メソッドの定義方法としてインスタンスメソッドとクラスメソッドという2通りの定義方法があることを学ぶと思います。しかし、言語自体のガイドブックには「定義方法にインスタンスメソッドとクラスメソッドがある」と書いてあるだけで、大抵その使い分けについては書かれていません。 そういう訳で、このエントリではその使い分けについて少し考えてみたいと思います。理論的に厳密な使い分けを目指すというよりは、そもそも使い分けの検討が全くつかない！という方に向けて、その指針の一助となることを目指します。 インスタンスメソッドとクラスメソッドとはそもそものところ、Rubyといった「オブジェクト指向の考え方」を実装した言語の機能です。その機能がなぜあるのか？というそもそものところは、オブジェクト指向の考え方にさかのぼることになります。 そこで、インスタンスメソッドとクラスメ
状態、型、抽象化についていろいろ
ふみ (DJ Monad) @fumieval オブジェクト指向向きの言語は、様々な状態とそれに対する手続きを独立した「オブジェクト」に切り離すことができるが、手続きそのものはファーストクラスではない。Haskellの場合は真逆で、好きなように手続きを定義できるが、状態を制御可能にしたまま分離する仕組みがなかった。 ふみ (DJ Monad) @fumieval …というのを昨日山本さんに話した。これが従来のOOPの世界とHaskellのスタイルの間にある地溝で、ここに橋をかけない限り、状態について不自由が発生し続けるだろう
問．Cでオブジェクト指向プログラミングを行なえ - 株式会社CFlatの明後日スタイルのブログ
問．Cでオブジェクト指向プログラミングを行なえ。ただし「オブジェクト指向プログラミング」とは、次のような特徴を持つプログラミング技法であるものとする： オブジェクトの実装はオブジェクトのユーザーからは隠蔽される（カプセル化／隠蔽） 同一型のオブジェクトと同一メソッドを与えた時、実際のメソッドの動作はオブジェクトの内容により変化する（ポリモーフィズム／多態性） なお、ユーザーが既存のオブジェクトをカスタマイズして新たなオブジェクトを作成する機能は、必要ないものとする。 この問いの狙い よく、「オブジェクト指向プログラミング」と「オブジェクト指向言語」は混同されます。が、前者はプログラムを設計する上での考え方で、後者はその考え方を容易にソースコードに書けるような仕様になっている言語の事で、全く違うものを指しています。 その証拠を示すため、「非オブジェクト指向言語」たるC言語で「オブジェクト指向
「オブジェクト指向の価値ってよく分からないですよね」について - manie's blog
そういえばCORBAとかROSEとかUMLとかやってた気がします。 プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。 「オブジェクト指向の価値ってよく分からないですよね。」 誕生の歴史を知ればよい。環境によっては価値がある。 コンピュータは情報数学と電子回路から誕生した。電子回路は半導体によってハードウェアからソフトウェアとなり、機械語（そしてアセンブリ言語）が必要になった。C言語はアセンブリ言語に配列と構造体を加えたものだ。手続型言語ではデータ構造とアルゴリズムを同時に設計するが別々の保守が必要だった。保守は同時にやるべきだ。データ構造とアルゴリズムを同時に同じ場所で実装し保守出来る仕組みがクラスだ。 情報数学と電子回路 情報数学は乱暴に言えばビット演算学だ。NOTとORとANDを使ってあらゆる命題論理を電子回路で置き換え可能な式に書き下
再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
第1回 Class::Componentから始めるプラガブルモジュール | gihyo.jp
はじめに はじめまして。大沢と申します。 この連載では、筆者が実装したCPANモジュールのClass::Componentを題材にしつつ、近代的なPerlでのプラガブル(拡張可能)なソフトウェアの実装方法を紹介します。 今回は、Class::Componentの概要を説明します。 本連載で使うサンプルアプリケーション 本連載では、プラガブルなモジュールを作製するという事を考えて、Gopperというサンプルアプリケーションを元に解説を行ないます。 GopperはCodeRepos上のsvnリポジトリに置いてあるので各自checkoutしてください。 svn co -r 271 http://svn.coderepos.org/share/lang/perl/Gopper/trunk Gopper サンプルアプリケーションは連載中にも頻繁にupdateされる事が予想されますので、毎回リビジョン
関数型プログラミングとオブジェクト指向の抜き差し可能な関係について整理して考える - モナドとわたしとコモナド
Googleで適当に検索すると とズラリと出てくる。 オブジェクト指向 v.s. 関数型プログラミング 関数型とオブジェクト指向という一見相反するプログラミングパラダイムの併用について理解した プログラマが知るべき97のこと/関数型プログラミングを学ぶことの重要性 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 関数型プログラミングとオブジェクト指向の抜き差しならない関係について整理して考える とそれなりに参考になりそうな情報はあるものの、無駄に複雑化されたオブジェクト指向をストローマンにするような記事ばかり(それだけ今までのオブジェクト指向にみんなうんざりさせられているのだろう)で、そろそろきちんと自分自身「関数型プログラミングとオブジェクト指向の切り離され方」についてはっきりさせておきたい、と考え、概念整理した結論を書きます。 まず端的な結論 結論を
Strategic Choice
Problemこのクラスは大きすぎて、もうこれ以上大きくしたくありません。「単一責務の原則」を適用してクラスを分割しようと思います。分割の具体的な方法がわかりません。Strategy「クラスの抽出」を適用します。どんなとき？「単一責務の原則」を適用してクラスを分割しようと思います。責務を把握したので、分割の実装を行いますが、具体的な方法がわかりません。どうする？「クラスの抽出」リファクタリングを適用します。ほとんどのレガシーシステムにおいて、最初にできることは、「実装レベル」で単一責務の原則を適用することです。つまり、大きなクラスから「クラスの抽出」をして、抽出クラスに委譲することです。「インタフェースレベル」で単一責務の原則を導入するには、より多くの作業が必要です。クラスの呼び出し側を変更しなければならず、テストも必要になります。まず、実装レベルで単一責務の原則を導入しておくと、将来イン
第4回 オブジェクト指向の本質 | gihyo.jp
エンジニアとして良い仕事をするために必要なこと ソフトウェア業界で日米を往復しながら仕事をしていると、世界中のさまざまなエンジニアに会う。私のように「プログラミングを心底楽しんでいる」人から、「新3K」（きつい・厳しい・帰れない）を身をもって体験している人までさまざまだが、共通して言えることは、エンジニアとしての基礎がしっかりできている人とできていない人では、その生産効率に大きな開きがあり、それが結果的には、会社での労働環境や待遇に、そして結果として自分自身にとっての「仕事の充実度」に、大きな影響を与えているということである。 いつも締め切りに追われている、毎回バグで苦しんでいる、徹夜の連続で体力に限界がきているなど、「仕事がきつい」理由はいろいろとあると思うが、会社や上司の悪口を言う前に、自分自身がプロフェッショナルなエンジニアとしてこの業界で勝負をするうえで必要な最低限の基礎がで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/kenokabe/items/9c650ec8bcb1418c596d
Amazon.co.jp: インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践: Ken Pugh (著), 角谷信太郎(監訳) (翻訳), 児島修 (翻訳): 本
Amazon.co.jp: オブジェクト指向入門 第2版: 原則・コンセプト: バートランドメイヤー (著), 酒匂寛 (翻訳): 本
Amazon.co.jp： アジャイルソフトウェア開発の奥義: ロバート・C・マーチン, 瀬谷 啓介: 本
