Сегодня будет сложно. Напомню, что тут только мои заметки. Для полного погружения читайте книгу. :)
Когда я читала в первый раз эту книгу Мартина, то шестая глава была мне максимально непонятной. Сейчас стало яснее, но все равно тяжко зашла.
Заметки:
Используйте интерфейсы, а не напрямую реализацию в классах. Как пример: можно сделать класс с двумя переменными name и age. В этом случае мы сможем
Сегодня будет сложно. Напомню, что тут только мои заметки. Для полного погружения читайте книгу. :)
Когда я читала в первый раз эту книгу Мартина, то шестая глава была мне максимально непонятной. Сейчас стало яснее, но все равно тяжко зашла.
Заметки:
- Используйте интерфейсы, а не напрямую реализацию в классах. Как пример: можно сделать класс с двумя переменными name и age. В этом случае мы сможем присваивать значения для name и age в разное время. Но что делать, если это обязательно делать именно одновременно? Лучше создать интерфейс с геттерами и сеттером сразу для двух переменных. Так пользователь сможет читать значения независимо друг от друга. И их можно будет присваивать одновременно, если это необходимо.
- Скрытие реализации направлено на формирование абстракций. Абстракции — это хорошо.
- Класс должен не просто ограничивать доступ к переменным через методы чтения и записи, но и предоставлять абстрактные интерфейсы, которыми пользователь и будет оперировать. Знать данные реализации не нужно. С этим согласна. Сама постоянно обращаюсь к другим классам именно через интерфейсы, а вся реализация скрыта где-то глубоко внутри.
- Структуры данных раскрывают свои данные и не имеют осмысленных методов.
- Процедурный код (код, который использует структуры данных) позволяет легко добавлять новые методы без изменения соответствующих структур данных. Объектно-ориентированный код упрощает добавление новых классов без изменения соответствующих методов.
- Процедурный код усложняет добавление новых структур данных, потому что это требует изменение всех методов. Объектно-ориентированный код усложняет добавление новых методов, потому что для этого должны измениться все классы.
- Закон Деметры — модуль не должен знать внутреннее устройство тех объектов, с которыми он работает. Точная формулировка: метод a() класса С должен ограничиваться вызовом методов следующих объектов:
— класса С;
— объектов, созданные методом а();
— объектов, переданные a() в качестве аргумента;
— объектов, хранящиеся в переменной экземпляра С.
Другими словами — можно разговаривать с друзьями, но не с чужаками. Это прям цитата и мне она очень нравится. :) - НЕЛЬЗЯ вызывать методы из возвращаемых значений. Пример: а.b().c().d(). Такие цепочки — это как крушение поезда. Лучше их разделять. Однако, если там структуры данных, а не объекты, то это не является нарушением. Неожиданно, да?
Если нужны такие цепочки, то тогда лучше делать с переменными, а не с методами: а.b.c.d. - Еще раз: в структурах — открытые переменные, а в объектах — приватные переменные с открытыми функциями.
- Не используйте гибриды и не совмещайте структуры данных с объектами.
- DTO(Data Transfer Object) классы — объекты передачи данных или классы с открытыми переменными и без функций. С них начинается серия фаз преобразования низкоуровневых данных, полученных из базы, в объекты кода приложения.
- Активные записи — разновидность DTO. Тоже структура данных с открытыми переменными, но обычно там еще методы find и save. Это результат прямого преобразования таблиц БД или чего-либо другого.
- Не надо DTO считать объектами и включать в него методы с бизнес-логикой.
- Повторим: объекты позволяют легко добавлять новые, не изменяя существующие. Но они усложняют добавление нового поведения к существующим.
- Структуры данных предоставляют данные без значительного поведения. Легко добавить новое поведение, но сложнее добавить новые структуры в существующие методы.
- Если в системе интересует гибкость в добавлении новых типов данных, то отдается предпочтение объектной реализации.
- Если нужна гибкость расширения поведения, то тогда используем типы данных и процедуры.
