オブジェクト指向の度合い

あまりにオブジェクト指向を推し進めると全体のビジネスロジックが
見えづらくなる。しかし、ある程度オブジェクト指向にしなければ、
同じ変数にアクセスするメソッドを一つのクラスに集めることができない。

と思うんですけどどう思いますか？

例えば、
AA-BB-CC
と入れ子のデータがあれば、BB, CCにはアクセサを作って、
AAにビジネスロジックを書く。BB, CCにはユーティリティレベルの
メソッドのみを実装する。という感じ

質問者からの補足コメント

• 

  「ビジネスロジック」という用語は、そのアプリをコントロールするような処理(アプリケーション固有の処理)を指して使っています。
  ビジネスロジックを考えるとは、プログラムの実装を考えることと同義と思っています。

  No.1の回答に寄せられた補足コメントです。 補足日時：2016/04/16 20:45

• 

  >　AAにはAAとしての（＝BBとCCを個々に意識しない）データ操作のメソッドがあります。
  >BBにはAAのうちのBBとしての（＝CCを意識しない）データ操作のメソッドがあります。C
  >CにはCCのデータ操作のメソッドがあります。
  
  データ操作のメソッドだけをAA BB CCに書くのだとしたら、ビジネスロジックは
  AA BB CCに用意されたアクセサ、イテレータを使って他のクラス(AAでもBBでもCCでもない)が担うことになります。
  
  すると、それは手続き型プログラミングと同じ処理構成に近づきます。
  main関数から連なる大きなビジネスロジックの関数呼び出しの木構造ができます。
  オブジェクト指向としてのメリットはデータ操作メソッドくらいで、ほとんど
  手続き型と変わりません。
  
  勝手な解釈ですが、mainからAA等のクラスにビジネスロジックを分けて任せるのではと
  思ってました。

  No.2の回答に寄せられた補足コメントです。 補足日時：2016/04/16 21:00

No.4 ベストアンサー 回答者： tknakamuri 回答日時： 2016/04/17 09:42

言いたいことはわかります。

処理に必要な末端のクラスにまで
役割分担を細かく背負わせて、処理を拡散
させるのはよくない。

役割を明瞭に分割してコラボというのは
大原則だけど、末端の細かな実装には単純な
役割のみを負わせるべき。

例えば、集計値を蓄積するとか、単に値を
受け渡すとか。

そういう末端にまで頭を捻って無理に役割を与えすぎると
たいてい破綻します。

これはオブジェクト志向の度合いというより、
責任分坦の匙加減の問題です。オブジェクト志向と
対立する話じゃありません。

No.3 回答者： lv4u 回答日時： 2016/04/16 21:56

>>ビジネスロジックを考えるとは、プログラムの実装を考えることと同義と思っています。

ネットで「ビジネスロジック」を検索すると、いくつかの定義があるようですね。

A)ビジネスロジックとは、業務ソフトウェアの中で、具体的な業務で扱う様々な実体（商品、顧客、在庫など）を表現し、また、それらの関係や処理の方法、業務の流れなどをプログラムコードとして実装した部分。アプリケーション固有の処理やルールを記述したもの。


B)現場によって違いがある場合もある為、個人的な見解ですので予めご了承ください。
結論から言えば、「業務ロジック」と「ビジネスロジック」は同じものな場合もあるし、全く異なる場合もあります・・・。

C)「ビジネスロジックを分ける」の本質は
１．使い回しできるところとできないところを分離する
２．システムに変更が必要なときに見る必要があるところとないところを分離する


Ａの意味だと「実装」という単語があるので、質問者さんの考えに近い気がしますね。Ｂは中立（？）、Ｃの意見は、質問者さんと違いますね。この意味だと、ビジネスロジックが同じまま、実装が手続き型でもＯＫだし、オブジェクト指向言語であってもＯＫってことになります。
そして、私の回答は、Ｃの意味です。


まあ、ビジネスロジックという単語が何を意味するか？は別にして、質問者さんが例示したAA-BB-CCのプログラムのどこにビジネスロジックが埋め込まれるか（反映されるか）となれば、それはAAの部分がメインになると思います。
もちろん、ビジネスロジックの一部をBBにまかせるほうが良いこともあるかもしれませんし、場合によっては、CCにまで及ぶかもしれません。

ただ、ビジネスロジックは、現実のビジネスの流れを反映したものになっていると思います。
そして、ビジネスのやり方は、時間とともに変化していくものです。となれば、その変化の影響をうけるプログラムの部分は、極力小さくしたいはずです。

そうであれば、ビジネスのやり方が変わったとき、ロジック変更はAAのみとか、BBのみに影響するというように、影響が最小になる作りを選ぶということになると思います。

そして、それを実現する手法のひとつとして、オブジェクト指向があるけど、それだけでは力不足・時代遅れであり、メタ・プログラミングとか、ラムダ式とか、DSLといわれるドメイン特化言語などのプログラミング手法を使うのが最近の流行だと私は思っています。

No.2 回答者： zircon3 回答日時： 2016/04/16 20:05

何処かに処理手順をコントロールする部分は必要です。

データ（へのアクセス機能）とアプリケーションとしての処理手順を分離することがオブジェクト指向の目指すところでもあります。

ということで。。。

> AA-BB-CC
> と入れ子のデータがあれば、BB, CCにはアクセサを作って、
> AAにビジネスロジックを書く。BB, CCにはユーティリティレベルの
> メソッドのみを実装する。という感じ

　これは違います。
　ビジネスロジックはこの外です。
　AAにはAAとしての（＝BBとCCを個々に意識しない）データ操作のメソッドがあります。BBにはAAのうちのBBとしての（＝CCを意識しない）データ操作のメソッドがあります。CCにはCCのデータ操作のメソッドがあります。

No.1 回答者： lv4u 回答日時： 2016/04/16 18:58

全体のビジネスロジックを考えているときは、オブジェクト指向なんて意識する必要ないと思うのですけどね。

たとえば、リレーショナル・データベース（ＲＤＢ）を使うアプリの場合、データベース設計は、「概念モデル」「論理モデル」「物理モデル」と３つの段階で進めるのが基本です。
が、概念モデルを考えている時、ＲＤＢの実装上の制限なんて考慮しません。
この時点では、ビジネスに最も適したデータベースを考えるのが第一であり、「そんな設計では、ＲＤＢで実装できないから、そんな概念モデルするのはやめてくれ！」なんてことをプログラマがＳＥに申し入れたとしたら、「お前のようなプログラマは要らない！」なんていわれるかも？

ですから、全体のビジネスロジックを考えるときは、ビジネスロジックに集中し、プログラムの実装を考えるとき、オブジェクト指向を考慮した設計をすればいいだけだと思います。

「オブジェクト指向が○○だから、ビジネスロジックをそうするのはやめて欲しい！」っていう主張は、本末転倒だと思いますよ。