十分性，完全性，プリミティブ性

SWEBOK 2004 の設計の章で次の基本原理が挙がっていました．

• 抽象化(Abstraction)
• 相互結合と凝集強度(Coupling and cohesion)
• 分割とモジュール化(Decomposition and modularization)
• カプセル化・情報隠蔽(Encapsulation/information hiding)
• インタフェースと実現の分離(Separation of interface and implementation)
• 十分性，完全性，および基本性(Sufficiency, completeness and primitiveness) 

このうち，最後の十分性，完全性，基本性(プリミティブ性)について原典をあたってみました．SWEBOK 2004 によると [Bus96] 第6章と [Lis01] 第5章でした．このうち [Bus96]は既に持っていたので参照しましたが，[Booch90] を引用していました．


[Booch90] には十分性，完全性，プリミティブ性について下記のように書いていました(改段落は僕が入れました)．

By sufficient, we mean that the class or module captures enough characteristics of the abstraction to permit meaningful and efficient interaction. To do otherwise renders the component useless. For example, if we are designing the class Set, it is wise to include an operation that removes an item from the set, but our wisdom is futile if we neglect an operation that adds an item. In practice, violations of this characteristic are detected very early; such shortcomings rise up almost every time we build a client that must use this abstraction.

By complete, we mean that the interface of the class or module captures all of the meaningful characteristics of the abstraction. Whereas sufficiency implies a minimal interface, a complete interface is one that covers all aspects of the abstraction. A complete class or module is thus one whose interface is general enough to be commonly usable to any client. Completeness is a subjective matter, and it can be overdone.

Providing all meaningful operations for a particular abstraction overwhelms the user and is generally unnecessary, since many high-level operations can be composed from low-level ones. For this reason, we also suggest that classes and modules be primitive. Primitive operations are those that can be efficiently implemented only if given access to the underlying representation of the abstraction. Thus, adding an item to a set is primitive, because to implement this operation Add, the underlying representation must be visible. On the other hand, an operation adding four items to a set is not primitive, since this operation can be implemented just as efficiently upon the more primitive Add operation, without having access to the underlying representation. Of course, efficiency is also a subjective measure. An operation is indisputably primitive if we can implement it only through access to the underlying representation. An operation that could be implemented on top of existing primitive operations, but at the cost of significantly more computational resources, is also a candidate for inclusion as a primitive operation.

--- Grady Booch: Object Oriented Design with Application

僕が訳してみました．突っ込み歓迎．

十分であるとは，そのクラスやモジュールが意味のある効率的な相互作用をするのに十分な抽象化の特性を捉えていることを意味する．十分でなければ部品が役に立たなくなる．たとえばもし Set (集合)クラスを設計しているときに，集合から要素を削除する操作を加えることは賢明であるが，もし要素を追加する操作を無視してしまうと役に立たなくなる．実際には十分性に反することは早期に検出できる．そのような欠点はたいていこの抽象化を使う顧客から指摘される．

完全であるとは，そのクラスやモジュールのインタフェースがその抽象化の全ての意味のある特性を捉えていることを意味する．十分性が最小のインタフェースを意味するのに対し，完全なインタフェースはその抽象化の全ての観点をカバーする．その結果，完全なクラスやモジュールのインタフェースはあらゆる顧客が共通的に利用できるくらい十分一般的である．完全性は主観的な事柄であり，やりすぎになることもある．

多くのハイレベルな操作はローレベルな操作から構成することができるので， ある特定の抽象化に対して全ての意味のある操作を提供することは，ユーザーを困惑させ，一般には不必要である．この理由からクラスやモジュールがプリミティブであるということが導かれる．プリミティブな操作とは，その抽象化の基礎となる表現形式へのアクセスが与えられたときのみに，その操作が効率的に実装できることを意味する．その結果，集合に要素を加えることはプリミティブである．なぜならば，この操作 Add (追加)を実装することにより，その基礎となる操作は明らかになるからである．一方，集合に4つの要素を加える操作はプリミティブではない．なぜならば，この操作はよりプリミティブな操作 Add によって，基礎となる表現形式に対するアクセスをすることなく，効率的に実装できるからである．もちろん，効率性も主観的な尺度である．ある操作を基礎となる表現形式へのアクセスを通してのみ実装できるとき，その操作は議論の余地なくプリミティブである．あらゆる操作は，既存の最上位のプリミティブな操作で実装できるが，より多くの計算資源を犠牲にしてプリミティブな操作として包含する候補にもなる．

[Booch90] Grady Booch. Object Oriented Analysis and Design with Applications. Benjamin-Cummings Publishing Company, Subs of Addison Wesley Longman, Inc.
  

[SWEBOK2004]  英語版 

[Bus96] F. Buschmann et al., Pattern-Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996. 

[Lis01] B. Liskov and J. Guttag, Program Development in Java: Abstraction, Specification, and Object-Oriented Design, Addison-Wesley, 2001.