単一責任の原則（SRP） - Strategic Choice
単一責任の原則（SRP:the Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない。どういうこと？変更理由が2つあるということは、責任（役割）も2つあるということ。そんなジェネラリストなクラスを許さない、という原則。 ところで、「単一責任」って、クラスを作る上で一見当たり前に見える。責任（役割）をそのまま責任ではなく、変更理由としているところがポイント。 この見る角度を変えるところがこの原則の運用の大切な所。なんで？役割を複数もつクラスはもろいクラスだから。 複数の役割を担っているクラスがあって、それをある1つの理由で変更すると、関係のないその他の役割部分にまで影響を及ぼす事になり、その結果予想もしない形でクラスが壊れてしまう。 保守で違う人が修正したら簡単に壊れてしまう。 保守で変更していくと、実装的だけでなく、設計的にもよ
インターフェイス指向設計 - yuku-t
2015-03-12 インターフェイス指向設計 book review 『インターフェイス指向設計』を読んだ。念の為に書き添えておくと、この本が指すインターフェイスというのは、いわゆるUIのことではなく、プログラミング部品としてのinterfaceのこと。 インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践作者: Ken Pugh,角谷信太郎(監訳),児島修出版社/メーカー: オライリージャパン発売日: 2008/05/24メディア: 大型本購入: 16人 クリック: 357回この商品を含むブログ (67件) を見る この本のいいところは オブジェクト指向プログラミングの肝は 高凝集 で互いに 疎結合 なオブジェクトを用いてプログラムを構築することにある という態度を一貫して保ち、その目的を達成するにはどうすべきかという観点からインターフェイスの利用について語ってい
Haskellでの合成可能なオブジェクトの構成とその応用
Haskellでの合成可能なオブジェクトの構成とその応用 木下郁章, 山本和彦, 2015 Haskellで状態を管理する際は、 一般的に代数データ型や型クラスが用いられるが、 データが拡張できないか、動的な性質を持たない。 そのためHaskellは、 複雑な状態を扱う問題領域には適していないと考えられてきた。 一方で、一般的なオブジェクト指向言語では、 オブジェクトを提供することでこの問題領域で成功を収めている。 本論文では、Haskellの言語仕様を変更することなしに、 オブジェクト指向言語から着想を得たオブジェクトを実現する。 本論文で提案するオブジェクトは圏を構成し、合成を用いて継承を表現できる。 また、終了する運命にあるオブジェクトやストリーミングなどに応用でき、 複雑な状態を扱うゲームの実装にも使われている。 論文をダウンロード(PDF) PPL 2015 発表スライド ここに
【PHPで学ぶデザインパターン入門】第1回 Strategyパターン | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは、エンジニアの王です。 今回はデザインパターンと、デザインパターンの中の「Strategy」について紹介したいと思います。 デザインパターンとは？ 端的にいうと、「よくある問題へのよくある解決策」です。 ここでは、あくまでもソフトウェア設計の場合に限定しているのですが、さまざまなコンテキストで活かせる概念です。 「今までの経験上、この手の問題なら、この方法（パターン）でやればうまくいくよ！」という経験則は誰にでもあると思います。それがゲームの場合なら「攻略法」、料理の場合なら「レシピ」、語学の場合なら「定型文」だったりします。 ソフトウェア設計の場合、特にオブジェクト指向プログラミングにおいて言うなら、「デザインパターン」とは、過去のソフトウェア設計者が失敗に失敗を重ね、試行錯誤の中から導き出した再利用しやすいノウハウの集大成のようなものです。 そう、要するに、柔軟性、拡張性、再
オブジェクト指向vs関数型プログラミングの壮絶な宗教戦争っていつしてたの……？ - Qiita
なんか荒れてますが、私も一言いいたいです！！ オブジェクト指向がそうであるように、関数型も銀の弾丸ではありません！！！ - 参照透過性はすばらしい この記事をぼやーんと眺めてました。 高精度煽り除去フィルタを通して読むと、関数型のアプローチがよい、と言う話ですね。 実際コードを書いてると、自分の書いたコードに関するバグは、体感、８割くらいが副作用に起因するものです。 副作用があると、呼び出し元が考慮すべきパターンが増えます。Mの状態を持つオブジェクトと、Nの状態を持つオブジェクトをつなぐと、MxNのパターンになるわけです。これはつなぐたびに積算されるため、爆発します。 副作用が無い場合、状態数は1なわけです。1x1は？1です！！よって、状態の組み合わせ爆発は起きません。考慮すべきは、入力値のパターンだけで十分なわけです。 他にもいろいろメリットが！！ すばらしき参照透過性！！関数世界最高で
インスタンスメソッドとクラスメソッドはどのようにして使い分けるべきか？（Rubyの場合） | mah365
Rubyといったオブジェクト指向言語を学ぶと、メソッドの定義方法としてインスタンスメソッドとクラスメソッドという2通りの定義方法があることを学ぶと思います。しかし、言語自体のガイドブックには「定義方法にインスタンスメソッドとクラスメソッドがある」と書いてあるだけで、大抵その使い分けについては書かれていません。 そういう訳で、このエントリではその使い分けについて少し考えてみたいと思います。理論的に厳密な使い分けを目指すというよりは、そもそも使い分けの検討が全くつかない！という方に向けて、その指針の一助となることを目指します。 インスタンスメソッドとクラスメソッドとはそもそものところ、Rubyといった「オブジェクト指向の考え方」を実装した言語の機能です。その機能がなぜあるのか？というそもそものところは、オブジェクト指向の考え方にさかのぼることになります。 そこで、インスタンスメソッドとクラスメ
2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 - Qiita
はじめに もうすっかり年末なので、これから2015年にかけてアプリケーションアーキテクチャがどのようになっていくのかという個人的な考え/妄想や背景について、「リアクティブ」というキーワードをもとににまとめてみたいと思います。 Google Trendsを見ると"reactive programming"という言葉は2010年前後から、ゆっくりとバズをし始め、現在も上昇を続けています。 また、仕事としては、2010年ごろから大規模なWebサービス開発において、フロントエンド、バックエンド、アルゴリズム改善といった様々な箇所で、リアクティブプログラミングの要素を取り入れながら、アーキテクチャの改善を進めてきました。そのため、こういったアーキテクチャがコード品質の維持や安定性の向上、実際的で複雑な問題の解決にも適応可能であるということを実感として持っています。 近年、そういった要素が様々なツール
ドメイン駆動設計のリファレンス本 | GuildWorks Blog
井上です。 現在、ドメイン駆動設計(Domain Driven Desing . 以下 DDD)を用いて開発を行っています。 DDDの参考書籍といえば、もちろん「エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう」(以下 DDD本)ですが、その著者であるエリック・エヴァンスが最近(2014/9/22)「Domain-Driven Design Reference: Definitions and Pattern Summaries」という新しい本(以下 DDDリファレンス本)を出していることに気がつきました。 DDDリファレンス本とは 早速DDDリファレンス本を取り寄せてみました。８８ページと非常にコンパクトな本になっています。 内容的には、以下で公開されているPDFに新しい図や写真を追加してペーパーバックとして出版したもののようです。 DDD REFERE
第1回 Hello, Wicket | gihyo.jp
Wicketとは WicketはApache Software Foundationで開発されている、Webアプリケーション開発用のフレームワークです。フレームワークにもさまざまなものがあり、それぞれ用途が異なります。Wicketの行うことは、ブラウザからのリクエストを受け付け、処理を振り分け、ページを生成してブラウザにレスポンスを返すことです。位置づけとしては、Apache Strutsと同じと考えれば良いでしょう。 Wicketの特徴 Wicketには他の多くのWebフレームワークとは異なる、大きな特徴があります。多くのWebフレームワークが、リクエストからレスポンスまでのフロー（流れ）をどのようにコントロールするか、という方針で作られているのに対して、Wicketは「Webページをページというオブジェクトとして扱い、オブジェクトを組み立てることでアプリケーションを構築する」という考え
問．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個ほ
N1875: C言語にクラスを追加する提案
ask.fmで、面白い質問が来た。なんと、C言語にクラスを追加する提案論文が、先月末に公開されているというのだ。 N1876: Adding classes to C C言語の標準規格は追っていないのだが、なかなか興味深い。 この提案は、C言語にC++風のクラス機能を追加する提案だ。ただし、C++のクラスをそのまま持ってくるのではなく、だいぶ保守的な採用の仕方をしている。 この論文で提案されているクラス機能は、C++の文法によく似ている。クラスstructかclassキーワードで宣言する。アクセス指定子もあり、structはデフォルトでpublic、classはデフォルトでprivateなのも、C++と同じだ。 派生はあるが、多重派生は認められていない。 virtual関数やRTTIはない。 また、C++にある、自動的に呼ばれるコンストラクター、デストラクターは存在しない。 かわりに、イニ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践: Ken Pugh (著), 角谷信太郎(監訳) (翻訳), 児島修 (翻訳): 本
https://qiita.com/kenokabe/items/7bc03b751776ec080da8
https://qiita.com/kenokabe/items/9c650ec8bcb1418c596d
Amazon.co.jp: オブジェクト指向でなぜつくるのか―知っておきたいプログラミング、UML、設計の基礎知識―: 平澤章: 本
Amazon.co.jp: オブジェクト指向入門 第2版: 原則・コンセプト: バートランドメイヤー (著), 酒匂寛 (翻訳): 本
Amazon.co.jp： デザインパターンとともに学ぶオブジェクト指向のこころ (Software patterns series): アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章: 本
オブジェクト指向における再利用のためのデザインパターン
