単一責任の原則（SRP） - Strategic Choice
単一責任の原則（SRP:the Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない。どういうこと？変更理由が2つあるということは、責任（役割）も2つあるということ。そんなジェネラリストなクラスを許さない、という原則。 ところで、「単一責任」って、クラスを作る上で一見当たり前に見える。責任（役割）をそのまま責任ではなく、変更理由としているところがポイント。 この見る角度を変えるところがこの原則の運用の大切な所。なんで？役割を複数もつクラスはもろいクラスだから。 複数の役割を担っているクラスがあって、それをある1つの理由で変更すると、関係のないその他の役割部分にまで影響を及ぼす事になり、その結果予想もしない形でクラスが壊れてしまう。 保守で違う人が修正したら簡単に壊れてしまう。 保守で変更していくと、実装的だけでなく、設計的にもよ
オブジェクト指向の法則集 - Qiita
この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-principles.html ） なお、この記事の他にも石井さんのオブジェクト指向やRubyに関する多くの記事をオブラブの「まさーるのページ」で読むことができます。では、以下に石井勝さん（旧メールアドレス masarl@nifty.com）の記事を転載します
再考: GoF デザインパターン - Qiita
本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における～」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ
教養としてのSmalltalk - 石橋秀仁(zerobase)書き散らす
オブジェクト指向も、MVC (Model-View-Controller) も、アジャイル開発 (XP: Extreme Programming) も、テスト駆動開発も、Smalltalkから生まれた、っていうことについて、徐々に体得的に実感できつつある。 現代のエンジニアリングの潮流がSmalltalkに由来するということは、そこに何か非常に重要な本質が潜んでいる可能性がある。 また何か書きたい。 とりあえず現時点でほとんど確信しているのは、現代のエンジニアは教養としてSmalltalkをやっとくといい、ということだ。仕事でSmalltalkを書くかどうかは関係なく。 関連情報 Smalltalk入門 (全16回) - プログラミングならドットインストール オブジェクト指向９つの簡単なルール 読解いやな法則: にわかな奴ほど語りたがる PharoCasts: Display Picasa
オブジェクト指向JavaScriptの原則
TOPICS Web , JavaScript 発行年月日 2014年06月 PRINT LENGTH 200 ISBN 978-4-87311-681-5 原書 The Principles of Object-Oriented JavaScript FORMAT PDF 本書はJavaScriptが持つオブジェクト指向的な言語特性や、その特性を強力にサポートするECMAScript 5の機能を紹介し、それらの特性や機能を活かすプログラミングの方法、考え方、パターンについて、深くそして簡潔に解説する書籍です。本書を通じて、C++やJavaなど「クラスベースのオブジェクト指向言語」に慣れたプログラマはJavaScript特有のクラスを持たないオブジェクト指向プログラミングの世界への知識を得ることができ、JavaScriptプログラマはJavaScriptのオブジェクトに関する理解をさらに深
プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。
この文章について OOP（オブジェクト指向プログラミング、オブジェクト指向パラダイム）について プログラミング勉強中の大学生さんに説明する機会が何度かあったので、 自分の中で整理するために書きました。 中には適切でない説明もあります。ばっさり省いているところもあります。 詳細より イメージを掴んでもらうことを優先しているためです。 「それにしてもあんまりだなー」という表現がありましたらご連絡いただけると嬉しいです。 大学生さん 大学生さんたちはいろんな背景を持っています。 プログラミングを始めたばかりの人 独学で Objective-C や JavaScript を書いた経験がある人 Web やコンピュータの仕組みについてもこれから勉強する予定の人 使用言語 大学生さんたちはプログラミングの第一歩として JavaScript と PHP を使っています。ここでは説明に PHP のコードを使
オブジェクト指向設計原則 - Strategic Choice
原則について優れたオブジェクト指向開発のための指針。ただ、、、原則は原則。必ず守らなければならないのではなく、まずそれで考えることが重要。逸脱したとしても正当な理由やトレードオフが説明できればよい。一覧単一責任の原則（SRP）オープン・クローズドの原則（OCP）リスコフの置換原則（LSP）依存関係逆転の原則（DIP）インターフェイス分離の原則（ISP）参考アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技作者: ロバート・C・マーチン, 瀬谷啓介出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/07/01メディア: 大型本 Principles Of Object Oriented Designオブジェクト指向設計＠Syboos.jpオブジェクト指向設計の原則＠それはBooksオブジェクト指向設計原則＠ディノオープンラボラトリオブジェクト指向の法則
オブジェクト指向におけるデザインパターン
HOME Last modified: 2014-01-17 ここでは Pree の著書の論旨に基づきつつ、他の文献からの引用をおりまぜて、 「デザインパターン」の意義と概略を整理してみたいと思います。 あくまでも私の解釈と経験に基づく理解なので、誤りや説明不足はご容赦ください。 オリジナルの文献を手に取るきっかけとなれば幸いです。 文献 特集「デザインパターンとオブジェクト指向設計」 月刊ドクター・ドブズ・ジャーナル日本版, 1997年10月号. Design Patterns Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley Professional Computing Series,
複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
継承は is-a、委譲は has-a または uses-a - Writing Some Code
「継承は is-a の関係」というのはオブジェクト指向の基本ですが、最近は何でも安易に継承を使ってしまうことが多かった自分を戒めてくれたのがこちらの本。 アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 作者: Venkat Subramaniam,Andy Hunt,木下史彦,角谷信太郎出版社/メーカー: オーム社発売日: 2007/12/22メディア: 単行本（ソフトカバー）購入: 35人 クリック: 995回この商品を含むブログ (291件) を見る 本書の「32 取り決めを守ってコードを置き換える」(p.129〜)に次のようにあり、継承か委譲か判断の指針になります。 新しいクラスが既存のクラスと置き換え可能で、かつ両者の関係がis-a (である)の場合は、継承を使う。 既存のクラスを新しいクラスで使いたいだけで、両者の関係がhas-a (持つ)またはuses-a (使う
オブジェクト指向プログラミングとは何か? · eed3si9n
2013-09-18 oop はどう定義されるべきだろうか? 純粋オブジェクト指向プログラミング 純粋オブジェクト指向プログラミングは以下のように定義できる: オブジェクトを使ったプログラミング。 オブジェクトとは何か? 他のオブジェクトへの参照を保持し、事前にリストアップされたメッセージを受信することができ、他のオブジェクトや自分自身にメッセージを送信することができるアトムで、他には何もしない。メッセージは名前とオブジェクトへの参照のリストから構成される。 これでおしまい。言い回しは僕が考えたものだけど、アイディアはオブジェクト指向という言葉を作った張本人 Alan Kay (2003) からのものだ。これ以外は、直接 oop に関係無いか、実装上の詳細だ。 この定義から導き出せるものを考えてみよう。 まずは名前空間だ。C の関数と違ってメッセージ (別名メソッド) はオブジェクトごとに
私が愛するオブジェクト指向とそれを使わない理由 - takuto_hの日記
この記事では、私がオブジェクト指向のどこを愛しどこを素晴らしいと感じていて、そのうえでなぜオブジェクト指向を使うことを避けているのかを書き留めておきます。関数型言語使いの方で、「オブジェクト指向の何がいいのかわからない」「オブジェクト指向難しすぎ・複雑すぎ」とおっしゃる方にぜひ読んでいただきたいと思っています。また、「オブジェクト指向言語完璧に理解したわ」と思っている方にも読んでいただきたく思います。 なお、ここでのオブジェクト指向の定義は、「各言語でオブジェクト指向と呼ばれているものすべて」とします。JavaやScalaやJavaScriptやSmalltalkやRubyやCommon LispやOCamlがオブジェクト指向と呼んでいるものすべての総称です。もっとまともな定義が知りたい方は以下の記事がおすすめです。 オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smallta
Continuous Modeling - Fly me to the Luna
みなさまご無沙汰しております。僕はここの所、残業はしないまでも毎日クタクタになるほど忙しい毎日を過ごしています。どんな仕事か一言でいうと、あるプロダクトのアーキテクチャを刷新するお仕事です。今までできなかったあれやこれやを実現するために、既存のアーキテクチャを改善したり、作りなおすお仕事です。今はまだ始まったばかりで、方針を決めるために、既存のアーキテクチャ上に機能拡張してみて問題点を調査したり、どう改善するのか方針案を考えたり、実際に改善案を少しずつやってみたりしています。 このプロジェクトは、それほど大所帯ではないですが、他の会社のエンジニアさんも加わるなど、結構スキルセットがバラバラです。そのため、久しぶりにペアプロで作業を回しています。1日じゅうペアプロすると、一日の終わりの頃には頭がクタクタです。久しぶりです、この感覚。楽しい。 さて、既存のアーキテクチャを見ていくと、10年以上
2010-12-26
リアクティブプログラミングは、「時間とともに変化する値」＝「振る舞い」同士の関係性を記述することでプログラミングを行うパラダイムです。 GUIなどのようにインタラクティブなシステムや、シミュレーションやアニメーションのようにダイナミックに状態が変化するようなシステムを宣言的に記述することができます。 これらの「変化する状態」や「外部とのやりとり」が支配的なシステムは、純粋関数型言語が、その強みを発揮しにくい部分でもあります。 本稿では、リアクティブプログラミングが副作用を含む系を宣言的に記述することを可能にし、状態の管理という厄介な問題からプログラマを開放する可能性があることを示したいと思います。 （割と独自研究に基づく解釈ばかりなのでその点ご了承ください。あと例としてでてくるコードは、Pythonベースの擬似コードで具体的なライブラリに基づくものではありません。） Why Reactiv
Complete Constructor（完全なコンストラクタ） - Strategic Choice
師曰く形式が完全に整ったオブジェクトを返すコンストラクタを作成しなさい。どういうこと？オブジェクトが計算を行えるようになるには、特定の情報を必要とします。その必要な情報を完全に受け取るコンストラクタを提供することで、その計算の「事前条件」をユーザーに伝ます。どうして？引数のないコンストラクタでオブジェクトを生成してから、一連のsetterメソッドを呼び出すことで、状態を整えていく方法があります。柔軟性が高まることもありますが、オブジェクトが正しく動作するためにどんなパラメータの組み合わせが必要なのかが伝わってきません。以下の例では、パラメータの一部がなくても計算できるかどうか、（クライアントから）判断する方法がありません。 Rectangle box = new Rectangle(); box.setLeft(0); box.setWidth(50); box.setHeight(200
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://qiita.com/kenokabe/items/9c650ec8bcb1418c596d
jcabi-aspects – Check Java Classes Immutability in Runtime
https://qiita.com/tokomakoma123/items/a33feffe947a958a2d3a
https://qiita.com/tokomakoma123/items/fb7530232912dc4176c4
オブジェクト指向設計の原則と関数型プログラミング
