【デザインパターン】コマンドパターン - dorivenの日記
リファクタリングがまだ中途半端なのですが、5月中までに結果を出さないと行けないので頑張ってやってます。 リファクタリングとは名ばかりの完全なコードの書き直しなのですが、まだまだ自分としては納得行ってないでの時間があれば続けたいんです。 最近気づいたんですけど、小さなコードのリファクタリングはよくやってるのですが、大きなコードのリファクタリングって大変で、自分はかなり苦手、というより慣れていないな、と実感しています。 今まで散りばめられていた様々な機能を分離したりで、勢いだけで書けないんで気持ちよさも最高潮ではないです。 そういえば、さっき見たらコードがコメントとテストコード込みで3000行くらい行ってました。 いつの間にこんなに書いたんだって話しですね。まだまだ増える予定だし。 そして、現在恒例の計算部でバグが出て死にそうです。デスマ確定です。 早くバグ滅っしたい。 プロジェクトメンバーは
コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ - kakakakakku blog
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
Is Dependency Injection Replacing the Factory Patterns?
Is Dependency Injection Replacing the Factory Patterns? Dependency Injection (DI) has been a hot topic since at least 2003 and onwards. Lots of dependency injection frameworks have appeared (including my own Butterfly DI Container), and lots of forums and blogs has discussed the technique. Yet I still experience big enterprise software development departments, who have not yet embraced the idea. I
storklab.com - このウェブサイトは販売用です！ - storklab stork lab リソースおよび情報
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.
Seleniumを使ったWeb UI自動テストシステムの構築でやったことまとめ - うなの日記
Seleniumを使ったWeb UIの自動テストシステムを作ったので、やったこと・感想などをまとめてみます。 テスト対象 テスト対象は、AJAXなWebアプリです。 サーバーはREST APIを提供するのみで、UIは全てJavaScriptという構成。 サポートブラウザはIE7以降,Firefox3.6以降。(特定の組織内で使うものなので、Operaなどは未サポートです。) 使用したSelenium 2.x 系列を使いました。 WebDriverと統合されたあとのやつです。 言語はJavaを使用。 テストの目的 以下を目的としました。 機能追加/不具合改修でのデグレード防止 機能追加や不具合改修に伴う動作不正を検出し、デグレードを未然に防止する。 動作確認コストの削減による開発効率の向上 ブラウザごとの動作確認を自動テストを利用して行うことで、機能実装時の確認工数を減らす。 リリース前のリ
Laravel.IO A Use-Case Architecture
A simple architecture is perfect for a simple application. But, as the application grows in its complexity, the architecture must become more complex in order to prevent it from becoming unmaintainable. In this talk we discuss some ideas for simplifying complex code bases. We also discuss the important distinctions between presentation, service, and domain layers and strategies for separating high
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
Strategyパターンを用いた実装について
Strategyパターンを用いた実装について 現在Javaを勉強しており、 Strategyパターンを用いた以下の実装を考えています。 public class UseStrategy { private Strategy strategy; public void doSomthing(int num) { switch (num) { case 0: strategy = new AlphaStrategy(); break; case 1: strategy = new BetaStrategy(); break; case 2: strategy = new GammaStrategy(); break; } // 変数strategyを用いて処理を続行していく // ... } private interface Strategy { public abstract void m
PHPerのMVCの一体どこが間違っていたのか - MugeSoの日記
メリークリスマス！ PHP Advent Calendarもいよいよ24日目に突入です。 昨日はxhprofについてでしたね。僕もパフォーマンスチューニングの際に使っています。手軽に利用できるのでお勧めです。 さて、このエントリーでは表題の通りMVCについて書かせていただきます。これは、PHPカンファレンス2012&WordCamp Tokyo2012合同LT大会で発表した「やはりお前らのMVCは間違っている」で煽るだけだったこの問題をきちんと解説するものです。 この発表資料を公開するとPHPの枠を超えて広く閲覧いただき*1、また多くの方から突っ込みを戴きました。「LTだから」と言って逃げていた回答をして、気持ち新たに新年を迎えようと思います。 MVCとはなんなのか 間違いを指摘する前にMVCがそもそもどういうアーキテクチャであるのかを確認しなければいけません。 MVCは1970年代にパロ
サルでもわかる 逆引きデザインパターン 第4章 逆引きカタログ その他 ユーティリティークラス
イントロダクション ユーティリティクラスはデザインパターンではありませんが、良く使われる基本的な定石なのであえてここでご紹介いたします。 ユーティリティクラスは、staticな共通の処理のメソッドを集めたクラスです。 同じ処理が2箇所以上で出てきた場合は、ユーティリティクラスにまとめることができる可能性があります。 ユーティリティクラスを使うと共通処理を1箇所にまとめることができますので、再利用性の向上ばかりでなく、あとから修正が発生してもユーティリティクラスの修正だけですみ、保守性が向上するというメリットがあります。
DAOパターンのデメリットを補う「DataAccessMethodパターン」
DAOパターンは、企業向けシステム開発で利用される非常に優れたデザインパターンですが、多くのクラスやインターフェイスを定義する必要があるというデメリットがあります。そこで本稿では、GoFのTemplateMethodパターンをベースしたDataAccessMethodパターンを紹介します。これを用いると、通常のDAOパターンに比べてクラス数が激減します。 はじめに CJ2EEのDataAccessObjectパターンは、企業向けシステム開発で利用される非常に優れたデザインパターンです。これを利用することにより、柔軟なシステムを構築することが可能となります。有名なパターンなので、多くの方はこのパターンを使った設計／開発に携わった経験があるのではないかと思います。 しかし、DataAccessObjectパターンを使った開発は多くのクラスやインターフェイスを定義する必要があります。これは、Da
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Software Design Patterns in Laravel by Phill Sparks