俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
ちなみに、最初に結論だけ言っておくと、まずSandi Metzの「オブジェクト指向設計実践ガイド」を読め、という話です それだけで終わってしまいたい気持ちはあるが、不親切過ぎるしもうちょっとRails向けの話を書こうと思う。 ただ言いたいことは、よく分かってないのに使うのは止めろということ。 自分も本で書いたりした手前、それが参考にされた結果なのかもしれないが、世の中には本当に酷いクラスが存在するもので、雑にサンプルで書くと以下の様な感じのコードが存在したりする。 class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.activ
そのオブジェクト指向入門は間違っている（大げさ） - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日！ - uzullaがブログ
はい、Webアプリエンジニア養成読本 AdventCalendar2014です。突然トリをやる事になってしまったので、どうしたもんかとおもいます…。 「最終日だぞ…ちゃんとかかないといけない…しかしネタはない…そうだリンク集を作ろう！」とか思ったんですが、そもそもアドベントカレンダーってリンク集だよねって気付いて愕然としているクリスマスの夜です。現在朝の4時、これを書き終えて寝たい。 さて…何を話そう ここまでWebアプリエンジニア養成読本アドベントカレンダーということで続けてきました。そして今日は25日、ついに最終日です！ Webアプリエンジニア養成読本 Advent Calendar 2014 - Qiita Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus) 作者:和田 裕介,石田 絢一 (uz
「オブジェクト指向の価値ってよく分からないですよね」について - manie's blog
そういえばCORBAとかROSEとかUMLとかやってた気がします。 プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。 「オブジェクト指向の価値ってよく分からないですよね。」 誕生の歴史を知ればよい。環境によっては価値がある。 コンピュータは情報数学と電子回路から誕生した。電子回路は半導体によってハードウェアからソフトウェアとなり、機械語（そしてアセンブリ言語）が必要になった。C言語はアセンブリ言語に配列と構造体を加えたものだ。手続型言語ではデータ構造とアルゴリズムを同時に設計するが別々の保守が必要だった。保守は同時にやるべきだ。データ構造とアルゴリズムを同時に同じ場所で実装し保守出来る仕組みがクラスだ。 情報数学と電子回路 情報数学は乱暴に言えばビット演算学だ。NOTとORとANDを使ってあらゆる命題論理を電子回路で置き換え可能な式に書き下
再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
オブジェクト指向とは結局メンタルモデルのモデリング手法である - assertInstanceOf('Engineer', $a_suenami)
きしださんのエントリが話題です。 オブジェクト指向は禁止するべき - きしだのはてな 「禁止するべき」とはまた随分と煽りタイトルですねと思いつつも、内容自体はとても納得のいくものでした。 ただ「オブジェクト指向」というのはいろいろな観点で語られることが多く、多少モヤモヤとはしているので僕の考えを書いてみようと思います。 なお、きしださんご自身は以下の補足エントリで立場は明確にされています。本エントリはこれを否定するものではありません。あくまで違った立場からの意見です。*1 オブジェクト指向について - きしだのはてな 参考までに、ぼくの基本的な定義は、ランボーの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」という定義に従っています。そのようなオブジェクトが単体ではなく組織化されるということが重要です。オブジェクト指向を勉強するとはそのような組織
オブジェクト指向は禁止すべき!?なのか つれづれ/shi3z:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活
麻布十番でひさしぶりに「もや鍋」を食べながらボケーっとしていたら、「オブジェクト指向は禁止するべき」という記事がタイムラインにながれてきていて、「なぬ!?」と思ったのだけど、まともな記事だった。 オブジェクト指向がなぜ優れているのか、というかなぜ世の中はオブジェクト指向を必要としたのか、という点について無視すると、たしかに初心者にオブジェクトの概念教えるのは難しいんだよね。 僕は基本的にゲームプログラミングから入っているから、オブジェクト指向というのはびっくりするくらい重要というか、当たり前のものの一つになっている。 ゲームだとオブジェクトというのが画面に現れる。 例えば弾とか敵とかね、あれがひとつひとつオブジェクトだよ、と言われれば納得する。 その昔、ナムコの業務用基盤(ギャラクシアンとか)ではスプライトのことをオブジェクトと呼んでいたくらいだからゲーム=オブジェクト指向は揺るぎないと思
オブジェクト指向は禁止するべき - きしだのHatena
プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムの本に、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ
オブジェクト指向設計原則 - Strategic Choice
原則について優れたオブジェクト指向開発のための指針。ただ、、、原則は原則。必ず守らなければならないのではなく、まずそれで考えることが重要。逸脱したとしても正当な理由やトレードオフが説明できればよい。一覧単一責任の原則（SRP）オープン・クローズドの原則（OCP）リスコフの置換原則（LSP）依存関係逆転の原則（DIP）インターフェイス分離の原則（ISP）参考アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技作者: ロバート・C・マーチン, 瀬谷啓介出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/07/01メディア: 大型本 Principles Of Object Oriented Designオブジェクト指向設計＠Syboos.jpオブジェクト指向設計の原則＠それはBooksオブジェクト指向設計原則＠ディノオープンラボラトリオブジェクト指向の法則
オブジェクト指向設計とは - @ledsun blog
オブジェクト指向という言葉には オブジェクト指向分析(OOA) オブジェクト指向設計(OOD) オブジェクト指向プログラミング(OOP) の三つの意味があります。 オブジェクト指向初心者泣かせです。 ここではオブジェクト指向設計を説明します。 ソフトウェアの設計 ソフトウェアの設計には二つの側面があります。 作成するソフトウェアの共通部分を探し出しモジュール化する 作成するソフトウェアが将来変更される部分を抽象化し変更しやすくする 一つ目のモジュール化は構造化設計からある手法です。 オブジェクト指向設計で特に取り上げる点はありません。 ここでは二つ目の将来の変更のために抽象化することに重点を当てます。 オブジェクト指向設計 オブジェクト指向設計とは多態を実装する部分を決めることです。 多態とはオブジェクト指向言語を活用した次のものです。 変更可能な点に抽象クラス*1 （オブジェクト指向言語
プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。
この文章について OOP（オブジェクト指向プログラミング、オブジェクト指向パラダイム）について プログラミング勉強中の大学生さんに説明する機会が何度かあったので、 自分の中で整理するために書きました。 中には適切でない説明もあります。ばっさり省いているところもあります。 詳細より イメージを掴んでもらうことを優先しているためです。 「それにしてもあんまりだなー」という表現がありましたらご連絡いただけると嬉しいです。 大学生さん 大学生さんたちはいろんな背景を持っています。 プログラミングを始めたばかりの人 独学で Objective-C や JavaScript を書いた経験がある人 Web やコンピュータの仕組みについてもこれから勉強する予定の人 使用言語 大学生さんたちはプログラミングの第一歩として JavaScript と PHP を使っています。ここでは説明に PHP のコードを使
デメテルの法則 - Wikipedia
デメテルの法則 (Law of Demeter, LoD) または最小知識の原則 (Principle of Least Knowledge) とは、ソフトウェアの設計、特にオブジェクト指向プログラムの設計におけるガイドラインである。 このガイドラインは1987年の末にかけてノースイースタン大学で作成された。簡潔に言うと「直接の友達とだけ話すこと」と要約できる。基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 「デメテルの法則」という名前は、この法則がアダプティブプログラミングとアスペクト指向プログラミングに関する研究であるデメテルプロジェクトの成果であることに由来する。プロジェクト名は農業の女神であるデーメーテールにあやかっている。 オブジェクト指向における適用[編集] オブジェクト指向
オブジェクト指向プログラミング再入門
論文紹介：Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
デザインパターンとOpen-Closed Principle
1999/06/11 石井 勝 概要 この記事では，まずOpen-Closed Principleの意味と解説を行い，その後デザインパターンをOpen-Closed Principleの観点から眺めます．デザインパターンのうちの多くはOpen-Closed Principleを満たすために用意されたものとみなすことができます．Open-Closed Principleを理解し，数あるデザインパターンの中から，どういう場合にどのパターンを使うのが一番効果的なのかを考えます． 目次 はじめに ソフトウェアと連続性 仮想仕事の原理 修正と追加 Open-Closed Principle Open-Closed Principleの例 Open-Closed Principleの反例 オブジェクト指向とOpen-Closed Principle デザインパターンとOpen-
Rubyで学ぶオブジェクト指向／デザインパターン
Rubyで学ぶオブジェクト指向入門 オブジェクト指向プログラミング入門（その１).pdf オブジェクト指向プログラミング入門（その２).pdf オブジェクト指向プログラミング入門（その３).pdf オブジェクト指向プログラミング入門（その４).pdf 添付１ 論理シミュレータクラス図.pdf 添付２ Pque説明.pdf 添付３ 回路シミュレーション例.pdf 添付４ LogicSimソースコード オブジェクト指向プログラミング入門（その５)簡易システム性能評価シミュレータ.pdf オブジェクト指向プログラミング入門（その６)RUnitに適用されたデザインパターン.pdf Rubyで学ぶデザインパターン パターンサンプルコード このサンプルコードは、Java言語で学ぶデザインパターン入門 結城 浩（著） （ソフトバンクパブリッシング ISBN:479731462）に掲載されているサンプルソ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
おすすめオブジェクト指向練習方法 | サイバーエージェント 公式エンジニアブログ
オブジェクト指向設計の原則と関数型プログラミング
デザインパターン[モデリング] -TECHSCORE-
Do You PHP? - サンプルコード（OOP関連）
koshigoewiki:php:デザインパターン [KoshigoeWiki]
ブラックジャックのオブジェクト指向開発