データクラスがコードのにおいと見なされるのはなぜですか？
This 記事は、データクラスは「コードのにおい」であると主張しています。理由：
新しく作成されたクラスに含まれているパブリックフィールドがほんのわずかである場合（そして、ほんの一握りのゲッター/セッターでさえ）は、これは正常なことです。しかし、オブジェクトの本当の力は、データの動作タイプや操作を含めることができるということです。
オブジェクトにデータのみが含まれているのはなぜ間違っているのですか？クラスの中心的な責任がデータを表すことである場合、データを操作するメソッドを追加しないと単一の責任の原則？
純粋なデータオブジェクトを持つことには何の問題もありません。この作品の作者は率直に言って、自分が何について話しているのかわかりません。
このような考え方は、「真のOO」がプログラミングの最良の方法であり、「真のOO」はデータと機能性が混在する「リッチデータモデル」に関するすべてであるという古くて失敗した考えに由来しています。
現実は、特にマルチスレッドソリューションのこの世界では、実際にはその逆が真であることを示しています。不変のデータオブジェクトと組み合わせた純粋な関数は、明らかに優れたコーディング方法です。
純粋なデータオブジェクトを持つことには何の問題もありません。著者は、私が知っているソフトウェア開発者には共有されない意見を持っています。
特にデータベースマッピングの場合、一般に、データベースに格納されているフィールドとゲッターおよびセッターのみを含むエンティティークラスがあります。 Wikipedia Hibernate（framework）
Java多くのツール/フレームワークで使用されるBeans）の穴のアイデアは、フィールドと関連するゲッターとセッターのみを含むBeansと呼ばれるデータクラスに基づいています。 Wikipdia JavaBeans
Fazit：
何かが「悪い」または「コードのにおい」であると誰かが主張する場合、常に与えられた理由を探す必要があります。理由が納得できない場合は、より良い理由または別の意見について他の人に尋ねてください。 （このフォーラムでしたように）
マーティン・ファウラーによるなぜ良い議論：
「Tell-Don't-Askは、オブジェクト指向とは、データをそのデータを操作する関数とバンドルすることに関するものであることを人々が覚えておくのに役立つ原則です。代わりに、オブジェクトに何をすべきかを伝える必要があります。これにより、データに合わせて動作をオブジェクトに移動することが奨励されます。」
理解する必要があるのは、2種類のオブジェクトがあることです。
behaviorを持つオブジェクト。これらは、データメンバーのほとんどまたはすべてにパブリックアクセスを与えることを控えるべきです。これらに対して定義されているアクセサメソッドはごくわずかです。
例はコンパイルされた正規表現です：オブジェクトは特定の動作を提供するために作成されます（文字列を特定の正規表現と照合し、（部分的な）一致を報告するためです）howコンパイルされた正規表現はその仕事はユーザーの仕事ではありません。
私が書くほとんどのクラスはこのカテゴリーにあります。
実際にはdataであるオブジェクト。これらは、すべてのメンバーをパブリックとして宣言する必要があります（または、完全なアクセサセットを提供します）。
例は、クラス
Point2Dです。このクラスのメンバーに保証する必要がある不変条件は絶対にありません。ユーザーはmyPoint.xおよびmyPoint.yを介してデータにアクセスできる必要があります。個人的に、私はそのようなクラスをあまり使用しませんが、どこかでそのようなクラスを使用しない、私が書いたより大きなコードの断片はないと思います。
オブジェクト指向に習熟するには、この違いが存在することを理解し、クラスの関数をこれら2つのカテゴリのいずれかに分類することを学びます。
C++でコーディングする場合、オブジェクトの最初のカテゴリーにclassを使用し、2番目のカテゴリーにstructを使用することにより、この区別を明示的にすることができます。もちろん、これら2つは同等ですが、classはすべてのメンバーがデフォルトで非公開であることを意味し、structはすべてのメンバーがデフォルトで公開であることを宣言します。まさにあなたが伝えたい情報の種類です。