oop - OOP クラスの設計、この設計は本質的に「アンチ」OOP ですか?

Question

MS がフォーラムのサンプルアプリケーションをリリースしたときのことを覚えています。アプリケーションの設計は次のようなものでした。

/Classes/User.cs /Classes/Post.cs ... /Users.cs /Posts.cs

そのため、classes フォルダーにはクラス、つまりプロパティとゲッター/セッターだけが含まれていました。Users.cs、Post.cs などには、データアクセス層にアクセスする実際のメソッドがあるため、Posts.cs は次のようになります。

public class Posts
{
    public static Post GetPostByID(int postID)
    {
          SqlDataProvider dp = new SqlDataProvider();
          return dp.GetPostByID(postID);
    }
}

もう 1 つのより伝統的な方法は、Posts.cs のすべてのメソッドをクラス定義 (Post.cs) に入れることです。

物事を2つのファイルに分割すると、手続きがはるかに簡単になりますよね? クラスから動作を取り出して別のクラス定義に入れているため、これは OOP ルールに違反していませんか?

score 3 · Accepted Answer

すべてのメソッドがデータソースへの直接の静的呼び出しである場合、"Posts" クラスは実際には Factory です。「Posts」の静的メソッドを「Post」クラスに入れることは確かにできますが (これが CSLA の仕組みです)、それらは依然としてファクトリメソッドです。

「Posts」クラスのより現代的で正確な名前は「PostFactory」になると思います (すべてが静的メソッドであると仮定して)。

これが必ずしも「手続き型」のアプローチであるとは言えないと思います。これは単なる誤解を招く名前です。現代の OO の世界では、「Posts」オブジェクトはステートフルであり、一連のオブジェクトを操作および管理するメソッドを提供すると想定するでしょう。「投稿」オブジェクト。

score 1 · Accepted Answer

それは、関心の分離をどこでどのように定義するかによって異なります。Post にデータを入力するコードを Post クラスに配置すると、ビジネスレイヤーがデータアクセスコードに挿入されます。逆の場合も同様です。

私にとっては、実際のドメインオブジェクトの外部でデータのフェッチと入力を行い、ドメインオブジェクトにデータの使用を任せることは理にかなっています。

score 0 · Accepted Answer

何がアンチ OOP であるかプロ OOP であるかは、ソフトウェアの機能と、それを機能させるために必要なものに完全に依存します。

score 0 · Accepted Answer

クラスが部分クラスではないことを確認してください。その場合、それらは実際には 2 つのクラスではなく、読みやすくするために複数のファイルにまたがる 1 つのクラスにすぎません。

score 0 · Accepted Answer

コードスニペットに基づくと、Postsは主に静的ヘルパーメソッドのクラスです。PostsはPostと同じオブジェクトではありません。Postsの代わりに、より適切な名前はPostManagerまたはPostHelperかもしれません。そのように考えると、なぜ彼らがそのようにそれを壊したのかを理解するのに役立つかもしれません.

score 0 · Accepted Answer

これは、アプリケーションを分離 (または疎結合) するための重要なステップでもあります。

oop - OOP クラスの設計、この設計は本質的に「アンチ」OOP ですか?

6 に答える 6

Related

Reference