┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.07 2003/07/30
■ I N D E X
┃
┣【キーワード】知ってるようで分からないビジネスワード勉強会「ＥＲＰ」
┗【プログラミング】ソフトウェア原則[1] OCP(Open-Close Principle)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【キーワード】知ってるようで分からないビジネスワード勉強会「ＥＲＰ」
皆様お久しぶりです。Hiroshiです。
初回の「ＣＲＭ」に続き、今回は「ＥＲＰ」についてお話したいと思います。
ＥＲＰとはEnterprise Resource Planningの略で、欧米から普及し日本でも
注目が集まっている「パッケージソフトウェア」です。受注、部品購買、生産、
製造、配送、販売、会計という企業における一連の業務の流れを扱う全社的な
業務パッケージで、特に、業務と会計機能（財務会計、管理会計）との連携が
大きな特長となっています。
例えば営業部門では、在庫や物流など注文に関連する各部門のデータを同時に
把握できるため、今までよりも迅速・正確な対応が可能になり、お客様への納
期回答時間を大幅に短縮することができます。
さらに業務と会計機能が連携しているために、基幹業務の諸情報に結びつい
た財務会計、管理会計の情報は、会社の経営資源をどのように有効に配分して
いくかという計画への発展に役立てることができます。
しかしＥＲＰはパッケージソフトであるために多くのメリット、デメリット
を含んでいます。メリットとして低コスト、比較的短期間なシステム構築、バー
ジョンアップなどがあげられます。
しかし、パッケージの操作方法を新たに勉強していく手間とメリットが見合
わなかったり、その企業の特有の業務プロセス（ノウハウ、企業の強み）が失
われてしまったりということがあります。
ＥＲＰの特性をよく理解して、パッケージを自社の業務プロセスに修正、開
発をして部分最適を図るか、ＥＲＰを戦略的システムとして捉えて自社の業務
プロセスをＥＲＰに乗せて全体最適を行っていくかが導入成功の鍵になるので
はないでしょうか。 (Hiroshi)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】ソフトウェア原則[1] OCP(Open-Close Principle)
今回から、「ソフトウェア原則」シリーズをはじめたいと思います。
前回の書評『オブジェクト指向入門』の中で、OCP"Open-Close Principle"とし
て、
「ソフトウェアモジュールは、変更に対して閉じており、拡張に対して開いて
いるべき」
を紹介しました。第1回目は、このOCP からです。次のC言語コードを見てどう
思いますか？
[コード1]
----------------------------------------------------------------------
typedef struct { int x, y; } Point;
typedef struct { Point p1, p2; } Line;
typedef enum { LINE, POINT } Kind;
typedef union { Point* point; Line* line; } ShapeUnion;
typedef struct {
Kind kind;
ShapeUnion of;
} Shape;
void draw(Shape* shape) {
switch(shape->kind) {
case LINE:
/* draw line (shape->of->line.p1 ---- shape->of->line.p2) */
break;
case POINT:
/* draw point (shape->of->point)*/
break;
}
}
---------------------------------------------------------------------
これは、私が15年前に書いたコードです。なかなかイケてるでしょ？
でも、Kindとして新たに CIRCLE を追加したとき、この draw 関数を修正し、
case CIRCLE を追加しなければならいのです。
では、どうするの？ C++ では、
［コード2］
----------------------------------------------------------------------
class Shape {
public:
virtual void draw() = 0;
};
class Point : public Shape {
int x, y;
public:
void draw() { /* draw point (x,y) */ }
};
class Line : public Shape {
Point p1, p2;
public:
void draw() { /* draw line p1-p2 */ }
};
----------------------------------------------------------------------
と書くことができます。このようにすると、Circle の追加は、「既存のプログ
ラムを全く変更せずに」（再コンパイルさえも！）できるのです。これが、
CloseしているプログラムをOpenにするというオブジェクト指向プログラミング
の1つの真骨頂なのです。修正の論理を、追加の論理に変換している、といえま
す。
ちなみに、オブジェクト指向プログラミングでは、構造化プログラミングで
goto が悪だったように、switch 分岐は悪と言われています。
（2箇所以上同じ分岐がある場合）。
後日談。
現在では、『リファクタリング』という再設計技術が注目されるようになり、
コード1をコード2に再設計することを、Replace Conditional With Polymorphism
(多態による条件分岐の置き換え)と呼んでいます。また、switch文が必ずしも
悪という訳ではなく、同じパターンの switch が繰り返されることが悪だ、と
いう解釈になっています。(Once and Only Onceの原則)
（平鍋）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
東京はいつまでたっても涼しくて、梅雨があけません。
XPアンギャ東京編当日まで1週間を切りました。懇親会会場の手配などをしなが
らふと思い出しました。なぜ、XPアンギャ第一弾に東京がなかったのか。
その理由は、ご当地の旨いものがなかったからです(笑)
なんて言うと、講師陣に怒られるのですが、1割くらいはホントです(笑)。
XPアンギャ東京編ですが、まだ申し込み受け付け可能です。
1日目のみ、2日目のみの参加も受け付けています。懇親会のみの参加も可能で
す。日程的に諦めていた方も、コメントに一言添えて、是非お申し込みくださ
い。（いりさ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/mlmagazine_help.html
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/mlmagazine.html
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.