リンク元の議論とはちょっと方向が違うのですが、最近思っていることが書かれていたので：
データとそのデータを扱う処理をひとつのものとして扱うのがオブジェクト指向
というのが教科書に必ず書かれていますが、すでにこの考え方はdeprecatedじゃないかと。デザインパターンやDependency Injectionを書いていく際のクラス抽出というのは、こうじゃない気がするんですよね。だから教科書の言葉を疑うことから設計をはじめないといけない気がします。じゃあ何なのかと言われると分からないのですが...。教えてエライ人。
さらに、Rubyだと頭を使うので面白い。Interfaceという概念がなく（ていうか全てInterface）、moduleをどううまく活用するか。特異メソッドやaliasでなんとでもなるし。実装の共有とAPIの共有にわけて考えると、
Sub-Class Delegate Module 特異 実装の共有 × ○ ◎ △ APIの共有 Rubyならなんでもアリなので、考慮しなくてよい!?
うーん。
お久しぶりです。s/depricated/deprecated/
どもです。お恥ずかしい。スペルチェックに身が慣れてしまって...。tDiaryのpreview画面で、スペルチェックが働いてくれるとうれしい。
「データとそのデータ…」というのは、業務モデルの話をしているのではないかと思います。
だから、ロジック集であるデザインパターンを念頭に置くと、教科書が嘘に思えてしまうのではないでしょうか。
難しく考えないでデータと処理に分ける事が基本でいいような気がします。
構造化手法に戻ってどうしますか。>Saisse
でもパターンとかの本を見てると明らかにクラスの分割の方針が「データと処理」になっているように見えます。
プログラムの固まりから処理とデータを抜き出して役割と名前を付けたのがパターンという見方もできるのでは？ということです。
あぁ、デザインパターンを「データと処理の切り離し」と見るのですね? それは同意します。>Saisse
いまひとつイメージが湧きません。具体的にどのパターンがデータと処理を分割しているのかを教えていただけませんか?＞Saisse
例えばFactoryMethodは「クラスを生成する」という処理を切り離してFactoryとして、作成される対象をProductとしています。Productの方は処理だったり、データだったりするのですが。
それは「データ」と「処理」の分離とは関係なく、ProductからFactoryへ「インスタンスを生成する」という責務を移動しただけではないかしら。極端な話、Productには何ひとつデータを持たなくてもFactoryMethodパターンとしては成立しますし。デザインパターンが分割しているのは「データと処理」ではなく「責務」だと思うなあ。
確かに「債務」という見方は正しいのですが、「債務」って何？とか、何故に債務を分ける必要があるのか？って事を考えていくと、「データと処理」に行き着いてしまうのです(長くなるのでProcessは省略します)。あくまでも一つの「見方」ですし、このくらい単純化しても良いんでないかな？と。
うー、債務じゃなく責務でつ。<br>ツッコミ欄で議論もアレなのでこれで最後。個人的には「データと処理」の置き場所が「クラスの責務」に行き着くと考えてます。Saisseさんとは逆の流れですかね?(このへん、思いつきで書いてますが。)<br>「データと処理」へと行き着くプロセスは、後日Saisseさんのサイトででも解説していただけたらうれしいです。