社内勉強会 - Pixel Pedals of TomakomaiMoose::RoleはJavaのInterfaceなんかじゃないの内容を社内勉強会でやったので、スライドだけ貼っておきます。 slideshareの貼り方ははてなブログでslideshareのプレゼンテーションflashを貼る方法で教わりました。
第3回 Moose::Role：役割単位のクラス分け | gihyo.jp
多重継承しないほうがよい場合 前回は多重継承を利用してクラスを拡張するときにありがちな問題と、そのひとつの解決策を見てきましたが、クラスにいくつかのメソッドを追加したいだけであれば、むしろ継承を利用しないほうがふさわしい場合もあります。 たとえば「コウモリ」というクラスを実装するとき、「乳を出す」というメソッドのために「ほ乳類」というクラスを、「空を飛ぶ」というメソッドのために「鳥類」というクラスを継承するのは――たしかにそれで当座の問題は解決するかもしれませんが――違和感が残ります。 use strict; use warnings; use Test::More tests => 4; package Mammal; sub new { bless {}, shift; } sub produce_milk { print "I can produce milk.\n"; } pa
Roleに基づくスタブライブラリ - 世界線航跡蔵
オブジェクトが他のオブジェクトと相互作用するにあたり、そのオブジェクトの機能の全体が必要になることは少ない。むしろ、オブジェクトの提供する特定のRoleのみが見えるべきである。そのRoleを提供することのみを契約すべきである。 MVCアーキテクチャではControllerはModelに対してオブザーバとして振る舞うし、Viewに対しては何らかのメッセージソースとして振る舞う。MVC風webフレームワークではControllerはViewに対して、表示すべきデータを供給する役割だし、一方でHTTPリクエストの消費者として振る舞う。 さて、ある種の静的型付け言語ではこのRoleをinterfaceという言語要素で表すことができる。そして、契約違反はコンパイルエラーとして検出することが可能だ。その言語の上のフレームワークが、適切にinterfaceで契約を結んでいるかは別として。 これをRuby
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
