タグ

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

  • 分散プログラミングモデルおよびデザインパターンの考察

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog 写真:アフロ データ&サイエンスソリューション統括部、データインフラ部、今野です。 早速ですが、今月開催の「Developers Summit 2016 (以下、デブサミ2016)」で当方が登壇する運びとなりました。気がつけば、前回の記事「分散システム処理モデルに関する動向について」から随分と日がたってしまいましたので、今回は、より広範囲な内容を整理してみたいと思います。 デブサミ2016の当方の講演テーマは「温故知新」です。今回は、このテーマにもつながる話題として、クラウド環境の代表的な分散プログラミングモデルやデザインパターンについて、一般的な考察をしてみたいと思います。 古典的なプログラミングモデルによる分類 まず最初に

    分散プログラミングモデルおよびデザインパターンの考察
  • Feature Request: m.prop().subscribe() · Issue #78 · MithrilJS/mithril.js

    hajimehoshi
    hajimehoshi 2016/02/05
    " I'm trying to avoid the observable pattern as much as possible"
  • アプリ開発と状態遷移の管理 - ninjinkun's diary

    このエントリーは読者としてスマートフォンアプリ開発者とWebフロントエンドエンジニアを想定して書いています。 CROSS2016に出るので、最近の自分の考えを整理しておく。 最近ReduxSwift実装であるReSwiftを使って開発している。使った感想なども最後の部分に書いたけれど、このエントリーの題はアプリの状態管理の話。 アプリは大きなシングルトン iOS、Android共にアプリを実装しようと思うと大抵シングルトンが必要になる。各ViewController内をまたがってデータを共有したいというユースケースが多いからだ。例えば ユーザーのログイン情報を集約するUserManager コンテンツへのいいね情報を集めるLikesManager ブックマーク情報を集めるBookmarkManager などなど。もちろんアプリの内容によってこれらの顔ぶれは違ってくると思うけれど、大抵U

    アプリ開発と状態遷移の管理 - ninjinkun's diary
  • デザインパターンを読み解く

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

  • GUIをツリーにする話(新篇) - ジンジャー研究室

    English 前置き この記事は以下の記事からの続きである。 GUIをツリーにする話(前篇) - ジンジャー研究室 GUIをツリーにする話(後篇) - ジンジャー研究室 前回の話をざっくりまとめると、 リストと追加ボタンを扱うコンポーネント 合計を表示するコンポーネント の2つがあった場合、モデルの受け渡しを不要にするために共有したい。 また、片方のViewによってModelが更新されたとき、もう片方のViewにもそれが反映されて欲しい。 「モデルを監視する」を定義通りに、Observerを用いて実装するのにBackbone.jsが適している。しかし、記述方法としてはAngularJSのdirectiveがおいしい。 <div ng-app="app"> <div ng-controller="Ctrl"> <list values="members"></list> <sum valu

    GUIをツリーにする話(新篇) - ジンジャー研究室
  • 読書会(アジャイルソフトウェア開発の奥義)第4回議事録

    読書会(アジャイルソフトウェア開発の奥義)第4回議事録 [ 戻る ] 2005年02月19日 土曜日 読書会議事録 出席者:(敬称略) 高橋(智) 高橋(徹) 遠藤 岩室 奥 久保 金井 原井 門脇 村山 吉村 丸山 吉 小棚木  根(記) 第11章 P163  依存正逆転の原則(DIP) 11.1 依存正逆転の法則から ■上位と下位の定義が不明 WhatとHowの関係とみていいのか? レイヤー設計のこ とか? ■依存とは何か? それがないとコンパイルできないという定義で良さそうだ。 クラスライブラリの考えで、良さそう。 ■Martin Fowlerの言うPOJOは、flamework非依存での話。 ■DIとは依存性をinterfaceのみに手中させる考え方らしい。 ■POJO(Plain Old Java Object) POJI(...Interface) もある、 ■POCO (

  • What the Flux? (On Flux, DDD, and CQRS)

    Flux is an application architecture designed by Facebook for their JavaScript applications. It was first introduced by Facebook in May 2014, and it has since garnered much interest in the JavaScript community. There are several implementations of Flux. Frameworks like Fluxxor keep to the original Facebook Flux pattern, but reduces the amount of boilerplate code. While other frameworks like Reflux

  • MVCの流れを簡単にまとめてみる - Qiita [キータ]

    理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア

    MVCの流れを簡単にまとめてみる - Qiita [キータ]
  • Fluxとはなんだったのか + misc at 2014 - saneyuki_s log

    はじめに VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita を読んでいる前提で話を進めます。 結局”Flux”なんだったのよ 詳細については過去に自分が覚え書きを書いたのでそっちを読んでいただけると良いと思うけど、あれは 「MVCの変形亜種に、オブザーバーパターンを乗せ、データを単一方向に流すことを規定した」ものに、Facebookが命名したものでしかない。極端に目新しいものでもない。その最大の功績はアーキテクチャそのものではなく、「試行錯誤を踏む中で誰もが一度はやっていたであろう似たようなことを上手く実践法則としてまとめた上で、共通認識としての名前をつけた」こと。概念に名前をつけて共有することで、事前説明が簡略化され、質的な問題に取り組む時間が増える。これをFacebookのブランド力でねじ伏せるように広めたことこそが重要かつ評価すべきポイン

    Fluxとはなんだったのか + misc at 2014 - saneyuki_s log
  • 開発効率アンチパターン

    11. #IGPFC • テンプレートを使いこなそう • 自分自身(チーム)の設計フレームワークを持とう • もっと先へ加速したくはないか、少年 • まとめ

    開発効率アンチパターン
  • IOS/Androidアプリの3つの大事な設計方針

    .NETラボ 勉強会 2015年04月の資料です。 Windowsフォーム開発に慣れきっている人がWPF開発に移行したときに、仕様の違いによりハマりやすい点を実体験も含めてお話しさせていただきました。 こちらのサイトで元のPPTXファイルをダウンロードしていただけます。 http://sonic.blue/it/129

    IOS/Androidアプリの3つの大事な設計方針
  • Fluxアーキテクチャの覚え書きを書いた - saneyuki_s log

    どこに書いたか忘れそうなので備忘でgist貼付ける Facebook提唱のFluxのメモ:http://facebook.github.io/react ...

    Fluxアーキテクチャの覚え書きを書いた - saneyuki_s log
  • 再考: GoF デザインパターン - Qiita

    投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代にカタログ化された 現代のプログラミングと合致しないものが多い 「オブジェクト指向における~」と断っている以上、OOPに絡める必要があった パターンのいくつかに「多態性を用いると便利」という蛇足がついている 挙げたパターンに根拠がない 「とりあえず、23個ほ

    再考: GoF デザインパターン - Qiita
  • AvalonからMVVM、そしてRxへ: GUIプログラミングの哲学の歴史

    MSテクノロジ知らんがな、とよしぞうに言われて、そういえばこの辺の話は外ではあまり聞かないな、と思ったので、ちょっと軽く振り返ってみる。 なお、Javaプログラマ向けに一部翻訳してるので、C# の実際とはちょっと違う。 かつて人々は、onclickでリクエストを発行しデータを取ってきて、その間はローディング中としてアイコンを回したりして、帰ってきたらアイコンを戻して取得したデータからtableを組み立てたりしていた。 このシーケンシャルな手続きプログラムは、非同期なGUIという物と大層相性が悪く、すぐにアイコンが回り続けたり途中で何か違う事をすると落ちたりといったバグを埋め込んでしまい、人々は悩んでいた。 GUIプログラムのバグはどこから来るのだろうか? それはページの動的な所から来る、という観察があった。 静的なhtmlはあまりバグらない。 一旦動く、という事が静的に確認されれば、それ以

    AvalonからMVVM、そしてRxへ: GUIプログラミングの哲学の歴史
  • Facebook: MVC Does Not Scale, Use Flux Instead [Updated]

    InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example

    Facebook: MVC Does Not Scale, Use Flux Instead [Updated]
  • Lifting State Up – React

    These docs are old and won’t be updated. Go to react.dev for the new React docs. These new documentation pages teach modern React and include live examples: Sharing State Between Components Often, several components need to reflect the same changing data. We recommend lifting the shared state up to their closest common ancestor. Let’s see how this works in action. In this section, we will create a

    Lifting State Up – React
  • 関数型言語を学ぶことは実務でどう役に立ったか - Rejasupoem

    関数型LT大会で「実社会の問題を解決する関数型言語」というタイトルで発表しました。 というのも、会社で「すごいHaskellたのしく学ぼう!」の輪読会をしていて、最初こそ10人以上の人が参加していたのだけど、章が進むごとにどんどん人が離脱していって、主催者としてはなんとか完走したいという思いがあったので、調べたのですが、 ヒアリングから、この二つの線がクロスしたときに、人は離脱するという知見が得られました。 ということで、Haskellに対して実用性を見出したいと思いながら半年を過ごしたのですが、実用的 = 仕事で使うということであれば、今の現場でHaskellに移行するのは現実的ではありません。 でも、Haskellには関数型言語のエッセンスが詰まっていて学びが多かったと思っていて、直接的には使っていないけど、概念として役立つことがあると思ったので、それを伝えるために今回文章に起こしまし

  • L&#39;eclat des jours(2013-10-25)

    _ WebMVCと設計パターン WebMVC(面倒なので以降はただのMVC。J2EEのMVCがSmalltalkのMVCと異なるMVCだということは既に10年以上の歴史があるのだから、今更どうでもよろしい)というのは、Transaction Script PatternとDomain Modelの間にまたがるスペクトラムだ。これがMVCの最大の特徴であり利点なのだが、なぜか、Transaction Script PatternとDomain Modelの両極端の声の大きい人が自分の視点を叫ぶ(実際に前者で声が大きい人はいない。彼らは沈黙のうちにコードを広める)。そこで混乱が生まれ、最悪のTransaction Script Pattern実装(貧血)と最悪のDomain Model実装(血 )が幅をきかせることになる。といっても、最悪のDomain Modelは普通は作れないのでそれほど

    L&#39;eclat des jours(2013-10-25)
  • Beyond MVC

    PHP Advent Calendar 2013 - 6日目 昨日は@fivestrさんのComposerを使った簡単Travis CI設定でした。 TL;DR オブジェクト指向/MVCでうまく捉えきれていなかったものは何なのか?MVCから続くソフトウェアアーキテクチャーの「その先」は何なのか?Reenskaug博士を知っていますか? WikipediaによればReenskaug博士は1930年生まれ。MVCという概念が世の中に送り出された論文『MODELS - VIEWS - CONTROLLERS (pdf)』は1979年ですから、49歳の時ということになります。1960年からソフトウェアを書き始め、1973年からオブジェクト指向でソフトウェアを開発しており、現在でも現役でソフトウェアの世界にいらっしゃいます(ex 2009年の講演)。「プログラマ歴42年 (* Clean Coder

    Beyond MVC
  • 雑把の UI アーキテクチャー史(MVCからMVVMへ) | プログラマーズ雑記帳

    Web の場合は View と Controller の違いははっきりしてます。 View は html ページとその作成を担当します。 CGI は アドレスとパラメーター(アドレスの ? の後など)を受け取り、処理を行います。 その受け取り部分が Controller です。 Model と View ではなく、なぜ MVC としたのでしょうか ? 『 GoF 』 では Controller を分ける利点をいくつか挙げられています。 キーボードの応答を変えたり、メニューからの呼び出しに変更するとき、表示方法を変更しなくていい。 入力イベントを無視するといったことをコントローラーのインスタンスの入れ替えで可能。 その他にも "View を入れ替えれば、 PC アプリ、 Web アプリでも使えるように" という理由もあります。 ちょっと無理そうな話ですが、例えば、 PC アプリが次のような