Принцип SRP vs private class data design pattern. Хто правий?
Нещодавно, при виконанні тестового завдання я отримав критику, щодо архітектури проекту. Зокрема мова була про недотримання SRP.
На роботу мене не взяли і відразу після всього я взявся за теорію і вивчення всіх цих вищеназваних принципів. Почитав в декількох джерелах, розібрав, занотував в зошит, декілька разів зазубрив (бо ж на співбесідах питатимуть)....через тиждень з чистою совістю все забув.
Пройшов деякий час і я повернувся до SOLID. Вирішено було осягати все на практиці: з кодом, прикладами і IntellijIdea.
Загуглив перший з цієї санскріптної мантри принцип, ткнув в першу урлу з результатів, потрапив на вікі:
ru.wikipedia.org/...нственной_ответственности
На цьому ресурсі нам намагаються втюхати пояснити цей, перший принцип, на наступному прикладі:
Маємо сутніть (геттери/сеттери відпускаю)
public class Report { private String date; private String header; private String content; private String footer; }
Маємо дії які повинні вміти робити з цією сутністю:
toPrint(); toHtml(); toJson();
Спочатку нам говорять, що можна ці методи додати в класс Report і що це не правильно і я тут повністю погоджуюсь.
public class Report { private String date; private String header; private String content; private String footer; public void toPrint() { //print resport; } public void toHtml() { //generate to html; } }
Далі слідує рішення:
public class Response { private Report report; public void toPrint() { //print resport; } public void toHtml() { //generate to html; } }
Так, рішення не досконале і можна булоб додати реалізацію інтерфейсів і всяке таке, але логіка здавалось би вірна, але ні — на вікі кажуть, що
Вроде классы разделены по назначениям, но у Response есть признак нарушения SRP. Он зависим от Report. Изменяя Report, например, удалив метод получения заголовка, потребуются внести изменения в Response. А ведь изначально не подразумевалось изменять код формата отчёта. Код проекта не готов к быстрым и безболезненным изменениям.
і пропонується вирішити питання за допомогою паттернів проектування, зокрема
Выделение частного класса данных
ru.wikipedia.org/...ие_частного_класса_данных
Переходимо за посиланням, і що ми бачимо у висновку?:
(приклад надається на C#)
class CircleData { private double radius; private Color color; private Point origin; } class Circle { private CircleData circleData; public Circle(double radius, Color color, Point origin) { circleData = new CircleData(radius, color, origin); } public double Circumference { get { return 2 * Math.PI * this.circleData.Radius; } } public double Diameter { get { return 2 * this.circleData.Radius; } } public void Draw(Graphics graphics) { //... } }
А бачимо те, що замінивши класи CircleData на Report, а Circle на Response, і замінивши також методи Circumference, Diameter, Draw на toPrint(), toHtml(), toJson() - ми отримаєм в рішенні той шаблон, який називався «невірним рішенням».
На цьому місці хотілось би зупинитися і розібратися.
Як так виходить що патерни проектування суперечать принципам SOLID?
57 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів