Question

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

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.