OOP类设计，此设计是天生的“反” OOP吗？

OOP class design, Is this design inherently 'anti' OOP?

我记得当MS发布一个论坛示例应用程序时，该应用程序的设计是这样的：

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

所以classes文件夹只有类，即属性和getters / setters。
Users.cs，Post.cs等具有访问数据访问层的实际方法，因此Posts.cs可能类似于：

1
2
3
4
5
6
7
8

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

另一种更传统的方法是将Posts.cs中的所有方法也都放入类定义(Post.cs)中。

将内容拆分为2个文件可以使过程更多一些，不是吗？
这是否违反了OOP规则，因为它将行为从类中移出并放入了另一个类定义中？

如果每个方法只是直接调用数据源的静态调用，则" Posts"类实际上是一个Factory。您当然可以将" Posts"中的静态方法放入" Post"类中??(这是CSLA的工作方式)，但是它们仍然是工厂方法。

我会说" Posts"类的一个更现代，更准确的名称是" PostFactory"(假设它所拥有的只是静态方法)。

我想我不一定会说这是"过程式"方法，它只是一个误导性的名称，您会认为在现代OO世界中，" Posts"对象将是有状态的，并提供操作和管理一组对象的方法。"发布"对象。

好吧，这取决于在何处以及如何定义关注点分离。如果将代码填充到Post类中，则您的业务层将插入数据访问代码，反之亦然。

对我来说，在实际的域对象外部进行数据提取和填充是有意义的，并让域对象负责使用数据。

什么是anti-OOP或pro-OOP完全取决于软件的功能以及使其工作所需的条件。

对于应用程序去耦(或松散耦合)，这也是重要的一步。

根据您的代码段，Posts主要是一类静态帮助器方法。 Post与Post是不同的对象。可以使用PostManager或PostHelper来代替Posts。如果您以这种方式考虑，则可能有助于您理解他们为何以这种方式爆发。

您确定这些类不是局部类。在这种情况下，它们实际上不是两个类，而是一个类分散在多个文件中以提高可读性。