maytonНо я надеюсь что таких тех-лидов мы будем видеть все меньше и меньше.

Надеюсь, этот очередной абсолютно бестолковый крестово-похоронный демарш, объясняется пятницей

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

P.S. Какие ваши доказательства? (с)

Ну давайте, пройдёмся:

mayton Существует тренд веб-программирования. Он основан на упрощенной модели
объекта. Объекта прототипа. Лишенного каких либо строгих правили проектирования.
ПО сути веб-программист оперирует микро-хеш-тебличками в узлах которых
лежат произвольные безтиповые сущности. Могут быть полем. Либо функцией (методом).
Веб программирование - многолико. Оно не обязательно основано на JavaScript.
И оно не обязательно стоит в стеке браузера. Часть его - охватывает бэк-енд.
С теми-же либеральными правилами.

Если оперировать словом «тренд» таким образом, тогда можно сказать, что существуют ещё такие тренды, как «поесть», «поспать», «поссать» Веб-программирование, как и любое другое программирование, на чём угодно, и где угодно, основано на решении поставленных задач, автоматизация. Не более, и не менее. ООП не служит здесь взаимоисключающим фактором, и никак не претит вашим либеральным правилам. Хотите говнокодить? Вам никто не запрещает. Чтобы поковырять у себя в носу и запилить убогенький сайтик, вам ООП не нужен, это совершенно точно. Как 99% других требуемых квалифицированному разработчику знаний.

Не аргумент.

mayton Существует тренд декларативного программирования на аннотациях (как один
из способов взаимодействия с АОП). Аннотации полностью разрушают идеологию ООП.
Они игнорируют (или обладают такой способностью) языковые иерархии классов.
Они способны полностью поменять семантику зависимостей между классами. Они
способны внедрить невидимый интерфейс. Создать невидимый прокси. Добавит
логгинги, транзакции и политики безопасности. И все это - перпендикулярно ООП.
Тоесть вне закона ООП. Этот тренд поддерживают современные Java/C# в виде
синтаксиса и фреймворков.

Аспекты отлично дополняют ООП. Это не взаимоисключающие понятия, в текущих реализациях АОП работают поверх ООП и даже в терминах ООП.


maytonСуществует давление т.н. функционального программирования . Интерес к нему
периодически то понимается то спадает каждые 5-7 лет. Но совершенно очевидно
что растущие ресурсы датацентров создают условия для того чтобы запускать
в проуктив смелые и экспериментальные проекты на которые раньше все время
чего-то не хватало. Сегодня - оптимизация for/while циклов чтобы добыть лишние
несколько тактов CPU перестала быть актуальной. Скорость внедрения решения
в прод. - для бизнеса важнее. Сюда-же до кучи Spark/BigData - как одну из имплементаций.
Компилляторы стали умнее. Стали видеть намного уровней дальше. И человек (программист)
как винтик этой системы в части оптимизации - выпал. Он - не нужен. Пускай он лучше
думает над логикой верхнего уровня. We trust in compiller, bro!

ХЗ вообще что вы тут хотели сказать. Какое-то пустое разглагольствование.


maytonСуществует интерес к т.н. акторному программированию (Erlang/Sony-Ericson как один
из примеров имплементации). Полностью лишая логику состояния - он постулирует
чистый рафинированный мир тестабельных компонент. Есть месседжи. И есть компоненты
акторы. Эдакий себе Rest в пределах кристалла процессора. В довершение ко всему
акторное программирование выводит новый уровень "отказоустойчивости" из коробки.
Как вам? Потрясающе! И где здесь ООП? Месседжи? Ничего подобного. Это POJO. Или
Records(Pascal). Или Tuples. Никакой инкапсуляции. Акторы? Возможно. Но с натяжкой.
Ибо мало мотиваций. Для системы в которой единицей информации являются Tuples.

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

Инкапсуляция заложена не только в ООП, это вообще основа абстракции. А бизнесу вообще на ваши Tuples и месседжи глубоко накласть, в реальном мире существует таксономия, объекты и состояния. Просто в одно время евангелисты, проталкивающие ООП в массы слегка переусердствовали, создав впечатление, что ООП призван полностью отражать модель реального мира.


