Я ни для кого не сделаю открытия, сказав, что проектирование архитектуры программного обеспечения является одним из наиболее сложных этапов разработки. Выбор той или иной архитектуры скажется на большинстве характеристик качества ПО в целом. От архитектуры будут зависеть такие важнейшие показатели, как скорость и стоимость разработки. Она предлагает серию решений, основанных на широком диапазоне факторов, и каждое из этих решений может значительно влиять как на качество, производительность, удобство поддержки, так и на общий успех программного обеспечения. И… это еще не все.
Самая большая прелесть проектирования, на мой взгляд, заключается в том, что свой вклад может внести абсолютно любой специалист, принимающий участие в проекте. Едва-ли не ежедневно каждый ООП-программист сталкивается с необходимостью в проектировании классов и их взаимодействии. Это тоже архитектура. Но более «прикладная». Именно о ней (а точнее, о принципах, помогающих делать ее правильно) я и хотел сегодня поговорить.
Стоит уточнить, что под «принципом проектирования» я понимаю «design guideline».
Говорить здесь о таких известных и крайне полезных принципах проектирования, как SOLID, Separation of concerns (SoC), DRY, KISS или YAGNI, я думаю, не имеет особого смысла, тем более, что статей на эту тему великое множество даже на русском. Каждый так или иначе вкурсе. Однако, возможно, кому-то будут интересны 2 чуть менее известных принципа, о которых, обычно, упоминают реже.
Tell, Don't Ask
Программный принцип, смысл которого заключается в том, что программист, при проектировании архитектуры, не должен строить логику программы, основываясь на состоянии объекта. Он должен «говорить» объекту сделать что-то, а уже сам объект решает каким образом он это должен сделать. Иными словами, логика принятия решения о конкретном действии, основываясь на состоянии объекта, инкапсулирована внутрь класса в виде отдельного приватного метода. Задача проектирования может быть упрощена при условии, что архитектор изначально создает классы, опираясь на команды (методы), которые этот класс должен выполнять, вместо того, чтобы брать за основу свойства, которыми он должен обладать.
Пример:
Предпосылки
Работая с некоторыми отдельными параметрами объекта, мы, семантически, перестаем воспринимать его как нечто цельное, перестаем воспринимать его как класс, рассматривая только отдельные его составляющие.
Law of Demeter (LoD)
Программный принцип, сформулированный следующим образом:
Определить является ли объект «непосредственно связанным» или нет, нам поможет набор простых правил:
Смысл» сказанного можно условно упростить до
Пример:
Предпосылки
При необходимости в серьезном пересмотре структурных взаимосвязей внутри архитектуры, избыточные связи между объектами этой архитектуры неизбежно вызовут массу проблем.
Самая большая прелесть проектирования, на мой взгляд, заключается в том, что свой вклад может внести абсолютно любой специалист, принимающий участие в проекте. Едва-ли не ежедневно каждый ООП-программист сталкивается с необходимостью в проектировании классов и их взаимодействии. Это тоже архитектура. Но более «прикладная». Именно о ней (а точнее, о принципах, помогающих делать ее правильно) я и хотел сегодня поговорить.
Стоит уточнить, что под «принципом проектирования» я понимаю «design guideline».
Говорить здесь о таких известных и крайне полезных принципах проектирования, как SOLID, Separation of concerns (SoC), DRY, KISS или YAGNI, я думаю, не имеет особого смысла, тем более, что статей на эту тему великое множество даже на русском. Каждый так или иначе вкурсе. Однако, возможно, кому-то будут интересны 2 чуть менее известных принципа, о которых, обычно, упоминают реже.
Tell, Don't Ask
Программный принцип, смысл которого заключается в том, что программист, при проектировании архитектуры, не должен строить логику программы, основываясь на состоянии объекта. Он должен «говорить» объекту сделать что-то, а уже сам объект решает каким образом он это должен сделать. Иными словами, логика принятия решения о конкретном действии, основываясь на состоянии объекта, инкапсулирована внутрь класса в виде отдельного приватного метода. Задача проектирования может быть упрощена при условии, что архитектор изначально создает классы, опираясь на команды (методы), которые этот класс должен выполнять, вместо того, чтобы брать за основу свойства, которыми он должен обладать.
Пример:
//Not so good
if (currentUser.isAdmin())
currentUser.showAdminWelcomMessage();
else
currentUser.showUserWelcomMessage();
//Better
currentUser.showWelcomMessage();
Предпосылки
Работая с некоторыми отдельными параметрами объекта, мы, семантически, перестаем воспринимать его как нечто цельное, перестаем воспринимать его как класс, рассматривая только отдельные его составляющие.
Law of Demeter (LoD)
Программный принцип, сформулированный следующим образом:
Объект не должен обладать сведениями о других объектах, кроме объектов, с которыми он имеет непосредственную связь.
Определить является ли объект «непосредственно связанным» или нет, нам поможет набор простых правил:
- Метод может работать напрямую с собственным классом и его атрибутами
- Метод может работать напрямую с параметрами, которые передаются в него
- Метод может работать напрямую с «объектами, созданными внутри него
Смысл» сказанного можно условно упростить до
используй только одну точку
Пример:
//Not so good
a.getB().getC().doSomething();
//Better
a.doSomething();
Предпосылки
При необходимости в серьезном пересмотре структурных взаимосвязей внутри архитектуры, избыточные связи между объектами этой архитектуры неизбежно вызовут массу проблем.