Дизайн класса ООП. Является ли этот дизайн по сути «анти» ООП?

Question

Я помню, когда MS выпустила пример приложения на форуме, дизайн приложения был таким:

/ Классы / User.cs /Classes/Post.cs ... /Users.cs /Posts.cs

Таким образом, папка классов имела только класс, т.е. свойства и методы получения / установки. Users.cs, Post.cs и т. Д. Имеют фактические методы доступа к уровню доступа к данным, поэтому Posts.cs может выглядеть так:

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

Другим более традиционным способом было бы поместить все методы в Posts.cs также в определение класса (Post.cs).

Разделение объектов на 2 файла делает его намного более процедурным, не так ли? Разве это не нарушает правила ООП, поскольку оно выводит поведение из класса и помещает его в другое определение класса?

Answer 1

Если каждый метод является просто статическим вызовом прямо к источнику данных, то класс «Posts» - это действительно Factory. Конечно, вы могли бы поместить статические методы из «Posts» в класс «Post» (так работает CSLA), но они все еще являются фабричными методами.

Я бы сказал, что более современным и точным именем для класса "Posts" будет "PostFactory" (при условии, что у него есть только статические методы).

Полагаю, я бы не сказал, что это обязательно «процедурный» подход - это просто вводящее в заблуждение имя, вы бы предположили, что в современном мире OO объект «Posts» будет иметь состояние и предоставлять методы для манипуляции и управления набор объектов "Пост".

Answer 2

Ну, это зависит от того, где и как вы определяете свое разделение интересов. Если вы поместите код для заполнения Post в классе Post, ваш бизнес-уровень будет заменен кодом доступа к данным, и наоборот.

Для меня имеет смысл выполнять выборку и заполнение данных вне фактического объекта домена, и позволить объекту домена отвечать за использование данных.

Answer 3

Что такое анти-ООП или про-ООП, полностью зависит от функциональности программного обеспечения и того, что необходимо для его работы.

Answer 4

Это также важный шаг для развязки (или слабой связи) ваших приложений.

Answer 5

Исходя из вашего фрагмента кода, Posts - это прежде всего класс статических вспомогательных методов. Посты это не тот же объект, что и Пост . Вместо Сообщений лучшим названием может быть PostManager или PostHelper . Если вы думаете об этом таким образом, это может помочь вам понять, почему они так обошлись.

Answer 6

Вы уверены, что классы не являются частичными. В этом случае это действительно не два класса, а один класс, распределенный по нескольким файлам для лучшей читаемости.