Не может показаться, что они понимают СОЛИДНЫЕ принципы и шаблоны проектирования

Ответ 1

Я взял класс в колледже, который провел две недели вокруг дизайнерских паттеров и прочитал Gang of Four безрезультатно. Понимание того, что каждый образец служил и как использовать их в соответствии с моими проблемами, было очень тяжело для меня, разработчика, у которого не было большого опыта программирования OO.

Книга, которая действительно заставила меня щелкнуть, была Head First Design Patterns. Он начинается с выявления проблемы, разных подходов, рассмотренных разработчиками, а затем, как они закончили использование шаблона проектирования, чтобы исправить это. Он использует очень простой язык и делает книгу очень привлекательной.

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

Расскажите о SOLID:

• Одиночная ответственность. У класса должна быть только одна ответственность. Это означает, что, например, класс Person должен беспокоиться только о проблеме домена, касающейся самого человека, а не, например, о его сохранении в базе данных. Для этого вы можете использовать PersonDAO, например. Класс Person может захотеть сохранить свои обязанности как можно короче. Если класс использует слишком много внешних зависимостей (то есть других классов), это признак того, что у класса слишком много обязанностей. Эта проблема часто возникает, когда разработчики пытаются смоделировать реальный мир с использованием объектов и зайти слишком далеко. Взаимозаменяемые приложения часто не очень удобны для навигации и не совсем точно определяют, как работает настоящий мир.
• Открыть закрыто. Классы должны быть расширяемыми, но не модифицируемыми. Это означает, что добавление нового поля в класс отлично, но изменение существующих вещей - нет. Другие компоненты программы могут зависеть от указанного поля.
• Подстановка Лискова. Класс, который ожидает объект типа животного, должен работать, если собака подкласса и кошка подкласса передаются. Это означает, что у Animal НЕ должен быть метод, называемый корой, например, поскольку подклассы типа cat не смогут лаять. Классы, которые используют класс Animal, также не должны зависеть от методов, принадлежащих классу Dog. Не делайте такие вещи, как "Если это животное - собака, то (линяет животное собаку). Если животное - кошка, то (бросает животное в кошку) мяу".
• Принцип сегрегации интерфейса. Держите свои интерфейсы как можно меньше. Учитель, который также является учеником, должен реализовывать интерфейсы IStudent и ITeacher, а не один большой интерфейс, называемый IStudentAndTeacher.
• Принцип инверсии зависимостей. Объекты не должны создавать свои зависимости, но они должны быть переданы им. Например, автомобиль, у которого есть объект Engine внутри, не должен делать engine = new DieselEngine(), но, скорее, он должен быть передан ему на конструкторе. Таким образом, класс автомобиля не будет связан с классом DieselEngine.