ソフトウェア原則[1] - OCP(Open-Close Principle) - Qiita
週刊オブジェクト倶楽部 2003-01号の書評『オブジェクト指向入門』の中で、 OCP"Open-Close Principle"として、 「ソフトウェアモジュールは、変更に対して閉じており、拡張に対して開いているべき」 を紹介しました。第1回目は、このOCP からです。次のC言語コードを見てどう思いますか？ typedef struct { int x, y; } Point; typedef struct { Point p1, p2; } Line; typedef enum { LINE, POINT } Kind; typedef union { Point* point; Line* line; } ShapeUnion; typedef struct { Kind kind; ShapeUnion of; } Shape;
![ソフトウェア原則[1] - OCP(Open-Close Principle) - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/a8e5bfc55412e21d43c6c807aa841cc76f77a0cc/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JUUzJTgyJUJEJUUzJTgzJTk1JUUzJTgzJTg4JUUzJTgyJUE2JUUzJTgyJUE3JUUzJTgyJUEyJUU1JThFJTlGJUU1JTg5JTg3JTVCMSU1RCUyMC0lMjBPQ1AlMjhPcGVuLUNsb3NlJTIwUHJpbmNpcGxlJTI5JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0xZjM1OTcwMzdmNjE1OWQ0OGNlNmE4NjM0MjhiZDc4Yw%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTYxNiZ0eHQ9JTQwa2VuamloaXJhbmFiZSZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZjMwMzVhMmYyZjJkNDIxYTYxMWZhODIwYzRlYWMxMmU%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D85aba36f4575db1f2d3165419398cc91)
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - 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
契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記
契約による設計と名前による型づけ 最近, 社内で契約による設計の話が雑談として何度か出ていて, id:hakobe932さんが社内勉強会で紹介していたり, id:shiba_yu36さんがWEB+DB PRESSでSmart::Argsで制約をチェックする記事を書いていたり, 活発な議論になっている. インスタンスのファクトリメソッドとオプショナルな型を組み合わせると事前・事後条件を満たすことが保証できて, id:hakobe932さんの資料で言うところの「要求型」と「保護型」の区別も明確になってよいという話を書こうかとおもっていた. (これはそのうち別で書く.) とはいえ, こんな話はもう言っている人がいるだろうと思ってちょっと調べていて, どういう語句で調べたらいいか考えていた. インスタンスの型からそれを生成したファクトリメソッドが特定できて, それによって事前・事後条件が保証される
PHPのinterfaceとabstractを正しく理解して使い分けたいぞー ::ハブろぐ
interfaceとabstractの特徴と違いを捉える 今回もPHP話。（正しくないことは @ahomu に教えてもらえると助かりマス） PHP5では、interface（インターフェイスの宣言）やabstract（抽象化）が使用できます。これらの説明を読むと、一見して同じような役割を持っているように見えます。 それは両者とも、メソッドの実装を「インターフェイスを実装したクラス」や、「抽象クラスを継承したクラス」に強制的に任せる機能を持っているからです。これらの挙動は、外見上とても似ています。少なくとも自分はそこで引っかかりました。 interfaceもabstractも便利なオブジェクト指向機能ですが、使い分けができないと、もったいないです。ありがちな話だと、いつまでもabstract一辺倒で、interfaceの出番が見つからない、とか。 今回はそのへんを自分の理解を整理しつつ書き留
「コードを共通化するために継承しよう」なんて寝言は寝て言えとゆ話
「共通化 → 継承」という考えは間違っている、と断言する。こんなものはオブジェクト指向でも何でもない。仮想関数を持たないスーパークラスは要注意だ。 これはまさしくその通りで，「共通化 → 継承」のような説明がいまだに堂々とまかり通ってるのには，どうしたもんだろうと思う。それなりに人気のある書籍ですら，そんなこと書いてることがある。 思うのだけれども，「共通化 → 継承」といった発想が産まれる原因は，「差分プログラミング」の実装手段として継承を位置付けてるからなのだと思う。もちろん，差分プログラミングという概念自体，発想としてアリなのは言うまでもありません。同じ処理をあちこちに書かないことは，プログラマの美徳にすらなっている。しかし，それはあくまでも発想であって，具体的な実装手段を伴うものではありません。この点，そこに（実装）継承という実装手段をあてがったバカタレは，ほんとに罪深いと思う。委
デメテルの法則 - Wikipedia
デメテルの法則 (Law of Demeter, LoD) または最小知識の原則 (Principle of Least Knowledge) とは、ソフトウェアの設計、特にオブジェクト指向プログラムの設計におけるガイドラインである。 このガイドラインは1987年の末にかけてノースイースタン大学で作成された。簡潔に言うと「直接の友達とだけ話すこと」と要約できる。基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 「デメテルの法則」という名前は、この法則がアダプティブプログラミングとアスペクト指向プログラミングに関する研究であるデメテルプロジェクトの成果であることに由来する。プロジェクト名は農業の女神であるデーメーテールにあやかっている。 オブジェクト指向における適用[編集] オブジェクト指向
オブジェクト指向の概念の発明者は誰ですか？ - Smalltalkのtは小文字です
忙しい人のためのまとめ 一般に「オブジェクト指向プログラミング」と呼ばれる考え方には発案者が異なる二系統がある。（ただし簡単のため、次のうち前者から批判的に派生して生じたプロトタイプベースのオブジェクト指向はここには含めていない） アラン・ケイによる、変化に強い長期運用可能な遅延結合システムを SIMULA67 にあった「オブジェクト」をメッセージの受け手とすることで実現（オブジェクトにメッセージ送信）するアイデアに基づく「メッセージングのオブジェクト指向」と、 ビアルネ・ストラウストラップ（前後して抽象データ型を発案したリスコフ本人、オブジェクトクラスを考えたニガードらSIMULA陣営、Eiffelのメイヤーらも同様の着想を得ている）による、ユーザー定義型（抽象データ型）を SIMULA67 にあった「クラス」という言語機能を使って実現（カプセル化、継承、多態性）するアイデアに基づく「抽
リッチなドメインモデル 名前探し
3. ドメイン駆動設計への道 設計の改善 ドメインの理解 ・メソッドの構成 オブジェクト指向 ・オブジェクト間の特性移動 設計のスタイル 言葉の力 基礎訓練 ・データの再編成 モデル駆動 ・条件記述の単純化 責任駆動設計 エクササイズ ・メソッド呼び出しの単純化 役割ステレオタイプ ９つのルール 小さく作る 責任割当の原則 GRASP For 実装の原則 Thoughtful Developer ・クラス Leading Designer ・振る舞いとメソッド ・状態とコレクション 契約による設計 4. ドメイン駆動設計への道 シンプルな ﾄﾗﾝｻﾞｸｼｮﾝｽｸﾘﾌﾟﾄ リッチな 大きな ﾄﾗﾝｻﾞｸｼｮﾝ 泥団子 ｽｸﾘﾌﾟﾄ リッチな シンプルな ドメインモデル ドメインモデル アーキテクチャなし 汎用データ型 テーブルと対応した 業務の言葉で組み立てる 汎用命名ルール ドメインオブジ
八角研究所 : 高速スクリプト言語「Lua」を始めよう！（4） - 高速スクリプト言語「Lua」を始めよう！（4）
高速スクリプト言語「Lua」を始めよう！（4） - 高速スクリプト言語「Lua」を始めよう！（4）
Rubyの呼び出し可能オブジェクトの比較(1) - 世界線航跡蔵
Rubyにはコード片を表すオブジェクトが複数ある。 Method , UnboundMethod , Proc である。 Continuation は少し違うけど、実行コンテキストを記憶しているオブジェクトという意味では近いものがあるか。『 Ruby Way 』にはこういういろいろがあることについて「驚くほどのことではありません」と書いてあるけれども私は驚いた。で、これらが微妙に違うのだ。困ったもんだ。いや、便利なのかもしれないが。 それで今回はこれらの概要を眺めてみたいと思う。 普通のメソッド defでメソッドを定義するのが一番普通だやな。 class C def greeting(arg) puts "C#greeting reveived #{arg}" end def iterator yield 'iterator 1st' yield 'iterator 2nd' yield
突破すると一気に学習が加速する「オブジェクト指向学習の壁」を突破する鍵となる知識を、中学生でも分かるように図解してみた(初学者向け) - @fromdusktildawnの本館
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
オブジェクト指向を理解したければRubyを使え！ - 是非に及ばず
普通の構造化プログラマーがオブジェクト指向の存在意義を理解するコツ を読んで脊髄反射してみる。 自分自身がRuby信者(笑)なので、Rubyをおすすめするわけなんだけども、中途半端にオブジェクト指向機能が入っている言語で学習したところで構造化プログラミングから抜け出せないんじゃないかなと思う。 環境が人を作るという事もあるので、まずは全てがオブジェクトであるRubyでしばらくプログラムしていれば、オブジェクトの世界で自分がどう歩くべきか自然と分かるんじゃないかな。 なにしろ、Rubyの世界にはオブジェクトしかないわけで、int型とかなくて1とか2とかの数字は実はFixnumクラスのインスタンスだったりする。だから、1.to_sだとか、1.absなんてのが実行できるし、1.methodsで1が持つメソッド一覧を取得できたりする。 なにそれ、すげー！と感じたら、あなたは分かっている、または分か
Perlオブジェクト指向プログラミング
-> 趣旨と注意書き -> 身近なpackage -> なんのためのpackage ? -> What's `new' ? -> bless ( reference => package ) -> Hello, Module World! -> オブジェクト？ -> main パッケージと関連付けてみる -> クラスとメソッド -> オブジェクト指向 -> オブジェクトがリファレンスなら… -> -> を連続する -> 継承 -> 多重継承 -> 多重継承をやめる -> 多重継承をやめる(もう少し簡単に) -> 情報源(書籍等) <- モドル 趣旨と注意書き これを読んでも、あんまりきちっとした知識は、身に付きません（^^; オブジェクト指向の概念はほんの少ししか説明しません。ここで述べるのは、Perlでどうやるかってのが主です（それも不十分＆嘘まじりかも）。 とりあえず、モジュールを作り
実はオブジェクト指向ってしっくりこないんです！：気分はstatic！：エンジニアライフ
わたしはこれまで、C言語、Visual Basic、SAP ABAP、最近になって ASP.NET C# などの言語を使ってきた。 「自分でクラスを作ってオブジェクト指向っぽいことをしている」なんてことはまったくない。特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。データベースにアクセスするアプリケーションをC#で書いているのだが、Visual Studioで供給しているSQL関係のクラスを使えばできてしまうのだから。 オブジェクト指向の入門書では、クラスが持つ隠ぺい性が強調されているが、これは他
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方: Sandi Metz (著), 髙山泰基 (翻訳): 本
GitHub - trailblazer/trailblazer: The advanced business logic framework for Ruby.
https://qiita.com/tokomakoma123/items/fb7530232912dc4176c4
Ustream.tv: ユーザー rubykaigi: rubykaigi1, rubykaigi1. 技術
[Lua] その７ メタテーブル - 2009-07-31 - CREST’S WEBLOG (」・ω・)」うー！(／・ω・)／にゃー！
Perlゼミ(サンプルコードPerl入門)