サービスデザインパターン - winplusの日記
縁あって、翻訳をご担当された角征典さんより、『サービスデザインパターン』をいただきました。ありがとうございます。 サービスデザインパターン SOAP/WSDLとRESTful Webサービスの基本的な設計ソリューション あるサービスやツール、フレームワークなどの使い方を解説した書籍とは違って、本書は設計手法の解説なので内容はなかなかむづかしいのですが、文章が読みやすいので（文意がくみ取りにくいところがないので）、つらくなることがありません。ただ、書名にデザインパターンとあるようにパターン集なので、いたるところで『オブジェクト指向における再利用のためのデザインパターン』[GoF]や『エンタープライズ アプリケーションアーキテクチャパターン』[POEAA]といった古典が参照されており、いかに自分が不勉強であるかを思い知らされました...[POEAA]を角さんが訳してくだされば...。 Rail
なんちゃってデザインパターンで条件分岐をなくす - give IT a try
昨日会社のメンバーからコーディングについて相談を受けました。 話を聞いていると、オブジェクト指向設計を利用してコードをリファクタリングしたい様子でした。 彼は頑張ってインターフェースやクラスを自分で定義していたんですが、ちょっとぎこちない設計だったので、おいらはStateパターンとFactoryパターンらしきテクニックを使って、改善のお手伝いをしてみました。 そのときの事例をめちゃくちゃデフォルメして説明すると、こんな感じになります。 プログラムはStateに応じて文字や色を変更します。 初期状態です。 ボタンを押すとStateに応じて文字や色が変わります。 メンバーが最初に書いていたプログラムのイメージはこんな感じです。 using System; using System.Collections.Generic; using System.ComponentModel; using S
MVCは死んだ。MOVEするときがきた - きしだのHatena
Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ？ 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
まとめ本 - Strategic Choice
まとめ記事を書いた本の一覧です。まとめ記事の内容も、簡単に説明しています。一覧出典本まとめ記事オブジェクト指向設計原則パッケージ設計の原則オブジェクト指向を効果的に活用するための、クラス設計の原則についてまとめています。（SOLID原則） また、クラスレベルだけでなく、パッケージレベルの原則についてもまとめています。GRASPパターンオブジェクト指向設計の基本は「適切なクラスに適切な責任を割り当てること」です。この指針である「GRASP」についてまとめています。構造化プログラミング構造化プログラミングのエッセンスについてまとめています。 パラダイムが異なっても（＝オブジェクト指向でも）通用する・適用できる考え方です。 GoFのデザインパターンGoFのデザインパターンを全てまとめています。 各パターンのまとめ後、「なんでこんなことするのか？」「こうするとどういう効果がうまれるのか」を考察して
Ruby 2.0.0で学ぶ、14個のデザインパターンを作りました[GoF][Design Pattern] - 酒と泪とRubyとRailsと
GoFのデザインパターンとは、「プログラミングのベストプラクティスを体系化したもの」です。このベスト・プラクティスをしっかりと理解して設計すれば、ソフトウェア設計の効率を高めることができます。またデザインパターンが「プログラミングの思想」の共有をよりスムーズにしてくれます。先人たちの試行錯誤の結果を効果的に利用して、プログラミングをもっと楽しんでしまいましょう！ 🗻 デザインパターンのポイントGoFのデザインパターンには下のプリンシパルがあります。 変わるものを変わらないものから分離する インタフェースに対してプログラミングし、実装に対して行わない 継承より集約 委譲、委譲、委譲 必要になるまで作るな(You Ain’t Gonna Need It./YAGNI) 🤔 デザインパターン一覧 アブストラクトファクトリ ビルダ ファクトリメソッド シングルトンパターン アダプタ コンポジッ
![Ruby 2.0.0で学ぶ、14個のデザインパターンを作りました[GoF][Design Pattern] - 酒と泪とRubyとRailsと](https://cdn-ak-scissors.b.st-hatena.com/image/square/c2ea7e72d0d7f3ba6c237909f321e67ffbdaa24e/height=288;version=1;width=512/https%3A%2F%2Fmorizyun.github.io%2Fimg%2Fog_image.png)
ジェネリクスによるVisitorパターン拡張の考察 - プログラマーの脳みそ
先日twitterで "Expression Problem" という問題を知った。 静的な型付けの下で、場合分けのデータ構造に対して、新しい場合分けとその場合に対する新しい処理を、元のソースコードに手を加えることなく拡張定義すること 2009-05-16 この問題が意図するところを語るにはまずオブジェクト指向から流れを辿らねばなるまい。 オブジェクト指向のポリモーフィズム Javaのようなオブジェクト指向の言語で、ある特定のメソッドがあることを抽象クラスHogeで保証するとしよう。 public interface Hoge { void hoge(); } このとき、機能性、つまりメソッドというのは増えることがない固定のものだが、継承して実装されたクラスというのは自由に増やすことができる。そして、抽象型Hogeを扱っている既存コードは修正する必要がない。 これはいわゆる開放/閉鎖原則(
コードウォッチ：関数型プログラミングの自惚れ問題
僕は関数型プログラミングが好きだ。次の10年にかけてコードの革命を起こしていくだろうと考えている：言語はより関数型の機能を採用していくだろうし、開発者はより関数型の技術を導入していくだろうし、いくつかの点では、関数型プログラミングの原則はコードを組み立てていく上で「自然で」もっとも明確なやり方だとみんな考えるようになっていくだろう。 だけど、僕はもうこのシナリオを本気にしちゃいない。関数型プログラミングは、ワクワクするものを学ぶことに興味があると言っている主流のプログラマにとって明白な、大きな問題を抱えている：関数型プログラマーは自惚れ野郎どもだってことだ。 モナドって何？「モナドは自己函手の圏における単なるモノイドに過ぎないよ！(ｷﾘｯ ヒャッハー、そんな単語も何一つ分かってないとか、君、おバカな主流プログラマーってやつじゃないかい？m9(＾Д＾)」 実用的なシステムを構築するのに役に立
「MVVMパターンが必要な理由」啓蒙用資料公開 - the sea of fertility
MVVMパターン的な実装は、他のプラットフォームでは選択肢の一つにすぎませんが、WPF/Silverlight(Windows Phone 7 含む)においては唯一の選択肢です。コードビハインドを書かないことはMVVMパターンそのものの定義とは関係ありません。まずはスキルにあったレベルでMVVMパターンを意識した実装を初めてみませんか？ 以前の勉強会発表資料（わんくま勉強会での発表資料の半分以上をカットし、Androidテスト祭り分追加）を加工し、社内勉強会、そのほかの勉強会・ブログなどで自由に使える資料として公開します。私の個人名は抜いてあります。 無許可の改変・引用なども問題ありません。ただ、資料の直接の商用利用などはご遠慮ください。 ブログに張り付けたい場合、下のbマークから埋め込み用URLを取得できます。 「コードビハインドを書くのはMVVMパターンではない」などの誤解が、MVVM
サバクラ両方で動く JavaScript の大規模開発を行うために
サバクラ両方で動く JavaScript の大規模開発を行うために 原文：Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.) 考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる？ 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket te
日本でパターンが広まらない理由の一つは「ワンパターン」などのネガティブな和製英語のせい？ - 達人プログラマーを目指して
ソフトウェアアーキテクトの作業の一つに、システム全体の設計思想や開発方針を記述するアーキテクチャ説明書を作成をする仕事があります。そして、そのような設計書を記述する際に私はアーキテクチャパターンやデザインパターンの用語を利用します。例えば、 システム全体をレイヤーアーキテクチャパターンに従い「プレゼンテーション層」「アプリケーション層」「ドメイン層」「インフラ層」に分割する。 MVCアーキテクチャパターンにより表示ロジックとビジネスロジックを切り離し独立して画面を変更できるようにする。 オブザーバーパターンを使ってイベントを監視する機能を容易に追加できるようにする。 といった具合にです。実際に、パターンの用語を適切に使うことで、どうしてそういう設計をするのかという設計判断を簡潔に記述できますし、関連するパターンに言及することでトレードオフや代替手段についても言及でき、情報量の厚みを増すこと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
