Pull to refresh
4
Karma
0
Rating

Вы препарируете труп используя SOLID

И? Вся статья об этом. Вы её прочти? Это хорошо =)
Мы используем принципы, чтобы создавать «мертвые» решения. И пропагандируем, что они позволят «развить мертвеца».

Мои познания ИИ скромнее, но там тоже не все так радует, пока получаются только системы «стимул — реакция».

Вы препарируете труп используя SOLID

Не расширяете без надобности простое, до вас тут уже много мамонтов потопталось.
Статья о том, что, используя современные ООП методологии (в частности SOLID) вы создаете нечто, что не способно на самостоятельное развитие. Хорошо если это развитие вообще возможно, лучше если оно возможно без участия вас как «творца».
Да вы тешите себе мыслью, что проект пока «не смышлёный» на этапе прототипа. Да, вы тешите себе мыслью, что проект пока «не самостоятельный» на этапе внедрения. Но на этапе сопровождения вы не на минуту не спускаете глаз с проекта, а если и отвертитесь, то вам напомнят.
Допускаю что вами был изготовлен столь искусный механизм, способный работать автономно, который не требует вашего наблюдения. Но ответе сами себе, развивается ли он сам?

Вы препарируете труп используя SOLID

Конечно могут. Хотя…

Земля в центре вселенной.
Средние века, инквизиция.

Видимо и большинство может что-то делать иначе.

Вы препарируете труп используя SOLID

Кто же против. Парой встречаются исключения. Как в анекдоте «Главное для пациента своевременный уход врача».
Приведите пример системы, которая «развивалась» бы, приносила денег, без «врача» (хорошо если одно, а то порой целый консилиумы дежурят у койки).

Вы препарируете труп используя SOLID

Труп млекопитающего тоже может быть большим. И что странно, требует множества «приседаний» для поддержания в нем процессов жизнедеятельности.

Вы препарируете труп используя SOLID

В том, что OCP дает вам надежду что этого не произойдет, поскольку вы будет придерживаться правил.

Вы препарируете труп используя SOLID

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

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

Вы препарируете труп используя SOLID

И я том же.

Кто-то создал труп, который нам не интересно препарировать. Мы создаем следующий.
Я рад за вас, за себя нет.

Вы препарируете труп используя SOLID

Заклюют же.

ООП очень ограниченная концепция, как ФП (функциональное программирование).

К сожалению, одно ограничение приводит к следующему и так далее. И всё множество попыток втиснуть большее в меньшее, путём создания ограничений не добавляют ни чего.
Мы создаем тоже код, такой же плохо, но теперь больше.
Мы умеем его создавать, используя шаблоны T4, но лучше он не становится от этого. В нем просто меньше «глупых» ошибок.

Может даже огорчать, что множество «безумцев» так и будет защищать свои любимые, создаваемые годами, «костыли». Поднимать на щитах призывы к светлому будущему, но делать всё тот же страшный код.

Вы препарируете труп используя SOLID

Вы уже сами дали хороший пример ответа.
Да создадите. Но создадите проблемы и придерживаясь принципа OCP.

Раньше или позже? Не будет завесить от принципа, будет завесить ровно от автора творения, его опыта и предсказанных изменений.
В сущности, если вы ошиблись, то вариантов у вас не много — признать это и исправить.

Как вы это сделаете? OCP вам не поможет, он вам просто это запрещает.
Может уже есть множество решений, которые эксплуатируют ваш недочет.

Можете поломать совместимость и «накажете» еще и других разработчиков, можете замазать штукатуркой и сделаете дополнительный метод.

Вы препарируете труп используя SOLID

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

Вы препарируете труп используя SOLID

Суть то в том, что даже придерживаясь их, тратя колоссальные ресурсы вы не получаете того чего желали.

например, позволит не сломать существующий код и избавит от мучительного регрессионного тестирования.

Классика жанра DoubleList.
Да, добавление двух элементов в список. Без задания на этапе проектирования пре- и пост- условия делают все ваши старания бесполезными.
Один залетевший дятел разрушит цивилизацию.

Вы препарируете труп используя SOLID

Вы упадете.
У Вас не соберется проект, отвалятся тесты, позвонит клиент.

Вы препарируете труп используя SOLID

— не компилируется, простите.

Меня там не было, я не записывал ^_^’’

Бывает, сон помогает +1

Вы препарируете труп используя SOLID

...(Очень интересно услышать бы определение «правильности выполнения программы»...).

От того, что программа раньше писала в текстовый лог, а теперь начала писать в бд, правильность не изменилась. Изменилось поведение. Так, как надо было разработчику.

Ну предположим раньше мы писали файл все было хорошо на столько, что даже ни одной обработки ошибок не было создано в процессе создания чуда.
Пишем в базу. Глотаем ошибки? Пишем их туда же в лог? Не обрабатываем?
Почему Вы считаете, что изменение поведения не меняет «правильность»?

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

Перефразирую. Проблемы возникнут как только разработчик не предвидел того что понадобилось на текущем этапе развития проекта.

Вы препарируете труп используя SOLID

Ну да, ну да. Делать такие объекты, которые не меняются ни когда.

Вы препарируете труп используя SOLID

Глупость?
Глупость — обучать разработчиков так, что ни фанатично придерживаются принципов. Не понимая зачем и для чего.
Глупость — когда они тратят уйму времени, на то чего не может быть никогда.
Глупость – когда он них требует того, что невозможно.

Вы препарируете труп используя SOLID

Как ни странно, если я заменю в большей части проектов Int32 на Int64 вообще ничего не произойдет. Даже авто тесты не повалятся. Только принцип тут не причем.
Да получалось так что всё работает. Придерживались ли его при создании этого кода – не думаю.

Вы препарируете труп используя SOLID

Почему невыполним-то?

Вы создаете решение, описываете поведение и контракты, явно или не явно. Часто не явно, поскольку ожидаете некоторого поведения от фрейморков, своих починных, своей группы.
Но как только это необходимо (требования ТЗ, изменения окружения, появления или уход сотрудника) Вы нарушаете его, помочу что выбора то у Вас и нет. В последствии, даже если, у Вас появится время (не занятое ни одним другим проектом) для изменений будете ли Вы приводить своё решение к этому принципу – НЕТ (оправдание: у нас нет времени, есть более значимые задачи). Электрической розетки без разницы зачем Вы в ней суете вилку (столовую), оно без лишних напоминаний напомнит закон Ома.

Можете Вы создать хорошее решение без – ДА, ВОЗМОЖНО. С ним – ДА, ВОЗМОЖНО.
Мешает ли Вам принцип – ИНОГДА.
Нужно ли ему следовать – ДА, КОГДА ОН НЕ МЕШАЕТ. НЕТ, КОГДА МЕШАЕТ.
Выполним ли принцип – НЕТ. Если Вас это утешит, можно написать ДА, КОГДА ОН НЕ МЕШАЕТ.

Information

Rating
Does not participate
Registered
Activity