Создаем IT-продукты на заказ

За 5 лет мы создали продукты с топовыми e-commerce компаниями, ритейлом, банками и другими бизнесами по всему миру.

Специализируемся на SaaS-решениях на архитектуре микросервисов, делаем аналитику IT-проекта перед стартом.

Посмотрите, что говорят о нас клиенты и как комфортно мы стартуем проекты.

Для обсуждения проекта пишите на ceo@byndyusoft.com или звоните +7 (904) 305 5263

четверг, 29 октября 2009 г.

Принцип замещения Лисков

Формулировка №1: eсли для каждого объекта o1 типа S существует объект o2 типа T, который для всех программ P определен в терминах T, то поведение P не изменится, если o2 заменить на o1 при условии, что S является подтипом T.

Формулировка №2: Функции, которые используют ссылки на базовые классы, должны иметь возможность использовать объекты производных классов, не зная об этом.

Короткая версия: Derived classes must be substitutable for their base classes

Доклад на тему «Экстремальное программирование. Опыт внедрения» в ЮУрГУ

5-ого ноября в 18-00 я буду рассказывать о нашем опыте внедрения экстремального программирования (XP). Пройдет эта встреча в ЮУрГУ в аудитории 240, корпус 3Б. Содержание будет такое же как и на июньской встрече в ЧелГУ.

Участие бесплатное. До встречи!

среда, 14 октября 2009 г.

Принцип открытости/закрытости

Формулировка: программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для изменения

Какую цель мы преследуем, когда применяем этот принцип? Как известно программные проекты в течение свой жизни постоянно изменяются. Изменения могут возникнуть, например, из-за новых требований заказчика или пересмотра старых. В конечном итоге потребуется изменить код в соответствии с текущей ситуацией.

пятница, 9 октября 2009 г.

Принцип единственности ответственности

Формулировка: не должно быть больше одной причины для изменения класса

Что является причиной изменения логики работы класса? Видимо, изменение отношений между классами, введение новых требований или отмена старых. Вообще, вопрос о причине этих изменений лежит в плоскости ответвенности, которую мы возложили на наш класс. Если у объекта много ответвенности, то и меняться он будет очень часто. Таким образом, если класс имеет больше одной ответственности, то это ведет к хрупкости дизайна и ошибкам в неожиданных местах при изменениях кода.

Принципы проектирования классов (S.O.L.I.D.)

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

В ближайшее время я выпущу серию постов, в которых раскрою принципы проектирования классов:

Tема будет очень познавательна для тех, кто еще не знаком этими принципами.

Ссылки

PrinciplesOfOod

HanselMinutes:SOLID Principles with Uncle Bob - Robert C. Martin

SOLID Software Principles - Presentation And Code

Хороший дизайн должен быть SOLID: TOP-5 архитектурных принципов

Pablo's Topic of the Month - March: SOLID Principles

Создаем IT-продукты на заказ

За 5 лет мы создали продукты с топовыми e-commerce компаниями, ритейлом, банками и другими бизнесами по всему миру.

Специализируемся на SaaS-решениях на архитектуре микросервисов, делаем аналитику IT-проекта перед стартом.

Посмотрите, что говорят о нас клиенты и как комфортно мы стартуем проекты.

Для обсуждения проекта пишите на ceo@byndyusoft.com или звоните +7 (904) 305 5263