Ruby Singleton Pattern
Dalibor Nasevic Principal SDE @GoDaddy working on the email delivery infrastructure. Singleton is perhaps the most hated of all programming patterns. You can read some of the reasons for this in Why Singletons are Evil. But, I think it has some good usages. I will start by describing what a singleton pattern is, walk through different ways of implementing it in Ruby, and point to how it's used in
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)
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の問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
MVC is dead, it's time to MOVE on.
MVC is a phenomenal idea. You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self-contained bits of … What? I’m certainly not the first person to notice this, but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don’t know where else to put it. To fix
ドメイン駆動設計の概要
目次 プラトン的モデル 言うべきことを言う コンテキスト 価値提案を把握する 単一責任システム エンティティは ID とライフサイクルを持つ 値オブジェクトは記述する 集計ルートによりエンティティを結合する ドメイン サービス モデルの主要な操作 リポジトリにより集計ルートを省略する データベースの関連事項 DDD の使用を開始する ドメイン駆動設計 (DDD) とは、洗練されたオブジェクト システムの設計に役立つ原則とパターンをまとめたものです。設計に DDD を適切に適用することで、ドメイン モデルと呼ばれるソフトウェア抽象化を実現できます。このモデルにより複雑なビジネス ロジックをカプセル化できるため、実際の業務とコードとの間に存在するギャップを小さくすることができます。 この記事では、DDD に関連する基本的な概念と設計パターンについて解説します。機能豊富なドメイン モデルを設計し
xxxManager はよくない - 閑古鳥
SomethingManager - Radium Software Development クラスの名称をなんたら Manager とするのは良くない、という話。 以前にも似たような趣旨の話を見かけた記憶があるのですが、どこだったか思い出せません。とにかくまあ、前回読んだ時にも気をつけようと思ったのですが、それでもやっぱりたくさんあります。 Manager クラス。 大体 hoge があって hogeManager がある、みたいな感じになってしまっています。 foo があれば fooManager 。もっと、役割を限定しなければいけませんね。 Manager という名前がついていても、実際のそのクラスの役割はそれほど大したことをやっていないことも多いです。例えば画面に何かを表示するだけとか、データを持っておくだけとか。そういうクラスは名称を正確なものに変更するだけでもだいぶ違うのではと
[クラス設計のアンチ・パターン]我は管理者
現象 クラス名の最後に、やたらManagerやController、Handler、Supervisorといった名詞が加わっている。 状況 で？このUserAuthorityManagerの役割はなんだって？ え？UserのAuthorityプロパティを見て、その値から判断してアクセスできるデータを選別してるんだって？ なんでそのAuthority自身が主体的に動いてないのさ？え？Authorityはintだって？？ で、このUserManagerは？ え？Userを生成するときの構成を管理したり？Userが画面に遷移可能か管理したり？あとUserへのサービス構成の管理もやってるんだって？？ …それ、ちゃんとクラス設計してる？ 解説 まあ、上記の状況は極端すぎるとして。 HogehogeManager(いくつか名前があるので、代表でManagerを使う)、じつにお手軽で付けやすい名前なので
![[クラス設計のアンチ・パターン]我は管理者](https://cdn-ak-scissors.b.st-hatena.com/image/square/126e9c63960837b5815901e11e1f6c1303c17f2b/height=288;version=1;width=512/https%3A%2F%2Fblog.seesaa.jp%2Fimg%2Fogp_logo.png){kind=logo}
C# 4.0で実装するデザインパターン「その１ 生成に関するパターン」 - かずきのBlog@hatena
気が向いたやつをやってみます。最初はGoFの全パターンをやってみようと思いましたが、あまり従来と変わらないものとかもあるので、これはちょっと実装が変わるかなと思ったものをピックアップしていくつもりです。。 ちなみに、参考にしてるのは以下のサイトです。 Skeleton of GOF's Design Patterns なるべく上記のサイトと同等のコードになるように努めています。 今回は、とりあえず生成に関するパターンを見てみようと思います。 生成に関するパターン Factory Methodパターン これは、オブジェクトを作るクラスを継承関係を使って・・・とめんどくさいことをしていますが、メソッドを変数に入れて扱うというデリゲートの仕組みがあるC#では、あえて生成メソッドのためだけにクラスをこしらえる必要はないと思ったりします。 ということで、以下のような感じになりました。 namespa
サルでもわかる 逆引きデザインパターン 第4章 逆引きカタログ その他 Nullオブジェクト
具体的な例 それではより具体的な例を見てみましょう。サンプルは商品の割引価格を計算するコードです。 割引価格には「会員の割引価格」「セール時の割引価格」「通常の割引価格」の3種類があります。 割引価格の種類を決定するのは、Mainクラス実行時のアプリケーション引数です。 Mainクラスは「java Main 価格 割引ロジック名(sale, member, 指定しないのいずれか)」の形式で実行します。 例えば「java Main 1000 member」で実行すると会員割引価格となり、「java Main 1000 sale」で実行するとセール時の割引価格となります。 「java Main 1000」と指定がない場合は、通常の割引価格になります。 各クラスの役割は次のようになります（図8～9）。 ◎DiscountLogic（リスト14） 割引計算のロジックのインタフェースです。各割引計算
Visitor pattern - Wikipedia
A visitor pattern is a software design pattern that separates the algorithm from the object structure. Because of this separation new operations can be added to existing object structures without modifying the structures. It is one way to follow the open/closed principle in object-oriented programming and software engineering. In essence, the visitor allows adding new virtual functions to a family
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Java におけるコード進化パターン - デザインパターン