タグ

デザインパターンに関するkikuchi1201のブックマーク (6)

  • 48. GoFデザインパターンとDI (前編) w/ twada | fukabori.fm

    話したネタ デザインパターンとは? ソフトウェアパターン 書籍: オブジェクト指向における再利用のためのデザインパターン Gang of Four 進研ゼミみたいなもの Composite パターン デザインパターン以外のソフトウェアパターンとは? アーキテクチャパターン、アンチパターン、コンカレンシーパターン AWSクラウドデザインパターン パターンにはフォーマットがある GoFのデザインパターンはいつ頃生まれたもの? GoFのデザインパターン登場時に、ソフトウェア業界では何が起きていたのか? Ruby 20 周年記念パーティーレポート ―― プログラミング初心者の運営スタッフが見た Ruby コミュニティ C、C++Perl、Smalltalk、Visual Basic の時代 デザインパターンには、どういうカテゴリがある? 生成・構造・振る舞い Javaのクラスライブラリにおけるデ

    48. GoFデザインパターンとDI (前編) w/ twada | fukabori.fm
  • Patterns of Enterprise Application Architecture - Martin Fowler's Bliki (ja)

    Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、パターンカタログの翻訳を行っています。 ※書籍の邦訳とは一切関係ありません。 PofEAAのパターンカタログから読始めるとよいでしょう。 パターンカタログの日語版 パターンカタログの英日対応表 上記のカタログでは書籍の訳語を踏襲していますが、各ページでは「できるだけ正しい」訳語を使うようにしています。邦訳版のパターン名に関する議論などは、JapanesePatternNamesを参照。 ページ一覧 アクティブレコード アプリケーションコントローラ 関連テーブルマッピング BBS パターンカタログ パターンカタログの比較表 パターンカタログ(日語) クラステーブル継承 クライアントセッションステート 粗粒度ロック 具象テーブル継承 データマッパー データ転送オブジェクト データベースセッションステート

  • 一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか?

    回答 (5件中の1件目) この質問にかなり先行して2015年、Quora(家)で投げかけられた質問として、 Why do some functional programmers criticize design patterns in OOP languages as a sign of language deficiency, while Monad is also a design pattern? なぜ、関数型プログラマらは、オブジェクト指向(OOP)言語のデザインパターンを、言語の欠陥の象徴だと批判するのでしょうか?モナドもデザインパターンじゃないんですか? があります。...

    一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか?
  • PHPによるデザインパターン入門 - 目次 - Do You PHP はてブロ

    このエントリは、Do You PHP?(www.doyouphp.jp)で公開していたコンテンツを移行/加筆/修正したものです。公開の経緯はこちらをどうぞ。 2006/11/23に株式会社秀和システムさんから発売された「PHPによるデザインパターン入門」(ISBN4-7980-1516-4)を執筆しました。 また、2009/09/14付けの絶版に伴い、Do You PHP?にて校正前の原稿テキストを公開していました。が、この度、Do You PHP?の閉鎖に伴い、はてダに移行しました。今回の移行で、校正完了間際の原稿に差し替えましたが、まだ誤字/脱字、説明不足の箇所もあるかも知れません。ご了承ください。 1章 デザインパターンの世界へようこそ デザインパターンって何? デザインパターンとは? オブジェクト指向 GoFパターン デザインパターンのメリット・デメリット デザインパターンを使うメ

    PHPによるデザインパターン入門 - 目次 - Do You PHP はてブロ
  • Railsで導入してよかったデザインパターンと各クラスの役割について - masato_hiのブログ

    3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as

    Railsで導入してよかったデザインパターンと各クラスの役割について - masato_hiのブログ
  • デザインパターンを読み解く

    ポリモーフィズム(サブクラスによる切り替え、抽象化) ここに分類されるのは、オブジェクト指向の第3原則、ポリモーフィズムを使用したパターンです。ポリモーフィズムを使用すると、動的に使用するクラスを切り替えることができます。<参照> 他に分類されているものでも、ポリモーフィズムが重要な位置を占めているものもありますが、ここではそれしか使われていないものを扱います。 ただデザインパターン全体を通して強調されているのは、インターフェースでプログラミングするということです。実装への依存をなくし、そうすることによって設計の骨組みを明らかにするのです。 Template 次のようなメソッドがあった場合に、処理Bのところを条件によって変えたい場合があるとします。 class Hogehoge { void doit() { ... 処理A ... ... 処理B ... ... 処理C ... } }

  • 1