Класс
Класс, о котором мы обычно знаем, имеет частные переменные и общедоступные методы, которые манипулируют этими переменными.
Взгляд извне у класса нет переменных.
Следовательно, если смотреть снаружи внутрь, класс и, следовательно, его объекты не имеют «наблюдаемого» состояния.
А как насчет получателей этих переменных?
Рассмотрим класс с кучей переменных, которые, конечно, являются частными, и вы предоставляете их внешнему миру через их геттеры и сеттеры. во-первых?
Вам не кажется, что при использовании такого класса через эти геттеры нарушается принцип "скажи, не спрашивай"?
Давайте рассмотрим класс с кучей переменных и несколькими методами (не геттерами и сеттерами), которые работают с этими переменными.
Учтите, что эти методы могут манипулировать одной или несколькими переменными этого класса. Метод называется более «связным», чем другой, если он манипулирует большим количеством переменных, чем другой метод этого класса, который манипулирует меньшим количеством переменных.
Говоря это, мы можем сказать, что методы получения и установки не (достаточно) связные методы, поскольку каждый из них манипулирует одной переменной.
В целом это означает, что класс менее сплочен, если в нем больше методов получения и установки.
Значит ли это, что в классе не должно быть геттеров или сеттеров?
Было бы логичнее, если бы геттеры класса «абстрагировали» информацию, содержащуюся в переменных.
Например, давайте создадим класс с именем «автомобиль» и вместо создания геттера с именем «getPetrolLevel» создадим геттер с именем «getFuelPercentage». Давайте посмотрим, насколько это важно. Предоставление методу класса более абстрактного имени будет способствовать созданию производных, таких как «dieselCar» или «electricCar», которые будут лучше соответствовать его базовому «автомобилю». Это также соответствует принципу открытия/закрытия.
Чем меньше переменных или деталей реализации класса раскрывается, тем больше возможностей для создания полиморфных классов.
Структура данных
Как тогда будет называться класс, например, работник, который раскрывает внешнему миру свое внутреннее состояние и детали реализации, такие как имя и почтовый адрес, в виде геттеров и сеттеров? Класс? Нет! Структура данных? Да!
В отличие от классов, структуры данных не являются связными. Они не помогают следовать принципу «говори, не спрашивай». Структурам данных задают только простые вопросы. Если вы ожидаете, что структура данных будет делать что-то общее или абстрактное, то реализованная функциональность должна быть делегирована из этой структуры данных. Делегированная функциональность может использовать операторы switch case, которые детализируют реализацию на основе типа структуры данных.
"Если вы видите реализацию с оператором switch case, можете быть уверены, что за ней скрывается какая-то структура данных".
То, как связаны классы и полиморфизм, может быть таким же, как связаны операторы switch и структуры данных. ?
Когда в класс добавляется новая функция, все ее производные (если есть) и зависимые должны быть перекомпилированы. Когда добавляется новый тип (производный) класса, нет/минимально влияние на его зависимые и производные.
Аналогичным образом, когда вы добавляете новый тип в структуру данных, все операторы switch, использующие тип структуры данных, должны быть изменены и скомпилированы. Когда в структуру данных добавляется новый метод, вам нужно написать новый переключатель. Это не влияет на уже существующие операторы switch case.
Проблема несоответствия импеданса
Хорошая архитектура приложения предполагает, что зависимости, такие как базы данных и представления, должны зависеть от логики вашего приложения, а не наоборот. Код приложения должен быть максимально абстрактным, а зависимости, такие как база данных и представления, должны рассматриваться как конкретные.
Поток управления исходным кодом или зависимости от конкретной реализации к абстрактной, противоположный направлению потока исполнения. Код приложения использует базу данных или пользовательский интерфейс, даже не подозревая об их существовании. Это «принцип инверсии зависимости».
База данных содержит таблицы. Таблицы — это «структуры данных», они не содержат бизнес-объектов или объектов предметной области. Столы бетонные; объекты домена более абстрактны в своей реализации, чем таблицы (или их представления в памяти).
Такой инструмент, как Hibernate, действительно ли он решает проблему несоответствия импедансов?
Истинное несоответствие импеданса между базами данных и объектно-ориентированным дизайном не решается с помощью таких инструментов, как спящий режим. Hibernate — очень хороший инструмент, который помогает преобразовывать структуры данных в базах данных в структуры данных в памяти. Именно уровень интерфейса БД решает эту проблему несоответствия. Правильная абстракция и ее правильное использование преобразуют структуры данных в памяти в бизнес-объекты или объекты предметной области и устраняют несоответствие импеданса.
