構造化プログラミングを突き詰めることでできてきたモジュール概念は、機能に対応したトップダウンのモジュール構造を特徴とします。頂点に機能に対応したエントリーを置いて、そこからピラミッド構造（逆さの木構造）にサブモジュール分解された全体的な構造を持ちます。
上の図の場合、モジュールAというとサブモジュールであるモジュールB～Eを含みます。
モジュールCと言うとモジュールDとモジュールEを含ます。
そして「モジュールAは機能Aを実現するモジュール」といったようにモジュール構造が作られるわけです。
例えばモジュール概念でもってパソコンの電源装置を見た場合、電源装置は電源モジュールと言えるでしょう。さらに電源装置内の制御モジュールというサブモジュールというものも考えられます。ところで電源装置から、その制御モジュールを抜いたものがあったとしたら、それを指して電源モジュールとは言いません。あくまでも制御モジュール込みで電源モジュールと言います。
これに対しオブジェクト指向プログラミングにおける機能の実現のためのオブジェクト群の構造は、上記構造化プログラミングのモジュール概念には沿いません。最近の言い方をすれば、そもそもオブジェクトは機能を示さず責務を果たすだけです。それぞれのオブジェクト同士の間でのやり取りと、その責務の果し合いの結果としてある機能が実現されるだけという考え方です。
このためオブジェクト指向に対しては、その下位のサブモジュールも込みでモジュールと呼ぶ構造化プログラミング的なモジュール概念と異なり、オブジェクト一つひとつをばらばらに捕らえるユニット概念が適用されます。
モジュール概念は上意下達のカースケード構造に対し、オブジェクト指向のユニット概念は相互作用による対等な関係の構造と言えます。もっとも相互作用の部分を「メッセージセンディングとレスポンス」ととらえず「呼び出しと戻り値」的にとらえてしまうと相互作用というよりは発注・受注的な上下関係の概念に適用されてしまい、結局単にややこしい上下関係になってしまうことがありますが（ぐるっと回って元請けが下請けになってしまった構造になってしまったりする：それは通常よろしくないとして避けますが、最初に作った構造としてそういうものが出来てしまったりしがち）。
ちなみに機能分割によるモジュール構造を禁欲的に行うと、モジュールの再利用性は低下します。上（親モジュール）から与えられた機能以外は許されないとしたら共通機能括り以外ではモジュールは構成できないので、モジュールにほんのちょっと機能冗長性などがれば他の機能系統からも容易に利用出来そうな場合でも、ある系統にとって余計な機能はその系統のモジュールに入っている「べきではない」という禁欲性によってその冗長性は排他されるためです。
ここの捉え方がゆるいのがオブジェクト指向とも言えるかもしれません。そのためにオブジェクト（ユニット）の再利用性、流用性は高いと言えるかもしれませんが、逆にそういうユニットをデザインする立場でみれば、その冗長性が「なんとなく」に繋がるために、デザインのセンスが求められてしまいがちです。デザインプロセスの初期から、判断基準が機能分割に比べ全体的で多様な視点からのバランスなどに、より強く依拠してくるためだと思います。
結果として、なんとなく使いづらく、作りづらく、実行効率もいまいちな全体構造であるけれど、なんかとりあえず動くというものが出来やすいかもしれません。というかそういうものを作りやすい。それを活かすなら、適当に素早くでっち上げた後にブラッシュアップの作業をより積極行うような開発プロセスを適用するといったところでしょう。
モジュールとユニットの概念について補足しておくと、ユニットは数学の集合的な概念です。
集合Aの部分集合Bがあったとして、A-B（Aから部分集合Bを除いたもの）は集合ですが、同様にユニットAがサブユニットにBを持つとしたばあいにユニットAからユニットBを除いた部分はユニットと言えます。
これに対しモジュールAとそのサブモジュールBがあった場合、モジュールAからモジュールBを除いた残りの部分はモジュールと言えるか？というと言えません。
ユニットとモジュールの違いは、多分そこにしか無いのではないか・・・その結果、モジュールを設計するか、ユニットを設計するか、という作業の違いは大きいのですが。