CODE COMPLETE(上)

突っ込み入れてみるよ。
5.3.7 節 の「柔軟性」のところ。

Employee オブジェクトを LookupVacationBenefit() に渡す。

と書いてあります。

SomeObject.LookupVacationBenefit(anEmployee);

って事ですよね。自分なら

anEmployee.LookupVacationBenefit();

こう設計しますね。OOPL を使うならば。

さらに、

3つ目のモジュールで、Employee オブジェクトは持たないが、雇用日と職種を持つ

ってなっていますが、

new Employee(雇用日, 職種).LookupVacationBenefit();

ってするか、3つ目のモジュールに雇用日と職種を素で持たせるのが良くなくて、3つ目のモジュールは、Employee オブジェクトのインスタンスを保持すべきですね。

なので、

LookupVacationBenefit にEmployee オブジェクトを渡すよりも、雇用日, 職種 を渡すようにしたほうが柔軟性がある

とは自分は思いません。

SomeObject.LookupVacationBenefit(雇用日, 職種);

よりも、

anEmployee.LookupVacationBenefit();

のほうが良いでしょ? anEmployee がもし無いなら作れば良いんです。
実際は、雇用日と 職種だけでは、Employee のインスタンスを生成するのに不十分かも知れません。が、それはどこか他の設計がまずいので見直すべきでしょう。

Employee anEmployee = new Employee(雇用日, 職種, ...);
anEmployee.LookupVacationBenefit();

OOPL ならばこうしない?

LookupVacationBenefit() は、Employee オブジェクトを引数に受けるものと、雇用日と職種を受けるものと両方用意するというならまだわかります(引数が違う同名のメソッドは定義可能です)。しかし、本文を読む限りそのようには受け取れず、「雇用日と職種」を引数に受けるよう修正したほうが良いとしか読めません。果たしてその変更は柔軟性を高めるのでしょうか?

まあいろんな考え方があるので唯一の正解は無いですけども。自分は LookupVacationBenefit() の引数に雇用日と職種を渡すよう変更するという設計は好みません。