Примеры. Допустим, некто спрашивает, зачем нужно наследование интерфейсов. Я привожу пример, когда оно нужно. В ответ приводится пример, как то же самое можно сделать без наследования интерфейсов. История, конечно, вымышлена, все возможные совпадения случайны. Как хотите, а для меня такой ответ — признак полнейшего непонимания ООП. Оно нужно не потому, что без него не обойтись, и не потому, что сокращает количество кода, и не потому, что что-то там гарантирует (на любую хитрую жопу, как известно всегда что-нибудь найдется). Любой ОО-код переписывается в процедурный роботом на автомате. Не говоря про машину Тьюринга. А нужно оно только для того, чтобы сделать код чуточку понятнее любому нубу на проекте (в том числе, клиентам библиотек/фреймворков/сервисов). Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.
Другой пример. Когда я обсуждал эту (конечно же, чисто гипотетическую) ситуацию, один человек прямо сказал: все дело в бэкграунде. У тебя, грит, оопный бэкграунд, а придет нуб с функциональным бэкграундом и скажет — ни хрена непонятно. А были бы, грит, чистые функции, он бы все понял мгновенно. И такое высказывание для меня другой признак непонимания ООП. Во-первых, ООП не находится в антагонистических отношениях с ФП. Они отлично уживаются, просто потому, что нужны в разных местах. Во-вторых, НЕТ, НЕПРАВДА, с любым бэкграундом (ФП, ООП, лапша) проект, выдержанный в ОО-духе понять легче. Просто потому, что мы мыслим объектами.
На протяжении долгих лет я встретил ровно одного человека, который излагал (насколько я его понял) то же самое — Эрика Липперта. По удивительному совпадению (это сарказм), кокреатора одного из лучших языков — C#, а также отца Roslyn. На следы жизнедеятельности таких людей я натыкался чаще (взять тот же .NET FCL), но не сильно. Так вот, не дайте угаснуть моей вере в человечество или добейте ее окончательно.
Здравствуйте, SV., Вы писали:
SV.>...и это невероятно печально.
SV.>На протяжении долгих лет я встретил ровно одного человека, который излагал (насколько я его понял) то же самое — Эрика Липперта. По удивительному совпадению (это сарказм), кокреатора одного из лучших языков — C#, а также отца Roslyn. На следы жизнедеятельности таких людей я натыкался чаще (взять тот же .NET FCL), но не сильно. Так вот, не дайте угаснуть моей вере в человечество или добейте ее окончательно.
> А нужно оно только для того, чтобы сделать код чуточку понятнее любому нубу на проекте (в том числе, клиентам библиотек/фреймворков/сервисов). Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.
С какого перепугу наследование стало ближе к предметной области, чем к примеру копипастинг? Если бы интерфейсы можно было бы произвольно комбинировать и декомбинировать, это было бы ближе, но наследование и подгонка предметной области под наследование это клиника.
Здравствуйте, SV., Вы писали:
SV.>А нужно оно только для того, чтобы сделать код чуточку понятнее любому нубу на проекте (в том числе, клиентам библиотек/фреймворков/сервисов). Чтобы было можно быстрее сопоставить примитивы в коде со знанием предметной области. Все.
ООП само по себе не делает код понятнее.
оно *может* сделать код понятнее, если его применить там где его надо применить,
и можте сделать код запутаннее, если его применить там где его не надо применять.
да, мало людей понимает ООП.
есть много людей которые не понимают ООП, *не* применяют его там где надо, и получают сложный код,
и есть люди которые плохо понимают ООП, применяют его там где *не* надо, и тоже получают сложный код.
Хотя бы посмотрите насколько библиотечные интерфейсы соответствуют предметной области, они соответствуют не более чем процентов на 20-30, это можно оценить по доле используемых в прикладной программе членов этих интерфейсов. Это вот как раз и показывает, что наследование это негодный механизм, от которого необходимо уходить.
Чего это я шашкой-то размахался... Ну да, библиотечные интерфейсы преметной области перпендикулярны, но отрицать наследование еще пожалуй рано, нужно сначала придумать что-то получше
Здравствуйте, Abyx, Вы писали:
A>да, мало людей понимает ООП. A>есть много людей которые не понимают ООП, *не* применяют его там где надо, и получают сложный код, A>и есть люди которые плохо понимают ООП, применяют его там где *не* надо, и тоже получают сложный код.
Я скажу проще: мало людей умеет хорошо программировать.
Хороший программист сделает понятным код и с ООП и без него.
Плохой программист сделать непонятным код и с ООП и без негою
Здравствуйте, 0x7be, Вы писали:
A>>есть много людей которые не понимают ООП, *не* применяют его там где надо, и получают сложный код, A>>и есть люди которые плохо понимают ООП, применяют его там где *не* надо, и тоже получают сложный код. 0>Я скажу проще: мало людей умеет хорошо программировать. 0>Хороший программист сделает понятным код и с ООП и без него.
нет. хороший программист не сделает код понятным там, где без ООП он будет непонятным.
чтобы закрутить шуруп, нужна именно отвертка, а не молоток,
шуруп забитый молотком будет держаться хуже, вне зависимости от ваших личных качеств.
Здравствуйте, Abyx, Вы писали:
A>нет. хороший программист не сделает код понятным там, где без ООП он будет непонятным.
Приведи пример.
A>чтобы закрутить шуруп, нужна именно отвертка, а не молоток, A>шуруп забитый молотком будет держаться хуже, вне зависимости от ваших личных качеств.
Аналогия так себе
пруф?
видимо сама жизнь подтверждает несостоятельность этого утверждения коль скоро вы пришли к выводу, озвученном в сабже.
В конце концов ООП это не silver bullet, ООП довольно легко применить не к месту — "когда в руке молоток все становится похожим на гвоздь".
Функциональное программирование позволяет более понятно и просто решать некоторый класс задач:
When you anticipate a different kind of software evolution:
Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.
Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.
Примеры достаточно хорошо изложены в SICP (я его читал не весь) из которого запомнилось подход к написанию кода, выполняющего символьное диффиренцирование.
Опять же, появление мощных средств пришедших из ФП в C#, таких как замыкания и LINQ говорят сами за себя.
Здравствуйте, A13x, Вы писали:
A>Опять же, появление мощных средств пришедших из ФП в C#, таких как замыкания и LINQ говорят сами за себя.
В джава нет полной поддержки концепции замыканий и нет никакого линка. И тем не менее это самый популярный язык на планете. А ему то всего чуть более 15 лет. А вот функциональные языки существуют уже почти полвека и до сих пор используются исключительно для решения задач определённого класса. Никому не придёт в голову писать корпоративную систему в целом на лиспе/эрланге/хаскеле... Это говорит за себя куда как более весомо чем вкрапления нескольких особенностей в C#.
Здравствуйте, 0x7be, Вы писали:
A>>нет. хороший программист не сделает код понятным там, где без ООП он будет непонятным. 0>Приведи пример.
императивный язык,
мутабельные данные, которые надо менять по определенным алгоритмам, которые использует несколько частей программы.
попытка применить чистые функции выродится в вызовы
data1, data2, data3 = some_pure_fn(data1, data2, data3)
итого мы получим кучу мелких чистых функций и другую кучу не-чистых функций
попытка применить процедурный подход сведется к использованию абстрактного типа данных, т.е. ООП.
пример из реальной жизни — файлы, сокеты и другие источники/приемники данных
Здравствуйте, A13x, Вы писали:
A>Функциональное программирование позволяет более понятно и просто решать некоторый класс задач:
A>
A>When you anticipate a different kind of software evolution:
A>Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.
A>Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.
A>Примеры достаточно хорошо изложены в SICP (я его читал не весь) из которого запомнилось подход к написанию кода, выполняющего символьное диффиренцирование.
на словах всё хорошо, а на практике, с одной стороны — императивное железо, с другой стороны — мутабельные объекты предметной области.
вот и работает ФП только для задач типа символьного дифференцирования,
а чтобы что-то из реальной жизни описать, или быстро md5 посчитать — это нет, тут только С#/джава или C/C++
Наверное в своей первой же программе вы сразу стали использовать ООП, точнее одну из его реализаций, ведь то как реализовано ООП может отличаться в разных языках (Вопрос для самоконтроля: сколько разных реализаций ООП Вы можете назвать?). То есть я подозреваю, что именно от того, что Вы сразу начали использовать ООП, Вы и считаете, что это хорошо и правильно, а вовсе не потому, что ООП действительно объективно такое хорошее.
Здравствуйте, Steamus, Вы писали:
S>Здравствуйте, A13x, Вы писали:
A>>Опять же, появление мощных средств пришедших из ФП в C#, таких как замыкания и LINQ говорят сами за себя.
S>В джава нет полной поддержки концепции замыканий и нет никакого линка. И тем не менее это самый популярный язык на планете.
К слову, Jetbrains, собаку съевшая на яве, сейчас активно делает Kotlin, а так же развивает MPS.
И я не спорю, что ООП — это плохо, а ФП — панацея, просто есть разные случаи, когда к месту разные инструменты.
Здравствуйте, 0x7be, Вы писали:
SV.>>Просто потому, что мы мыслим объектами. 0>А это точно правда?
Это называется "понятийное мышление". В норме человек к 5 годам им овладевает в степени, достаточной для повседневного применения. У кого-то оно развито сильнее, и ему можно доверить проектирование. У кого-то слабее, и он может разве что воспользоваться результатами чужого труда по декомпозиции. Но когда совсем никак — это патология. Тот же функциональный подход с такими отклонениями не осилить, потому, что он требует еще большей изощренности.
Если нам не помогут, то мы тоже никого не пощадим.
