Абстракция данных

Скрытие реализации связано с абстракциями. Но он не просто делает переменные закрытыми и использует геттеры и сеттеры для доступа к этим переменным. Скорее, он предоставляет абстрактные интерфейсы, которые позволяют пользователям манипулировать сущностью данных, не зная их реализации. Например:

и

Первый использует конкретные термины для передачи уровня топлива в транспортном средстве, тогда как второй использует абстракцию в процентах. Второй вариант выше предпочтительнее. Вместо этого мы хотим выразить наши данные в абстрактных терминах. Это достигается не только с помощью интерфейсов и/или геттеров и сеттеров.

Антисимметрия данных/объектов

Проще говоря, разница между объектами и структурой данных заключается в следующем:

  • Объект: скрыть свои данные за абстракциями и предоставить функции, которые работают с этими данными.
  • Структура данных: раскрывает свои данные и не имеет значимых функций.

Рассмотрим, например, пример процедурной формы. Класс Geometry работает с тремя классами формы. Классы фигур — это простые структуры данных без какого-либо поведения. Все поведение находится в классе Geometry.

Посмотрите, что произойдет, если я добавлю функцию perimeter() к Geometry. Класс формы не будет затронут. С другой стороны, если я добавлю новую фигуру (новую структуру данных), мне придется изменить все функции в Geometry, чтобы справиться с ней.

Теперь рассмотрим объектно-ориентированное решение. Здесь метод area() является полиморфным. Класс Geometry не нужен. Поэтому, если я добавлю новую фигуру, ни одна из существующих функций не пострадает, но если я добавлю новую функцию, все фигуры должны быть изменены!

Фундаментальная дихотомия между объектами и структурами данных:

Процедурный код (код, использующий структуры данных) упрощает добавление новых функций без изменения существующих структур данных. С другой стороны, объектно-ориентированный код позволяет легко добавлять новые классы без изменения существующих функций.

Дополнение

Процедурный код затрудняет добавление новых структур данных, потому что все функции должны измениться. Код OO затрудняет добавление новых функций, потому что все классы должны измениться.

Дело в том, что есть вещи, которые сложны для ООП, просты для процедур, а вещи, которые сложны для процедур, легко для ОО!

Когда мы хотим добавить новые типы данных, а не новые функции, OO является наиболее подходящим. Когда мы хотим добавить новые функции, а не типы данных, структуры данных будут более подходящими.

Закон Деметры

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

Точнее, предположим, что у вас есть метод fи класс C. Закон Деметры гласит, что метод fкласса Cдолжен вызывать только следующие методы:

  • C(сам)
  • Объект, созданный f
  • Объект, переданный в качестве аргумента f
  • Объект, хранящийся в переменной экземпляра C

Например:

Метод не должен вызывать методы для объектов, возвращаемых любой из разрешенных функций. Другими словами, разговаривайте с друзьями, а не с незнакомцами.

Обломки поезда

Посмотрите на приведенный ниже код, который нарушает Закон Деметры.

Это нарушает закон Деметры, поскольку вызывает функцию getScratchDir() для возвращаемого значения getOptions(), а затем вызывает getAbsolutePath() для возвращаемого значения getScratchDir(). Такой код часто называют крушением поезда, потому что он выглядит как группа сцепленных вагонов поезда. Лучшее решение — разделить их следующим образом:

Является ли это нарушением Деметры, зависит от того, являются ли ctxt, Options и ScratchDir объектами или структурами данных. Если это объекты, то их внутренняя структура должна быть скрыта, а не открыта. С другой стороны, если ctxt, Options и ScratchDir являются просто структурами данных без поведения, то они естественным образом обнажают свою внутреннюю структуру, и поэтому Деметра не применяется.

Гибриды

Гибридные структуры представляют собой наполовину объекты и наполовину структуры данных. гибриды затрудняют добавление новых функций, но также затрудняют добавление новых структур данных. Избегайте их создания.

Объекты передачи данных

Типичной формой структуры данных является класс с общедоступными переменными и без функций, он называется Data Transfer Object или DTO. DTO — очень полезные структуры, особенно при общении с базами данных или анализе сообщений из сокетов и т. д.

Несколько чаще встречается форма «боб». Бины имеют частные переменные, которыми манипулируют геттеры и сеттеры.

Активная запись

Active Records — это структуры данных с общедоступными (или доступными) переменными. Но у них обычно есть методы навигации, такие как save и find. Обычно эти активные записи являются прямыми трансляциями из таблиц базы данных или других источников данных.

Необрабатывайте эти структуры данных как объекты, помещая в них методы бизнес-правил. Решение состоит в том, чтобы рассматривать Active Record как структуру данных и создавать отдельные объекты, содержащие бизнес-правила и скрывающие свои внутренние данные.

Вывод

  • Объекты раскрывают поведение и скрывают данные. Это упрощает добавление новых видов объектов без изменения существующих поведений, но затрудняет добавление новых поведений к существующим объектам.
  • Структуры данных раскрывают данные и не имеют существенного поведения. Это упрощает добавление новых поведений к существующим структурам данных, но затрудняет добавление новых структур данных к существующим функциям.
  • Когда нам нужна гибкость для добавления новых типов данных, мы предпочитаем объекты для этой части системы.
  • Когда нам нужна гибкость для добавления новых поведений, мы предпочитаем структуры данных для этой части системы.
  • Хорошие разработчики программного обеспечения понимают эти проблемы без предрассудков и выбирают наилучший подход к своей работе.

Это все краткое изложение главы 6 книги, которую я пытался изучить, и понял суть книги под названием «Чистый код» Роберта С. Мартина.

Не стесняйтесь вносить предложения и отзывы. Спасибо.

Ссылка

«Чистый код» Роберта С. Мартина