И? Вся статья об этом. Вы её прочти? Это хорошо =)
Мы используем принципы, чтобы создавать «мертвые» решения. И пропагандируем, что они позволят «развить мертвеца».
Мои познания ИИ скромнее, но там тоже не все так радует, пока получаются только системы «стимул — реакция».
Не расширяете без надобности простое, до вас тут уже много мамонтов потопталось.
Статья о том, что, используя современные ООП методологии (в частности SOLID) вы создаете нечто, что не способно на самостоятельное развитие. Хорошо если это развитие вообще возможно, лучше если оно возможно без участия вас как «творца».
Да вы тешите себе мыслью, что проект пока «не смышлёный» на этапе прототипа. Да, вы тешите себе мыслью, что проект пока «не самостоятельный» на этапе внедрения. Но на этапе сопровождения вы не на минуту не спускаете глаз с проекта, а если и отвертитесь, то вам напомнят.
Допускаю что вами был изготовлен столь искусный механизм, способный работать автономно, который не требует вашего наблюдения. Но ответе сами себе, развивается ли он сам?
Кто же против. Парой встречаются исключения. Как в анекдоте «Главное для пациента своевременный уход врача».
Приведите пример системы, которая «развивалась» бы, приносила денег, без «врача» (хорошо если одно, а то порой целый консилиумы дежурят у койки).
Придерживаясь вы тоже тратите ресурсы и не только денег и прямо сейчас.
Полагаю, что выбор «неудачной» архитектуры никак не повлияет на выгоду от следования или не следования этим принципам. Т.е. следования принципам вам ничего не дает: вы не увидите, следуя им возможные в будущем ошибки, вы не сможете исправить положение. Они просто вас сдерживают.
Уверяю вам, будет вы ходить по тем же граблям, может быть только на цыпочках и медленно.
ООП очень ограниченная концепция, как ФП (функциональное программирование).
К сожалению, одно ограничение приводит к следующему и так далее. И всё множество попыток втиснуть большее в меньшее, путём создания ограничений не добавляют ни чего.
Мы создаем тоже код, такой же плохо, но теперь больше.
Мы умеем его создавать, используя шаблоны T4, но лучше он не становится от этого. В нем просто меньше «глупых» ошибок.
Может даже огорчать, что множество «безумцев» так и будет защищать свои любимые, создаваемые годами, «костыли». Поднимать на щитах призывы к светлому будущему, но делать всё тот же страшный код.
Вы уже сами дали хороший пример ответа.
Да создадите. Но создадите проблемы и придерживаясь принципа OCP.
Раньше или позже? Не будет завесить от принципа, будет завесить ровно от автора творения, его опыта и предсказанных изменений.
В сущности, если вы ошиблись, то вариантов у вас не много — признать это и исправить.
Как вы это сделаете? OCP вам не поможет, он вам просто это запрещает.
Может уже есть множество решений, которые эксплуатируют ваш недочет.
Можете поломать совместимость и «накажете» еще и других разработчиков, можете замазать штукатуркой и сделаете дополнительный метод.
Ну поставите код на сервер, ну замените программиста, добавите еще полгода для верности. И что-нибудь изменится? Нет Вы просто введете еще пару тройку сущностей и усложните условия, возможные причины отказа и способы решения решения.
Суть то в том, что даже придерживаясь их, тратя колоссальные ресурсы вы не получаете того чего желали.
например, позволит не сломать существующий код и избавит от мучительного регрессионного тестирования.
Классика жанра DoubleList.
Да, добавление двух элементов в список. Без задания на этапе проектирования пре- и пост- условия делают все ваши старания бесполезными.
Один залетевший дятел разрушит цивилизацию.
...(Очень интересно услышать бы определение «правильности выполнения программы»...).
От того, что программа раньше писала в текстовый лог, а теперь начала писать в бд, правильность не изменилась. Изменилось поведение. Так, как надо было разработчику.
Ну предположим раньше мы писали файл все было хорошо на столько, что даже ни одной обработки ошибок не было создано в процессе создания чуда.
Пишем в базу. Глотаем ошибки? Пишем их туда же в лог? Не обрабатываем?
Почему Вы считаете, что изменение поведения не меняет «правильность»?
При таком подходе проблемы могут быть только с классами, которые в силу конкретной реализации разработчиком не пригодны для расширения
Перефразирую. Проблемы возникнут как только разработчик не предвидел того что понадобилось на текущем этапе развития проекта.
Глупость?
Глупость — обучать разработчиков так, что ни фанатично придерживаются принципов. Не понимая зачем и для чего.
Глупость — когда они тратят уйму времени, на то чего не может быть никогда.
Глупость – когда он них требует того, что невозможно.
Как ни странно, если я заменю в большей части проектов Int32 на Int64 вообще ничего не произойдет. Даже авто тесты не повалятся. Только принцип тут не причем.
Да получалось так что всё работает. Придерживались ли его при создании этого кода – не думаю.
Вы создаете решение, описываете поведение и контракты, явно или не явно. Часто не явно, поскольку ожидаете некоторого поведения от фрейморков, своих починных, своей группы.
Но как только это необходимо (требования ТЗ, изменения окружения, появления или уход сотрудника) Вы нарушаете его, помочу что выбора то у Вас и нет. В последствии, даже если, у Вас появится время (не занятое ни одним другим проектом) для изменений будете ли Вы приводить своё решение к этому принципу – НЕТ (оправдание: у нас нет времени, есть более значимые задачи). Электрической розетки без разницы зачем Вы в ней суете вилку (столовую), оно без лишних напоминаний напомнит закон Ома.
Можете Вы создать хорошее решение без – ДА, ВОЗМОЖНО. С ним – ДА, ВОЗМОЖНО.
Мешает ли Вам принцип – ИНОГДА.
Нужно ли ему следовать – ДА, КОГДА ОН НЕ МЕШАЕТ. НЕТ, КОГДА МЕШАЕТ.
Выполним ли принцип – НЕТ. Если Вас это утешит, можно написать ДА, КОГДА ОН НЕ МЕШАЕТ.
Мы используем принципы, чтобы создавать «мертвые» решения. И пропагандируем, что они позволят «развить мертвеца».
Мои познания ИИ скромнее, но там тоже не все так радует, пока получаются только системы «стимул — реакция».
Статья о том, что, используя современные ООП методологии (в частности SOLID) вы создаете нечто, что не способно на самостоятельное развитие. Хорошо если это развитие вообще возможно, лучше если оно возможно без участия вас как «творца».
Да вы тешите себе мыслью, что проект пока «не смышлёный» на этапе прототипа. Да, вы тешите себе мыслью, что проект пока «не самостоятельный» на этапе внедрения. Но на этапе сопровождения вы не на минуту не спускаете глаз с проекта, а если и отвертитесь, то вам напомнят.
Допускаю что вами был изготовлен столь искусный механизм, способный работать автономно, который не требует вашего наблюдения. Но ответе сами себе, развивается ли он сам?
Земля в центре вселенной.
Средние века, инквизиция.
Видимо и большинство может что-то делать иначе.
Приведите пример системы, которая «развивалась» бы, приносила денег, без «врача» (хорошо если одно, а то порой целый консилиумы дежурят у койки).
Полагаю, что выбор «неудачной» архитектуры никак не повлияет на выгоду от следования или не следования этим принципам. Т.е. следования принципам вам ничего не дает: вы не увидите, следуя им возможные в будущем ошибки, вы не сможете исправить положение. Они просто вас сдерживают.
Уверяю вам, будет вы ходить по тем же граблям, может быть только на цыпочках и медленно.
Кто-то создал труп, который нам не интересно препарировать. Мы создаем следующий.
Я рад за вас, за себя нет.
ООП очень ограниченная концепция, как ФП (функциональное программирование).
К сожалению, одно ограничение приводит к следующему и так далее. И всё множество попыток втиснуть большее в меньшее, путём создания ограничений не добавляют ни чего.
Мы создаем тоже код, такой же плохо, но теперь больше.
Мы умеем его создавать, используя шаблоны T4, но лучше он не становится от этого. В нем просто меньше «глупых» ошибок.
Может даже огорчать, что множество «безумцев» так и будет защищать свои любимые, создаваемые годами, «костыли». Поднимать на щитах призывы к светлому будущему, но делать всё тот же страшный код.
Да создадите. Но создадите проблемы и придерживаясь принципа OCP.
Раньше или позже? Не будет завесить от принципа, будет завесить ровно от автора творения, его опыта и предсказанных изменений.
В сущности, если вы ошиблись, то вариантов у вас не много — признать это и исправить.
Как вы это сделаете? OCP вам не поможет, он вам просто это запрещает.
Может уже есть множество решений, которые эксплуатируют ваш недочет.
Можете поломать совместимость и «накажете» еще и других разработчиков, можете замазать штукатуркой и сделаете дополнительный метод.
Классика жанра DoubleList.
Да, добавление двух элементов в список. Без задания на этапе проектирования пре- и пост- условия делают все ваши старания бесполезными.
Один залетевший дятел разрушит цивилизацию.
У Вас не соберется проект, отвалятся тесты, позвонит клиент.
Меня там не было, я не записывал ^_^’’
Бывает, сон помогает +1
Ну предположим раньше мы писали файл все было хорошо на столько, что даже ни одной обработки ошибок не было создано в процессе создания чуда.
Пишем в базу. Глотаем ошибки? Пишем их туда же в лог? Не обрабатываем?
Почему Вы считаете, что изменение поведения не меняет «правильность»?
Перефразирую. Проблемы возникнут как только разработчик не предвидел того что понадобилось на текущем этапе развития проекта.
Глупость — обучать разработчиков так, что ни фанатично придерживаются принципов. Не понимая зачем и для чего.
Глупость — когда они тратят уйму времени, на то чего не может быть никогда.
Глупость – когда он них требует того, что невозможно.
Да получалось так что всё работает. Придерживались ли его при создании этого кода – не думаю.
Вы создаете решение, описываете поведение и контракты, явно или не явно. Часто не явно, поскольку ожидаете некоторого поведения от фрейморков, своих починных, своей группы.
Но как только это необходимо (требования ТЗ, изменения окружения, появления или уход сотрудника) Вы нарушаете его, помочу что выбора то у Вас и нет. В последствии, даже если, у Вас появится время (не занятое ни одним другим проектом) для изменений будете ли Вы приводить своё решение к этому принципу – НЕТ (оправдание: у нас нет времени, есть более значимые задачи). Электрической розетки без разницы зачем Вы в ней суете вилку (столовую), оно без лишних напоминаний напомнит закон Ома.
Можете Вы создать хорошее решение без – ДА, ВОЗМОЖНО. С ним – ДА, ВОЗМОЖНО.
Мешает ли Вам принцип – ИНОГДА.
Нужно ли ему следовать – ДА, КОГДА ОН НЕ МЕШАЕТ. НЕТ, КОГДА МЕШАЕТ.
Выполним ли принцип – НЕТ. Если Вас это утешит, можно написать ДА, КОГДА ОН НЕ МЕШАЕТ.