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

i remember when ms released forum sample application, design of application this:

/classes/user.cs /classes/post.cs ... /users.cs /posts.cs

so classes folder had class i.e. properties , getters/setters. users.cs, post.cs, etc. have actual methods access data access layer, posts.cs might like:

public class posts {     public static post getpostbyid(int postid)     {           sqldataprovider dp = new sqldataprovider();           return dp.getpostbyid(postid);     } } 

another more traditional route put of methods in posts.cs class definition (post.cs).

splitting things 2 files makes more procedural doesn't it? isn't breaking oop rules since taking behavior out of class , putting class definition?

if every method static call straight data source, "posts" class factory. put static methods in "posts" "post" class (this how csla works), still factory methods.

i more modern , accurate name "posts" class "postfactory" (assuming has static methods).

i guess wouldn't "procedural" approach -- it's misleading name, assume in modern oo world "posts" object stateful , provide methods manipulate , manage set of "post" objects.