Java以外のOOP言語の文化はよく知らんのでJava限定ってことで。よくJavaBeanというものを耳にすると思いますが、よくあるゲッターとセッターとprivateフィールドの組み合わせで業務ロジックを包含する、なんていうか再利用可能なコンポーネントとかと呼ばれているものです。
で、JavaBeanというのはjava.io.Serializableを実装していてゲッターとセッターがあればオッケーなんですが、これは俗に言うJavaBeanです。これをトランザクションに参加できたりリモート化できるようにしたのがEJBです。これらは業務ロジックを包含しているのでカプセル化は重要です。
私が最近どうよ？と思うのが、エンティティやDTOに使われるValueObjectの類です。リフレクションを利用したフレームワークや今までの流儀があるせいか、絶対にフィールドへの単純な入出力しかしないのにゲッターとセッターを作るんですね。
最近のIDEではこの辺は自動生成もできるので、実際にそこまでは苦ではないのですが、本当にゲッターとセッターって要るの？と思うようになって来ました。構造体代わりの使い方しかしていないんですよね。将来拡張する可能性が・・・などという人もいますが、実際に何割のコードを拡張してきたのでしょう？逆にやらない拡張の為にどれだけゲッターとセッターに苦労してきたのでしょう？別にフィールドに直接アクセスしてもいいんじゃないかと。
ただ問題が一つあります。DTOの類にアクセスするフレームワークです。これらはゲッターとセッターが揃っているのを前提としているフレームワークが非常に多いのですね。でもこの辺も動的にインターフェイスを生成して、そのインターフェイスのプロキシをフレームワークに食わせれば解決できる問題です。利用コードでは動的に生成したインターフェイスにキャストできる必要はないので、実装コードも非常にシンプルです。
Seasar2ではDTOやエンティティでpublicフィールドをプロパティとしてみなすということが行われています。S2JDBCのテストコードがSVNに挙がっていましたが、ゲッターとセッターのないエンティティクラスの操作は非常にシンプルでした。
というわけで、もうそろそろDTOやエンティティのクラスの無駄なカプセル化を行う文化を考え直しましょうよ。