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

Question

Hi,

I remember back when MS released a forum sample application, the design of the application was like this:

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

So the classes folder had just the class i.e. properties and getters/setters. The Users.cs, Post.cs, etc. have the actual methods that access the Data Access Layer, so Posts.cs might look like:

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

Another more traditional route would be to put all of the methods in Posts.cs into the class definition also (Post.cs).

Splitting things into 2 files makes it much more procedural doesn't it? Isn't this breaking OOP rules since it is taking the behavior out of the class and putting it into another class definition?

Answer 1

Are you sure the classes aren't partial classes. In which case they really aren't two classes, just a single class spread across multiple files for better readability.

Answer 2

Based on your code snippet, Posts is primarily a class of static helper methods. Posts is not the same object as Post. Instead of Posts, a better name might be PostManager or PostHelper. If you think of it that way, it may help you understand why they broke it out that way.

Answer 3

This is also an important step for a decoupling (or loosely coupling) you applications.

Answer 4

What's anti-OOP or pro-OOP depends entirely on the functionality of the software and what's needed to make it work.

Answer 5

If every method is just a static call straight to the data source, then the "Posts" class is really a Factory. You could certainly put the static methods in "Posts" into the "Post" class (this is how CSLA works), but they are still factory methods.

I would say that a more modern and accurate name for the "Posts" class would be "PostFactory" (assuming that all it has is static methods).

I guess I wouldn't say this is a "procedural" approach necessarily -- it's just a misleading name, you would assume in the modern OO world that a "Posts" object would be stateful and provide methods to manipulate and manage a set of "Post" objects.

Answer 6

Well it depends where and how you define your separation of concerns. If you put the code to populate the Post in the Post class, then your Business Layer is interceded with Data Access Code, and vice versa.

To me it makes sense to do the data fetching and populating outside the actual domain object, and let the domain object be responsible for using the data.