Комментарии 23
многие программисты даже не задумываются о другой парадигме при написании ПО. ООП стало незыблемым стандартом.
На мой взгляд все ровно наоборот. Многие разрабы на JVM думаю, что пишут на ООП. При этом у них анемичная модель данных, Spring заставляет их работать в процедурном стиле, а в коде сплошь и рядом функторы и монады из ФП.
Так что непонятно, с какой реальностью дискутирует автор и какую предметную область имеет в виду. Все популярные языки давно уже мультипарадигменные. ООП в них просто полезная фича для ряда задач, а не какой-то угнетатель, который что-то кому-то навязывает.
Это очень сильно зависит от реализации ООП в конкретном языке. Описанные проблемы это как раз проблемы реализации, а не самой парадигмы.
"это плохая игра, но это единственная игра в городе.." )
только ООП -- не паттерн, а парадигма. для поддержки и развития сложной логики -- лучше парадигмы пока нет. DDD для бизнес-логики, DOD для оптимизации игр и прочее -- это, вроде бы, все же конкретные методологии и, вполне себе, часть парадигмы ООП.
Как мне кажется ООП хорош для программирования ГУИ и для геймдева. Возможно для чего то ещё. Для скриптов по автоматизации и низкоуровнего программирования удобнее императивный линейный стиль, без перекрестного обмена данными между многочисленными объектами. Для веба, финансовой сферы лучше ФП. Для поддержки и развития сложной логики (например компиляторы и т.п.), а также для разработки системы с нечеткими требованиями, где потребудется постоянный рефакторинг и модификация кода лучше ФП тоже ничего нет. На ООП пишут не потому, что оно лучше подходит, а потому что ниже порог вхождения, больше специалистов и т.п.
Всё вышеперечисленное не претендует на истину, это лишь моё мнение, оно может отличаться от вашего.
Хорошо написано. ООП это просто методология со своими плюсами и минусами. Но, к сожалению, подходы зачастую воспринимают как аксиомы - от недостатка понимания сферы.
В копилку к чувакам, округляющим глаза на "в GET может быть тело" и "не бывает api кроме rest" ?
Насчёт чуваков, которые округляют глаза на "в GET может быть тело". Я думаю они справедливо их округляют, если они читали RFC7231 или RFC2616:
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
The GET method means retrieve whatever information ([...]) is identified by the Request-URI.
A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
Там как бы в обоих подразумевается, что GET-запрос не может и не должен иметь тело. Это вообще может оказаться неожиданностью для клиента и сервера. А тех, кто так делает надо сжигать на костре прикладывать головой об распечатанный RFC вразумлять и исправлять.
А насчёт "не бывает api кроме rest", я надеюсь вы хотели сказать наоборот, что бывает, но есть те, кто не понимает расшифровки этой аббревиатуры? Ведь так?
Физически может? Может. Что делать с теми, кто применяет - это вопрос отдельный (в основном судить по статье УК РФ), а дыры в безопасности надо уметь закрывать, и знать о таких вещах для этого.
У вас с чувством юмора очень плохо - да, действительно, очень много "программистов" в принципе не понимают что rest это лишь методология, и считают что вообще не бывает никакого api кроме rest (для человека api становится синонимом rest api, даже rest) ?
Чтобы не создавались вышеописаные проблемы, кроме производительности, уже давно существуют принципы SOLID, нарушая которые все вышеприведенные примеры привели к приведенным в примерах проблемам. В случае необходимости достичь максимальной производительности соглашусь, OOP не самый лучший вариант.
Про то, что наследование не следует использовать для повторного использования кода уже кто только не писал - и ГоФ, и Саттер, и Александреску, и Рихтер, и наверняка кто-то еще. Но нет же, продолжаем топтать те же грабли, а потом писать такие вот статьи.
VTable проверяется для динамической диспетчеризации нужного метода в среде исполнения.
У вас очень ошибочное представление о том как работает VTable. Смещение указателя на нужный метод в VTable определяется и известно уже на этапе компиляции и никакой "динамической диспетчеризацией" там даже и не пахнет.
В середине поста автор обещает рассказать нам чем именно опасен метод update, после чего отвлекается на VTable, дальше рассуждает о методе draw в совсем другой иерархии классов... и так и не возвращается к методу update.
Так всё-таки, в чём опасность наследования Player - Character - GameObject?
Проблема в том, что на ООП многое не выразить в нормальной форме. Помоему, время более строгих языков и парадигм, чем ООП.
"ООП мотивирует писать спагетти-код" можно заменить на "ЧТО УГОДНО мотивирует писать спагетти-код"
Ещё не видел, чтобы такие УТВЕРЖДАТЕЛИ написали как же задизайнить сложную систему, чтобы не было проблем (switch вместо наследования? VTable исчезнет, и ему на замену придёт полный пипец :-( ). Когда система начинает становиться слишком сложной (независимо что там ООП, функциональщина, процедурщина, и тд), нужно думать, думать, думать и рефакторить, а на это должны дать добро сверху))
Пусть автор глянет на сложные проекты на процедурщине (я как-то лет 20 назад заглянул в код putty или др терминала - там был сущий ад!!)
Чем плохо ООП (иногда)