maytonСуществует интерес к тестированию на Mocks(Mokito) . Которое "срезает кожу" с ООП.
Оно "ломает" правила private. Шпионит за методами. Вобщем полный набор мозговых
извращений.

Бред какой-то. Если у какого-то человека руки растут из одного места, с кривизной, достойной восхищения Пьера Безье, то это вообще никак не аргумент. У нас в проекте более тысячи тестов. Покрытие ~90%, ни одного теста, который бы лез в private тестируемого компонента. Никто ни за чем, ни шпионит. Все компоненты тестируются изолировано. Для интеграционных тестов всё ещё проще.


maytonООП - корчится. Ему нечего сказать в ответ. Оно - осталось в пыльных библиотеках
университета в виде толстых и умных книжек года эдак 2000-го про системный анализ или может
быть про ООП в С++. Или в старых изданиях Java.

Ни одного аргумента, который хотя бы выглядел как более менее адекватный, я не увидел. Странные набросы, пространные рассуждения ни о чём, перевирание и притягивание за уши не совместимых друг с другом фактов.


maytonОно еще осталось в виде дурацких вопросах на собеседовании. Где тех-лид с умным видом
может вас спросить про "ромбовидное наследование" или про матрицу видимости public/protected/private.
Это ... если захочет вас окончательно макнуть в грязь...

Элементарщина какая-то. Если кого-то этим можно макнуть в грязь, то у меня для него печальные новости. Пусть шурует в дворники и не позорится.

maytonПросто теорию еще не подогнали под общий знаменатель.

Этого никогда не случится. Всё течёт, всё меняется. Когда-то ООП возводили в абсолют. Сейчас он просто встал в строй.

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

mayton - Никакого ООП не существует. ООП - это миф. Это обычное процедурное программирование
где каждый метод имеет неявный аргумент this.

Никаких людей не существует. Это просто набор атомов.

maytonЭто самый неудачный термин. Он является причиной очень многих заблуждений и непониманий ООП. Буквальный перевод
уводит нас в генетику и биологию. Области которые вообще ни краем не цепляют идею ООП. И ладно если собака наследует
волка (интересно почему не наоборот?). Еще не дай бог в примерах напишут что цыпленок наследует свойства курицы.

Непонимание происходит от недостатка опыта и знаний. Не более того.
Найти виноватого в своём невежестве, это подход ребёнка.

maytonПо поводу многоуровневого наследования. У меня есть личная неприязнь к подобного рода проектированию.
Это - хуже чем goto. Особенно когда отладчик перемещает вас вверх-вниз по иерархии. Честное слово! Лучше
композиция . Руки хочется поотбивать таким горе-кодерам.

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

mayton - Не существует никакого математического доказательства пользы от внедрения ООП.
Есть просто наша вера в то что ООП - это хорошо. Мы никогда не сравнивали два проекта ООП-не-ООП.
Никогда не меряли velocity Scrum-команд работающих в одинаковых условиях с ООП и не ООП.

ООП это не хорошо и не плохо, это лишь инструмент. Один из. Неумение его использовать -- не основание набрасывать на вентилятор. Есть такое понятие: испытание временем. Всё, что приносит пользу и эффективно остаётся, остальное умирает. Мы больше не ездим на колесницах с деревянными колёсами, правда? И нет никаких причин устраивать какие-то исследования и сравнения, просто более прогрессивное и эффективное вытеснило устаревшее и неэффективное. ООП пока никто вытеснять и не думал, успешно применяется до сих пор.

mayton - Множественное наследование - это "бантик сбоку".

Множественное наследование реализации мало где поддерживается. Множественное наследование контрактов, поддерживается очень хорошо, и пользу трудно переоценить.


maytonОб инкапсуляции типа private . Существует точка зрения, что кодер который поставил private
особым образом уведомляет нас о том что это поле нельзя смотреть. И изменять. Висит груша - нельзя скушать. Почти готов
согласиться с утверждением. Однако я-бы смягчил требования инкапсуляции и сделал их
рекомендательными. На уровне warnings компиллятора. Ну если разработчику очень нуна - все
равно дизассемблирует.

Вы абсолютно не понимаете зачем нужна инкапсуляция, зачем нужен private. К чему эти рассуждения?