Hook::LexWrap - Lexically scoped subroutine wrappers - metacpan.org
NAME Hook::LexWrap - Lexically scoped subroutine wrappers VERSION version 0.26 SYNOPSIS use Hook::LexWrap; sub doit { print "[doit:", caller, "]"; return {my=>"data"} } SCOPED: { wrap doit => pre => sub { print "[pre1: @_]\n" }, post => sub { print "[post1:@_]\n"; $_[1]=9; }; my $temporarily = wrap doit => post => sub { print "[post2:@_]\n" }, pre => sub { print "[pre2: @_]\n "}; @args = (1,2,3);
デザインパターンの自動化
.NETで簡単な例を見てみましょう。 public Person : INotifyPropertyChanged { string firstName, lastName; public event NotifyPropertyChangedEventHandler PropertyChanged; protected void OnPropertyChanged(string propertyName) { if ( this.PropertyChanged != null ) { this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } public string FirstName { get { return this.firstName; } set { this.firstName
[ThinkIT] DIxAOPコンテナ「Seasar2とSpring」 第5回：AOPとは何か (1/4)
AOPとはアスペクト指向に基づいたプログラミングのことです。しかし「アスペクト指向」や「それに基づいたプログラミング」とは何でしょうか。 今までにAOPについて様々な文献を読んでみたけれど、よく理解できなかったという方もいらっしゃるのではないでしょうか。何を隠そう、筆者も最初はよく理解できませんでした。 でも、それもそのはず、AOPを解説する人の多くは、アスペクト指向の思想や未来を含めて語っているからです。読者の多くは思想や未来はいいから、今の開発現場にAOPを取り入れると何ができるのか、取り入れると何がよいのかなどを知りたいのだと思います。今回はなるべく思想や哲学を除外した形でAOPの疑問に応えていきます（注1）。 ※注1： 本連載ではアスペクト指向について用語も含め意訳して記述しています。アスペクト指向について正しく学びたい方は「アスペクト指向入門 千葉滋著 技術評論社」を是非お読みく
第3回 attributeを拡張してpluginに変化を加える | gihyo.jp
今回のテーマ 前回は、Perlのattributeという仕組みを解説しました。今回は、さらにattributeの実戦的な利用方法として、(Perlとしては実験的な実装という扱いですが)パッケージ固有のattribute実装の方法と、Class::Component::Attributeを拡張してplugin作りを便利にする方法を取り上げます。 サンプルアプリケーション 本連載では、プラガブルなモジュールを作製するという事を考えて、Gopperという実際に実行可能なサンプルアプリケーションを元に解説を行ないます。GopperはCodeRepos上のsvnリポジトリに置いてあるので各自checkoutしてください。 svn co -r 659 http://svn.coderepos.org/share/lang/perl/Gopper/trunk Gopper パッケージ固有のattribu
アスペクト指向ソフトウェア開発とそのツール
情報処理 45巻1号、pp.28-33（平成16年1月号) 特集：モデリングとツールを駆使したこれからのソフトウェア開発技法 〜モデル駆動開発手法を中心として〜 「アスペクト指向ソフトウェア開発とそのツール」 千葉 滋 東京工業大学・大学院情報理工学研究科 オブジェクト指向は理想論？ モデル駆動による開発手法では、まずはじめにモデリングありき、である。開発したいシステムをうまくモデル化できなければ、その先へ進めない。 一般に、モデリングはオブジェクト指向でおこなわれる。しかし、近年の研究により、オブジェクト指向では、必ずしも全てのシステムをうまくモデリングできないことが指摘されるようになってきた。 非常に直感的に説明すると、オブジェクト指向ではシステムを全体から部分へ階層的に分割する。システム全体は、いくつかのコンポーネントからなり、コンポーネントは、いくつかのサブコンポーネントからなり、
SpringにおけるDIとAOPの基本メモ - oknknicの日記
基本的な使い方ベースのメモ。選択肢の詳細は参考文献に詳しくあり。 DI 準備 ApplicationContext.xml（設定ファイル） 各beanの定義：クラス名、インスタンス名、フィールド値設定、など 利用 ApplicationContextのインスタンス取得(※設定ファイル指定。複数ファイル可能) インスタンス名指定でbeanの取得 AOP 準備(ApplicationContext.xml) Adviseを表現するBean 織り込むAdvise: org.aopalliance.intercept.MethodInterceptorを実装したクラス PointCutを表現するBean 正規表現で指定するPointCutとAdvice指定: org.springframework.aop.support.RegexpMethodPointcutAdvisor Weavingを表現
subtest と Hook::LexWrap を使って xUnit みたいな setUp, tearDown をする - tsucchi’s diary(元はてなダイアリー)
発見したのは結構前なのですが、twitter でつぶやいても(これとかこれ)、あんまり(っていうか全く)反響なかったのでこっちにも書いておきます。 Perl でテストを書いているときに、xUnit の setUp/tearDown*1を使いたい場合、Test::Classを使ってテストを書いて、setup, teardown を使うのが一般的かな、と思います。こんな感じね。 #!/usr/bin/perl use strict; use warnings; use Test::Class; MyTest->runtests(); package MyTest; use parent qw(Test::Class); use Test::More; sub set_up :Test(setup) { diag("setup"); } sub tear_down :Test(teardown)
- Excel VBA - Decorator パターンモデル
1999/08/27 更新 石井 勝 概要 ここでは，Decorator パターンモデルという Excel プログラミングに関するアーキテクチャを解説します．これは，Decorator パターンをアーキテクチャレベルにまで拡張したモデルで，継承が使えない VB プログラミングで威力を発揮すると思います．まだ実験段階なので，このモデルが実用化できるかは今後の課題です． Excel プログラミングとは？ Excel のプログラミングを一言で表すと，VBA プログラミングで Excel を拡張する，ということです．オブジェクト指向の立場で拡張といえば，継承ですね．したがって次のように任意の ExcelObject クラスを継承してプログラミングできればいいですね： 例えば Worksheet クラスから MyWorksheet クラスを継承すればいいわけです．そうすると望みのカスタマイズされたワ
疎結合がソフトウェア開発を変える（1）
図1●オブジェクト指向の問題点を解決する オブジェクト指向技術が浸透するにつれ，その問題点が明らかになってきた。これを解決するキーワードが「疎」である。 図2●部品化のメリット システムを分割してうまく部品化できれば，さまざまなメリットが生まれる。中でも重要なものは，同じ部品を他のシステムで再利用できること，変更を加えたときに影響が及ぶ範囲を部品内に限定できること，部品を別のものに入れ替えることでシステムの変更や拡張が容易になること，である。 オブジェクト指向言語の考え方が登場してから30年余。オブジェクト指向は，ソフトウェア開発の現場にようやく定着してきた＊1。システム・インテグレーションの現場では「案件のほぼすべてが，オブジェクト指向開発」（日本ユニシス・ソリューション AD CoE コンピテンスセンタ統括部長の川口真一氏）。「システムを発注する側が，設計情報をUML（Unified
プログラム間にボタンを掛ける「DI/AOP」（前編）
「DI（Dependency Injection）」および「AOP（Aspect Oriented Programming）」と呼ばれる技術が注目を集めている。これらはオブジェクト指向プログラミングにおけるプログラムの単位であるクラスを，互いに結び付ける新たな技術である。システムへの機能変更ニーズが高くなり，さらに開発期間が短くなっている開発の現場において，開発の効率化や品質向上を実現する新たな手段として期待されている。まずはオブジェクト指向プログラミングにおける課題を明らかにし，DIやAOPがそれらをどう解決できるのかを見よう。 DIでクラスを容易に付け外す オブジェクト指向プログラミングの一つ目の課題として，「変更時にクラスの修正が必要になる」ことがある。そもそも，オブジェクト指向で開発したプログラムは，オブジェクト指向ではないプログラムと比べ，機能の削除や変更が容易であることが特徴だ
僕が考えるAOPの適用ポリシー
「 Javaナイトセミナー(Vol.3)」で宿題(?)だった「AOPの適用」について，僕なりの意見を以下に述べようと思う。 AOPはトランザクションやロギング，ベースとなる機構で必要な前処理などを適用することが代表例なのは揺るぎのない事実だろう。そして，AOPのこれらの処理に対する適用は，プログラマからテクニカルで毎度毎度のお決まりコーディングを削減することができ，さらに継承やTemplateパターンなどを駆使することなく前処理を実行できるため，対象のクラスを汚す必要がない（何らかのクラスを継承しなくて済むなど）という利点をもたらしてくれる。 しかし，業務的に必要な前処理や共通的な処理の実行にAOPを使用すると，本来業務処理をコーディングするプログラマはAOPに関する知識を必要としなくて済むはずなのに，業務処理の記述に比較的難解な技術となるAOPを覚えてもらうことになる。敷居が高くなるだけ
DIって本当に必要? - ひがやすを技術ブログ
DIって本当に必要?たまにそう思うときがあります。DIによって開発は本当に楽になったのか。 DIのメリットでよく語られることとして、インターフェースと実装を分離し、機能の利用者側はインターフェースを通じて機能を利用することで、実装に直接依存しなくなり、後で実装を変更しても影響を受けなくなるということがあります。 実際後から、実装クラスを変更するということはめったにないので、よくあるのは、テストのために実装クラスをモックに変えることです。 でも、別にそれだけならDIContainerなんていりません。たとえば、次のようにServiceクラスに直接依存したClientがあるとします。 class Client { Service service = new Service(); void setService(Service service) { this.service = service;
Log4J徹底解説～アスペクトはお好き？
目次 ダウンロードなど トレースログとAOP アノテーションと連携する！ トレースログ埋め込みツールの仕様 トレースログ埋め込みツールの実装 変数を監視する 変数監視プログラムの実装解説 ダウンロードなど これは「ロガーの使い方」に関する応用編である。アスペクト指向の考え方の下に、Javassist を使って、 トレースログを埋め込むツール jp.or.nurs.sug.javassist.AddTraceLog 変数を監視するツール jp.or.nurs.sug.javassist.WatchField を作る。これらのソース及びライブラリは、以下のリンクから入手できる（ドキュメント付き）。 ログツールのダウンロード ただし、Javassist ライブラリ及びログに使う Log4j などのロガーは同梱されていおない。各自入手のうえ、解凍後の lib ディレクトリにそれを入れること。Jav
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.csg.ci.i.u-tokyo.ac.jp/projects/bugdel/
IBM Developer