| 2024 / 11 «« ■ »» |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
meaning of mark :: 
nothing , 
comment
nothing , comment
Pageview
Online Status
Profile
hHandleName = Fe+;
某メーカ勤務の怪しい会社員。
40代に突入しても不惑の域に達しない。
某メーカ勤務の怪しい会社員。
40代に突入しても不惑の域に達しない。
Recent Diary
Recent Comments
RSS & Atom Feed
2006/08/24
抽象化注意報
[Fe+の千夜一夜]
夏休み前に買っておいた一冊。
アジャイルソフトウェア開発の奥義
OCP(Open-Close Principle)や、LSP(Liskov Substituion Principle)も参考になったけど、やはり参考になった（というより、最近失念していた）こととして、「抽象化の概念を初期実装段階であまり考慮する必要が無い」ってことですね。
デザパタで言うと、TempleteやFactoryに代表されるもの。
リファクタリングの結果や、反復開発で要求を落とし込む（ソフトウェア要求と実装の差異を極小にする行為）段階で、OCPを意識して行われるべきだと。
つまり、「どちらの要求方向に対する拡張にOpenにするのか」は単純な抽象化では実現できないってことですね。
本文では、複数の図形を扱う例として、「図形形状の拡張と、図形順列制御の拡張」を例に挙げて、OCPと抽象化の扱い方を説明しています。
これが結構絶妙だったりします。
コレを知っておくと、初期コードでは無駄な抽象化（Openにすべき拡張概念）を考えずに組めるので楽チンです。
最終的に拡張に対してOpenになればいいだけだしね。
●参考
デザインパターンの落とし穴
デザインパターンを読み解く
アジャイルソフトウェア開発の奥義
OCP(Open-Close Principle)や、LSP(Liskov Substituion Principle)も参考になったけど、やはり参考になった（というより、最近失念していた）こととして、「抽象化の概念を初期実装段階であまり考慮する必要が無い」ってことですね。
デザパタで言うと、TempleteやFactoryに代表されるもの。
リファクタリングの結果や、反復開発で要求を落とし込む（ソフトウェア要求と実装の差異を極小にする行為）段階で、OCPを意識して行われるべきだと。
つまり、「どちらの要求方向に対する拡張にOpenにするのか」は単純な抽象化では実現できないってことですね。
本文では、複数の図形を扱う例として、「図形形状の拡張と、図形順列制御の拡張」を例に挙げて、OCPと抽象化の扱い方を説明しています。
これが結構絶妙だったりします。
コレを知っておくと、初期コードでは無駄な抽象化（Openにすべき拡張概念）を考えずに組めるので楽チンです。
最終的に拡張に対してOpenになればいいだけだしね。
●参考
デザインパターンの落とし穴
デザインパターンを読み解く
posted at 2006/08/27 1:08:49
lastupdate at 2006/08/27 23:31:00
【修正】
Comments
Post your Comment
Menu
Category
Pageview Ranking
Search
Link
Amazon検索
