元記事が非常に長いので次のように分割しました。 #1 モジュールはどのように使われてきたか #2 Module Builderパターンとは何か（本記事） #3 Rails ActiveModelでの利用例 あとがき: Module Builderパターンという名前について 追記（2017/10/27） 元記事からTechRachoにリンクいただきました🙇 shioyamaさんがRailsに投げたプルリクを知らせていただきました: #30895 Convert AttributeMethodMatcher to Module Builder 概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Ruby Module Builder Pattern 公開日: 2017/05/20 著者: Chris Salzberg サイト: dejimata.com RubyKaigi 2
Ruby のモジュラリティの再発見(翻訳記事) Tweet これは、弊社のクリス・サルツバーグによる Rediscovering Modularity in Ruby — Commerce Hack という記事の翻訳です。 デジカの開発チームは、広島で開催された、Ruby開発者の世界で一番大規模な集まりである RubyKaigi 2017 に参加しました。これに参加するのは初めてではないですが、チーム全体で用意をして臨むのは初めてでした。CEOと4人の開発者が現地に行きました。私たちはかわいいステッカーを持ち込み、ちょっとシャレた配布物を印刷して、小さなブースで展示しました。さらにはテキストアドベンチャーゲームまで作りました。 RubyKaigi での発表内容 私が一番力を入れたのは、二日目に行なったThe Ruby Module Builder Patternという発表です。これは私が最
こんにちは、hachi8833です。今回の翻訳記事は、Rubyならではのデザインパターンとでも言うべき「Module Builderパターン」の詳細な解説です。RubyのModuleが実はクラスであることをうまく利用していて、Railsなどのフレームワーク側で有用性が高いパターンであるように思えました。 元記事が非常に長いので次のように分割しました。 #1 モジュールはどのように使われてきたか（本記事） #2 Module Builderパターンとは何か #3 Rails ActiveModelでの利用例 あとがき: Module Builderパターンという名前について 追記（2017/10/27） 元記事からTechRachoにリンクいただきました🙇 shioyamaさんがRailsに投げたプルリクを知らせていただきました: #30895 Convert AttributeMetho
2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ．タイトルの通り，コンテナのデザインパターンがまとまっていて，これからコンテナ設計をする人も，既にコンテナを運用している人も，デザインパターンを学べるのは価値があると思う．一部ミスリードをしているかもしれない． Design patterns for container-based distributed systems 論文も公開されている． https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45406.pdf パターン一覧 Single-container management pattern
コンポーネント指向での開発も割と枯れてきて、昨年から海外ではいわゆるデザインパターンに名前がついて紹介されることが多くなってきました。 この記事ではその内の一つ、Compound Componentsを紹介いたします。 またタイトルに「Reactの」とついてますが、実装例がReactなだけでコンポーネント指向であれば他のUIライブラリでも考え方は流用可能です。 完成した実装はここに置きました。 https://codesandbox.io/s/104lvmynj4 参考 Ryan Florence - Compound Components Advanced React Component Patterns Compound Componentsとは はじめに Compound という言葉ですが直訳だと動詞で 混ぜ合わせる という意味です。実際の実装は混ぜ合わせるというよりは「組み合わせる
よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ
はじめに# デザインパターンにでてくる Factory Method と Abstract Factory. なんだか, いつになっても違いが分からない… というわけで一旦整理してみることにした. 能書き# まずは, 一般的な説明をネットからひろう. Factory の原則# 生成と実装を分離することで, プログラムはシンプルになる. 生成パラメータの指定方法をシンプルに 生成後の管理をシンプルに 生成するオブジェクトの指定方法をシンプルに 特定のケースで特定のオブジェクトを生成するのは手続き思考的. 2 つをわけて考えることで設計に集中. 動作方法 生成,管理方法 Factory Method# オブジェクトの生成を行う時のインタフェースを規定して, インスタンス化するクラスを決定するのはサブクラスに任せる. factoryMethod の中でオブジェクトの生成をすることで, 生成を生成
イントロダクション オブジェクトを生成するnewは非常に負荷のかかる処理ですので、使いまわしが効くオブジェクトを毎回newするのはパフォーマンス上問題です。 たとえば、後述のファクトリメソッドパターンで取り上げるファクトリは毎回newする必要がないため、初めに生成したオブジェクトを再利用すぺきです。 また、データベースのコネクションプール数を制限したい場合、データベースアクセスオブジェクトの生成数を制限する必要があります。 このようにオブジェクトの生成数を制限したいときは、シングルトンパターンの出番です。 このパターンを使えば、オブジェクトを外部から直接生成させることを防ぐことができ、クラス自体に同時に生成できるオブジェクトの数を管理する機能を持たせることができます。 パターン解説 シングルトンパターンの特徴は、シングルトンクラスのオブジェクト生成を、シングルトンクラス自身が提供するオブジ
イントロダクション オブジェクトを利用する側からすれば、使用する際にオブジェクトの詳細を意識したくはありませんよね。 たとえば、条件によってデータファイルの読み込みに使うオブジェクトが異なる場合、CSV形式であればCSVDataReaderオブジェクトを、XML形式であればXMLDataReaderオブジェクトを生成します。 通常はif、else、switchなどの条件分岐を使用して、条件ごとに生成するオブジェクトを変更します。 ここで新たなデータファイル形式への対応が必要になった場合は、新しいオブジェクト生成処理と、条件式を追加しなければいけません。 オブジェクトの使用者は、オブジェクトが使用できる状態で受け渡してもらい、オブジェクトは使うことだけに専念したいものです。 また、このようにオブジェクトの生成処理と使用処理が同じコードに書かれていた場合、オブジェクトの生成処理によってオブジェ
3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as
概要 改めて基本を学ぶ。 Rubyによるデザインパターン第1章。 デザインパターンとは プログラミングにおいて繰り返し現れる問題に対する、適切解のパターン。 無駄無く設計されたオブジェクト指向プログラムの実現をサポート。 パターンとしてカタログ化されていることで 車輪の再発明を防ぐ デザインパターンの根底にある5つの考え 変わるものを変わらないものから分離する プログラムはインターフェイスに対して行う（実装に対して行わない） 継承より集約 委譲、委譲、委譲 必要になるまで作るな（YAGNI） 変わるものを変わらないものから分離する ソフトウェアの仕様には必ず変更が加わるもの。 変わるものと変わらないものを分離しておくことで、 「仕様の変更」に対して「システムの変更」を出来る限り局所的にする。 プログラムはインターフェイスに対して行う（実装に対して行わない） 可能な限り「一般的・抽象的なもの
普段Javascriptをよく書いているのですが、設計が今の自分の弱点だなぁと思い、 積読になっていた JavaScriptデザインパターン – オライリー・ジャパン を引っ張りだして勉強したことを紹介していきます。 内容に関して何か間違いや問題があったらご指摘ください。 デザインパターンとは デザインパターン – wikipedia “ソフトウェア開発におけるデザインパターン（型紙（かたがみ）または設計パターン、英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。” デザインパターンというのは、テンプレートの様なものと考えるとわかりやすいかもしれませんね。 また、Javascriptデザインパターンでは次のように提唱されています。 パターンは実績のある解決策で
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代
GoFのデザインパターンとは、「プログラミングのベストプラクティスを体系化したもの」です。このベスト・プラクティスをしっかりと理解して設計すれば、ソフトウェア設計の効率を高めることができます。またデザインパターンが「プログラミングの思想」の共有をよりスムーズにしてくれます。先人たちの試行錯誤の結果を効果的に利用して、プログラミングをもっと楽しんでしまいましょう！ 🗻 デザインパターンのポイントGoFのデザインパターンには下のプリンシパルがあります。 変わるものを変わらないものから分離する インタフェースに対してプログラミングし、実装に対して行わない 継承より集約 委譲、委譲、委譲 必要になるまで作るな(You Ain’t Gonna Need It./YAGNI) 🤔 デザインパターン一覧 アブストラクトファクトリ ビルダ ファクトリメソッド シングルトンパターン アダプタ コンポジッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く