Создание объектов внутри зависимых классов это довольно распространенная практика. К примеру тот же "фасад" чаще всего порождает нужные ему объекты сам. Мало того, это настолько обычная практика что для нее даже вывели отдельный тип связи "композиция". В нашем случае могла быть и она, может быть она даже была бы уместнее, но на диаграмме указана ассоциация дабы не усложнять) Но и в Вашем замечании есть доля правды. Но лишь от части. Само по себе создание колес вполне может происходить через фабрику\метод create и т.д., просто Bike и Car знают о том какие колеса им нужны, потому ссылаясь на принцип GRASP creator (habr.com/ru/company/otus/blog/505618/) мы можем заключить что им позволено создавать нужные им же экземпляры классов) Ну и еще одно маленькое замечание. Создавая эти объекты таким образом мы обеспечиваем консистентность данных. К примеру если бы колеса создавались вне Car и Bike тогда у программиста который разбирал бы код вполне могла бы промелькнуть резонная мысль "а почему тут нарушается принцип инверсии зависимостей?" И он заменил бы CarWheel и BikeWheel на Wheel. А после пришел бы другой программист и воспользовавшись этим заставил бы машину ездить на велосипедных колесах))
Да ребята ! Я всегда считал, что senior, отличается от junior позиции, один из обязательных моментов - это владение профессиональной лексикой. Поясню => ты либо говори на русском, либо на английском! А то получается yes, ok, макдональс))))) много микса -> спишем на волнение)))))
Ну, нужно паттерны на 1C объяснять, что бы названия классов на русском были XD Кстати, Тарас, зачем ты использовал слово "микс" если есть замечательные аналоги? К примеру "мешанина")) Спишем на волнение XD
ну тогда надо было про фаьрику расказать а потом про фабричный метод. Объеяснение есть но мне кажется можно было это сделать лучше
Слишком узкий юскейс. ФМ используется не только в этом случае "при наличие релэйшенов"
Спасибо, что подсветил!
Про необходимость использования какой-то мешанины наговорил, но с невозмутимым видом. Кохижн, коуплин, grasp - много слов но все не по сути.
Спасибо за видео! Single responsibility при этом не нарушается в Car и Bike? Теперь они отвечают еще и за создание колес помимо движения
Создание объектов внутри зависимых классов это довольно распространенная практика. К примеру тот же "фасад" чаще всего порождает нужные ему объекты сам. Мало того, это настолько обычная практика что для нее даже вывели отдельный тип связи "композиция". В нашем случае могла быть и она, может быть она даже была бы уместнее, но на диаграмме указана ассоциация дабы не усложнять)
Но и в Вашем замечании есть доля правды. Но лишь от части. Само по себе создание колес вполне может происходить через фабрику\метод create и т.д., просто Bike и Car знают о том какие колеса им нужны, потому ссылаясь на принцип GRASP creator (habr.com/ru/company/otus/blog/505618/) мы можем заключить что им позволено создавать нужные им же экземпляры классов)
Ну и еще одно маленькое замечание. Создавая эти объекты таким образом мы обеспечиваем консистентность данных. К примеру если бы колеса создавались вне Car и Bike тогда у программиста который разбирал бы код вполне могла бы промелькнуть резонная мысль "а почему тут нарушается принцип инверсии зависимостей?" И он заменил бы CarWheel и BikeWheel на Wheel. А после пришел бы другой программист и воспользовавшись этим заставил бы машину ездить на велосипедных колесах))
@@yourcodereview а на вопрос так и не ответили
@@yourcodereview и dependency inversion нам не закон, ну да ну да...
Да ребята !
Я всегда считал, что senior, отличается от junior позиции, один из обязательных моментов - это владение профессиональной лексикой. Поясню => ты либо говори на русском, либо на английском! А то получается yes, ok, макдональс))))) много микса -> спишем на волнение)))))
Ну, нужно паттерны на 1C объяснять, что бы названия классов на русском были XD
Кстати, Тарас, зачем ты использовал слово "микс" если есть замечательные аналоги? К примеру "мешанина"))
Спишем на волнение XD
@@qorecode6141 миксер - мешатель