Какой смысл писать про ФП — если до сих пор не все знают что такое ООП.
Какие только ответы тут не давались — ООП — это использование объектов, ООП — это использование структур с поведением.
И принципы ООП дискредитировали, в наследование вообще начали считать чем то не до ООП-ным.
Вроде все просто: инкапсуляция + наследование + полиморфизм = ООП.
На базе ООП, реализуются специфические паттерны, которые только в рамках концепции имеют смысл.
Все остальное: использовать ли множественное наследование, что лучше — наследование или делегирование, классы или прототипы — все это вопрос реализации принципов ООП в конкретной технологии.
Ну и чего там относящегося к вопросу, по ссылке, которую Вы дали?
Прочитал — всякие мысли про DTO и т.д.
Все это не имеет отношения к ООП.
Да, DTO с точки зрения ООП не обьекты, потому что не имеют поведения и не могут поддерживать полиморфизм. В ООП само понятие объекта имеет смысл только с точки зрения выполнения его постулатов.
Присутствие наследования требует наличия у объекта характеристик, которые наследуются. Полиморфизма — поведения.
DTO как концепция — это не ОО стиль разработки. Некоторые вещи вообще не разрабатывают в рамках ОО стиля. Например внешние API для широкого круга клиентов обычно пишутся в процедурном стиле, на каком бы языке вы не разрабатывали.
В языке программирования C# у каждого объекта есть внешние интерфейсы доступа. Property — часть таких интерфейсов. Сокрытие деталей реализации осуществляется приватным модификатором доступа. Вот в рамках этих правил разработчик и добивается внутренней согласованности объекта (его состояния и поведения).
Таковы механизмы языка для реализации инкапсуляции. Ими нужно пользоваться.
По поводу наследования подобрал неверное слово — имел ввиду не состояние, а характеристики.
В общем поведение тоже может быть характеристикой, наравне с остальными.
Я не утверждаю что какой то из трех признаков является прерогативой ООП.
Я утверждаю, что ООП определяется вот этими тремя признаками.
Их совместное использование и есть ООП.
Не верите мне — погуглите. Это теория. И не я ее придумал.
Использование объектов без наследования — это например язык C. Можно там объявить структуру, определить у нее поля и методы в виде указателей на функции.
И будет вполне себе полноценный объект. Но это никакое не ООП.
То есть там не имеют смысл ни паттерны ООП (включая SOLID), ни ОО подход к проектированию.
Что касается Haskell и JavaScript — эти языки позволяют разрабатывать в рамках парадигмы ООП и поддерживают в том или ином виде его принципы.
Использовать ли ООП на деле при разработке в рамках этих языков программирования — Ваш выбор, они и многие другие парадигмы тоже поддерживают.
C++ процедурный язык или нет? — процедурная парадигма в нем реализуема и даже «родная». C уж точно не ООП язык — но мы сможем там реализовать ООП с использованием специальных паттернов.
Haskell — как хорошо известно — это функциональный язык программирования.
Но с его помощью можно разрабатывать в рамках ООП используя средства языка.
Можно сказать что в каком то смысле это ООП язык.
Ну то есть я имею ввиду необходимую аксиоматику с точки зрения современного понимания ООП.
Конечно в принципе понятие объекта можно ввести. Но межно обойтись и без него.
То есть объект — это нечто, у которого есть состояние (чтобы работало наследование) и поведение (чтобы работал полиморфизм).
Да не правда все что вы тут говорите.
Присутствие объектов не определяет ООП.
Легко представить себе язык программирования в котором есть объекты, но нет наследования.
И это уже не ООП язык.
В ООП более того понятие объекта вообще не вводится.
Инкапсуляции, наследование и полиморфизм — вот 3 признака ООП.
Если все 3 работают — то это ООП.
Итак, абстракция, инкапсуляция, наследование и полиморфизм — всё это есть в ООП, но ничто из этого не является его неотъемлемым атрибутом.
Что за ерунда — каждый из этих принципов — неотьемлимая часть ООП.
Все вместе они и есть ООП, а не каждый по отдельности.
абстракция, инкапсуляция — это из процедурного стиля можно с натяжкой считать.
наследование и полиморфизм — добавляется и выходит ООП.
Как из C выходит C++.
И не надо говорить что если в каких то ООП языках можно писать в процедурном стиле, то значит ООП не поддерживает все принципы ООП.
Даже такие языки как C# поддерживают не только ООП парадигму, а например функциональный стиль.
Конечно у ООП есть свои недостатки и область применения, но эта статья больше похоже на холивар, чем на серьезное исследование.
По моему автор объелся груш.
getters и setters в Java, properties в C# и т.д. — это часть внешнего интерфейса объекта, наравне с методами. С какого перепугу они нарушают инкапсуляцию?
Это просто вырожденные методы класса.
И они вовсе не позволяют получить беспрепятственный доступ к состоянию объекта.
Настоящее нарушение инкапсуляции это например friendly function в C++.
Или использование рефлексии типов в .net.
Под инкапсуляцией обычно понимают вообще сокрытие деталей реализации а не только состояния объекта.
Например порядок вызова приватных методов в классе тоже может требовать согласованности.
В тоже время поля класса могут быть публичными, открывая к нему доступ. И это не является нарушением инкапсуляции если предусмотрено в архитектуре класса.
Меня МТС обманул вообще очень грубо несколько лет назад.
Однажды утром в 8-10 пришла смс, что положили 200р на счет.
Странно, думаю, надо проверить балланс — там наоборот не хватает 200 рублей.
Звоню оператору и он говорит, что с моего телефона были отправлены 2 платные смс на короткий номер по 200 рублей в 5 утра этого дня. В самом телефоне ничего такого конечно нет.
В отделе МТС мне сказали что кто то случайно отправил. И это могло быть похоже на правду в каких то обстоятельствах — может дети там например. Но вот только некому — жена была в командировке — я сладко спал рядом с телефоном один, никого больше в квартире не было.
Я перебрал в голове и проверил все варианты.
То ли барабашка, то ли лунатизм.
Толи МТС совсем офигел.
Когда же наконец можно будет сохранить номер при переходе между операторами.
Будут ли совершать покупки через телефон тоже интересный вопрос.
В современных картах есть технология pay pass и ей подобные для бесконтактных платежей.
Карта сейчас у всех под рукой как и телефон (по крайней мере в Европе).
Безопасность ясное дело совершенно разная.
Повсеместное использование мобильного телефона для оплаты не кажется мне очевидным в ближайшем будущем.
Хотя если это случится будет круто — решат вопрос всяческого спама с коротких номеров и многочисленных разводов операторов мобильной связи своих клиентов.
Какие у нас тарифы и роуминг для мобильной связи мы знаем. Уровень интеграции мобильных операторов тоже известен (вопрос сохранения номеров при смене оператора).
Интересно как в данный момент обстоят с этим дела в Европе (читай что у нас будет через несклько лет). Не умирает ли там классическая сотовая связь под влиянием дешевого интернета.
Старик Оккама смотрит с неодобрением на концепцию языка c# и платформы .net.
Если мы будем считать что возврат null — это ожидаемое поведение, то нам придется обрабатывать этот null по особенному на всех уровнях приложения. Это будет стоить нам немалых ресурсов. Можно немножко сократить накладные расходы инструментами вроде предложенных автором статьи.
Есть механизмы этого избежать. Я их перечислил. И они работают с разной эффективностью в зависимости от ситуации. Но главная идея — считать что null не может вернуться никогда внутри приложения.
Я ничего не предлагаю ловить. Я предлагаю только кидать, ну или позволить кому то другому кидать.
Ловит пускай комплексная система отлова ошибок в приложении.
На самом деле мой заминусованный комментарий не относился к оценке проделанной Вами работы в демонстрации монады с помощью DSL — тут я снимаю шляпу.
Это был комментарий на конкретный вопрос к тому же не разобравшись полностью.
Я лишь считаю своим долгом обозначить, что надо понимать, что предложенная схема — это решение проблемы, которая имеет классические решения. И предложенное решение все таки не совсем органично смотрится в рамках остального кода. Совсем другой стиль.
Возможно стоит обозначить где именно стоит использовать такой подход.
А где пихать его не стоит. Все таки в биндинге данных на вью — там где описанная Вами проблема особенно актуальна — нам все таки вполне хватает встроенных инструментов.
В зависимости от того, для чего Вам этот объект нужен.
Допустим есть метод который ищет один объект и может его не найти.
Возвращая null вы как бы накладываете на объект 2 ответственности — внешний интерфейс объекта и информация об успехе его поиска. Отсюда и проблемы.
И тут проверка на null как раз отделяет одну ответственность от другой — она необходима.
То есть вы как будто бы запихали в один контейнер 2 объекта а потом разделаете их.
Это как работать с nullable типами в дот нете.
Состояние null не есть часть интерфейса по работе с обьектом. Те, кто работает с ним не должны получить null.
Можно сделать проверку на null после поиска и отправить объект дальше.
Можно использовать шаблон TryDoSomething, который широко используется.
Можно вернуть объект который является null-ом, но поддерживает интерфейс доступа к обьекту (паттерн null object).
Выбирайте.
Есть еще вариант использовать какой то особенный DSL вроде предложенного выше или биндинга для WPF, но такого костыля можно избежать, если сразу грамотно выстроить поведение слоев или модулей приложения.
Писать ReturnSuccess — просто ошибка. Учить этому — преступление против всех разработчиков.
" != null" — писать не совсем красиво. Но это истинное уродство. Это неприятный запах настоящей проблемы: использование null как варианта возвращаемого значения метода, которое каждый раз надо обрабатывать. Вообще null не особенно подходит для обработки как результата операции — он ведет себя не так как остальные объекты. И это порождает дополнительные условия.
Когда пишем ReturnSuccess — прыскаем запах дезодорантом.
Я рекомендую в большинстве случаев считать что null быть не может — и ожидать NullReferenceException или на худой конец ArgumentNullException кидать — и покрывать тестами эти ситуации. А на крайняк использовать паттерн Null Object.
Почитайте про него сначала.
Ассанж был известен задолго до викиликс.
Да и сам проект не имеет и не имел аналогов по объему материала против НАТО. Это совсем не тоже самое что какие то там мелкие скандалы и пару фоток. Это главный банк упреков в сторону штатов со стороны таких стран как Россия, где в основе государства антиамериканская риторика. Теперь всегда можно сказать «Ну и что, а у вас негров бьють».
Ну и конечно тут важны материалы, которые дискредитируют конкретных американских политиков, конечно они будут ему мстить. По моему были открытые угрозы в публикациях.
Те, кто заявляет что ассанж — агент цру — погрязли в параное — так сложно все не бывает.
Автор сказал что на Macbook Pro один порт и для USB 2 и для USB 3, а у других ноутбуков 2 отдельных порта. И вроде как пользователям продукции эппл не нужно переключаться между портами.
Неужели и вправду бывают такие ноутбуки, на которых USB 3 без совместимости с USB 2 или это фантазия автора?
Я думаю Microsoft -у по барабану хорошая технология или плохая в данном случае. Она занимает огромную долю веб девелоперского рынка на дот нете и не развивать её нельзя.
В процессе вымирания на неё будет тратиться все меньше и меньше денег. От поддержки откажутся когда никто не будет уже использовать.
Да совершенно неважно почему.
И уж точно не из-за каких то там уникальных особенностей, менталитета и прочей высокопарной фигни.
Просто менее развитый рынок.
Все что есть на более развитых рынках — приходит на менее развитые с опозданием и только.
Раз в штатах такой сервис заработал — то и у нас заработает. Просто нужно еще несколько лет. Вконтакте поторопились.
Какие только ответы тут не давались — ООП — это использование объектов, ООП — это использование структур с поведением.
И принципы ООП дискредитировали, в наследование вообще начали считать чем то не до ООП-ным.
Вроде все просто: инкапсуляция + наследование + полиморфизм = ООП.
На базе ООП, реализуются специфические паттерны, которые только в рамках концепции имеют смысл.
Все остальное: использовать ли множественное наследование, что лучше — наследование или делегирование, классы или прототипы — все это вопрос реализации принципов ООП в конкретной технологии.
Прочитал — всякие мысли про DTO и т.д.
Все это не имеет отношения к ООП.
Да, DTO с точки зрения ООП не обьекты, потому что не имеют поведения и не могут поддерживать полиморфизм. В ООП само понятие объекта имеет смысл только с точки зрения выполнения его постулатов.
Присутствие наследования требует наличия у объекта характеристик, которые наследуются. Полиморфизма — поведения.
DTO как концепция — это не ОО стиль разработки. Некоторые вещи вообще не разрабатывают в рамках ОО стиля. Например внешние API для широкого круга клиентов обычно пишутся в процедурном стиле, на каком бы языке вы не разрабатывали.
В языке программирования C# у каждого объекта есть внешние интерфейсы доступа.
Property — часть таких интерфейсов. Сокрытие деталей реализации осуществляется приватным модификатором доступа. Вот в рамках этих правил разработчик и добивается внутренней согласованности объекта (его состояния и поведения).
Таковы механизмы языка для реализации инкапсуляции. Ими нужно пользоваться.
В общем поведение тоже может быть характеристикой, наравне с остальными.
Я не утверждаю что какой то из трех признаков является прерогативой ООП.
Я утверждаю, что ООП определяется вот этими тремя признаками.
Их совместное использование и есть ООП.
Не верите мне — погуглите. Это теория. И не я ее придумал.
Использование объектов без наследования — это например язык C. Можно там объявить структуру, определить у нее поля и методы в виде указателей на функции.
И будет вполне себе полноценный объект. Но это никакое не ООП.
То есть там не имеют смысл ни паттерны ООП (включая SOLID), ни ОО подход к проектированию.
Что касается Haskell и JavaScript — эти языки позволяют разрабатывать в рамках парадигмы ООП и поддерживают в том или ином виде его принципы.
Использовать ли ООП на деле при разработке в рамках этих языков программирования — Ваш выбор, они и многие другие парадигмы тоже поддерживают.
C++ процедурный язык или нет? — процедурная парадигма в нем реализуема и даже «родная».
C уж точно не ООП язык — но мы сможем там реализовать ООП с использованием специальных паттернов.
Haskell — как хорошо известно — это функциональный язык программирования.
Но с его помощью можно разрабатывать в рамках ООП используя средства языка.
Можно сказать что в каком то смысле это ООП язык.
Конечно в принципе понятие объекта можно ввести. Но межно обойтись и без него.
То есть объект — это нечто, у которого есть состояние (чтобы работало наследование) и поведение (чтобы работал полиморфизм).
Присутствие объектов не определяет ООП.
Легко представить себе язык программирования в котором есть объекты, но нет наследования.
И это уже не ООП язык.
В ООП более того понятие объекта вообще не вводится.
Инкапсуляции, наследование и полиморфизм — вот 3 признака ООП.
Если все 3 работают — то это ООП.
Что за ерунда — каждый из этих принципов — неотьемлимая часть ООП.
Все вместе они и есть ООП, а не каждый по отдельности.
абстракция, инкапсуляция — это из процедурного стиля можно с натяжкой считать.
наследование и полиморфизм — добавляется и выходит ООП.
Как из C выходит C++.
И не надо говорить что если в каких то ООП языках можно писать в процедурном стиле, то значит ООП не поддерживает все принципы ООП.
Даже такие языки как C# поддерживают не только ООП парадигму, а например функциональный стиль.
Конечно у ООП есть свои недостатки и область применения, но эта статья больше похоже на холивар, чем на серьезное исследование.
По моему автор объелся груш.
Это просто вырожденные методы класса.
И они вовсе не позволяют получить беспрепятственный доступ к состоянию объекта.
Настоящее нарушение инкапсуляции это например friendly function в C++.
Или использование рефлексии типов в .net.
Под инкапсуляцией обычно понимают вообще сокрытие деталей реализации а не только состояния объекта.
Например порядок вызова приватных методов в классе тоже может требовать согласованности.
В тоже время поля класса могут быть публичными, открывая к нему доступ. И это не является нарушением инкапсуляции если предусмотрено в архитектуре класса.
Однажды утром в 8-10 пришла смс, что положили 200р на счет.
Странно, думаю, надо проверить балланс — там наоборот не хватает 200 рублей.
Звоню оператору и он говорит, что с моего телефона были отправлены 2 платные смс на короткий номер по 200 рублей в 5 утра этого дня. В самом телефоне ничего такого конечно нет.
В отделе МТС мне сказали что кто то случайно отправил. И это могло быть похоже на правду в каких то обстоятельствах — может дети там например. Но вот только некому — жена была в командировке — я сладко спал рядом с телефоном один, никого больше в квартире не было.
Я перебрал в голове и проверил все варианты.
То ли барабашка, то ли лунатизм.
Толи МТС совсем офигел.
Когда же наконец можно будет сохранить номер при переходе между операторами.
В современных картах есть технология pay pass и ей подобные для бесконтактных платежей.
Карта сейчас у всех под рукой как и телефон (по крайней мере в Европе).
Безопасность ясное дело совершенно разная.
Повсеместное использование мобильного телефона для оплаты не кажется мне очевидным в ближайшем будущем.
Хотя если это случится будет круто — решат вопрос всяческого спама с коротких номеров и многочисленных разводов операторов мобильной связи своих клиентов.
Интересно как в данный момент обстоят с этим дела в Европе (читай что у нас будет через несклько лет). Не умирает ли там классическая сотовая связь под влиянием дешевого интернета.
Если мы будем считать что возврат null — это ожидаемое поведение, то нам придется обрабатывать этот null по особенному на всех уровнях приложения. Это будет стоить нам немалых ресурсов. Можно немножко сократить накладные расходы инструментами вроде предложенных автором статьи.
Есть механизмы этого избежать. Я их перечислил. И они работают с разной эффективностью в зависимости от ситуации. Но главная идея — считать что null не может вернуться никогда внутри приложения.
Ловит пускай комплексная система отлова ошибок в приложении.
На самом деле мой заминусованный комментарий не относился к оценке проделанной Вами работы в демонстрации монады с помощью DSL — тут я снимаю шляпу.
Это был комментарий на конкретный вопрос к тому же не разобравшись полностью.
Я лишь считаю своим долгом обозначить, что надо понимать, что предложенная схема — это решение проблемы, которая имеет классические решения. И предложенное решение все таки не совсем органично смотрится в рамках остального кода. Совсем другой стиль.
Возможно стоит обозначить где именно стоит использовать такой подход.
А где пихать его не стоит. Все таки в биндинге данных на вью — там где описанная Вами проблема особенно актуальна — нам все таки вполне хватает встроенных инструментов.
Допустим есть метод который ищет один объект и может его не найти.
Возвращая null вы как бы накладываете на объект 2 ответственности — внешний интерфейс объекта и информация об успехе его поиска. Отсюда и проблемы.
И тут проверка на null как раз отделяет одну ответственность от другой — она необходима.
То есть вы как будто бы запихали в один контейнер 2 объекта а потом разделаете их.
Это как работать с nullable типами в дот нете.
Состояние null не есть часть интерфейса по работе с обьектом. Те, кто работает с ним не должны получить null.
Можно сделать проверку на null после поиска и отправить объект дальше.
Можно использовать шаблон TryDoSomething, который широко используется.
Можно вернуть объект который является null-ом, но поддерживает интерфейс доступа к обьекту (паттерн null object).
Выбирайте.
Есть еще вариант использовать какой то особенный DSL вроде предложенного выше или биндинга для WPF, но такого костыля можно избежать, если сразу грамотно выстроить поведение слоев или модулей приложения.
" != null" — писать не совсем красиво. Но это истинное уродство. Это неприятный запах настоящей проблемы: использование null как варианта возвращаемого значения метода, которое каждый раз надо обрабатывать. Вообще null не особенно подходит для обработки как результата операции — он ведет себя не так как остальные объекты. И это порождает дополнительные условия.
Когда пишем ReturnSuccess — прыскаем запах дезодорантом.
Я рекомендую в большинстве случаев считать что null быть не может — и ожидать NullReferenceException или на худой конец ArgumentNullException кидать — и покрывать тестами эти ситуации. А на крайняк использовать паттерн Null Object.
Ассанж был известен задолго до викиликс.
Да и сам проект не имеет и не имел аналогов по объему материала против НАТО. Это совсем не тоже самое что какие то там мелкие скандалы и пару фоток. Это главный банк упреков в сторону штатов со стороны таких стран как Россия, где в основе государства антиамериканская риторика. Теперь всегда можно сказать «Ну и что, а у вас негров бьють».
Ну и конечно тут важны материалы, которые дискредитируют конкретных американских политиков, конечно они будут ему мстить. По моему были открытые угрозы в публикациях.
Те, кто заявляет что ассанж — агент цру — погрязли в параное — так сложно все не бывает.
Неужели и вправду бывают такие ноутбуки, на которых USB 3 без совместимости с USB 2 или это фантазия автора?
В процессе вымирания на неё будет тратиться все меньше и меньше денег. От поддержки откажутся когда никто не будет уже использовать.
Выбрал первый вариант потому что я так привык.
Думаю большинство так же голосовали.
А разработчиков которые используют преимущественно языки программирования со скобками гораздо больше.
И уж точно не из-за каких то там уникальных особенностей, менталитета и прочей высокопарной фигни.
Просто менее развитый рынок.
Все что есть на более развитых рынках — приходит на менее развитые с опозданием и только.
Раз в штатах такой сервис заработал — то и у нас заработает. Просто нужно еще несколько лет. Вконтакте поторопились.