Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 106
ООП — это инструмент и философия. А еще это музыка программирования. :) Хотя мои ощущения с того времени немного сместились, поскольку я изучил функциональное программирование.
> Не удержав себя от сравнения процедурного и объектно-ориентированного подхода, я задался простым вопросом — где бы я мог использовать процедурный подход, вместо объектного? Если честно, то я не знаю такие области, в которых ООП явно проигрывало функциональному подходу
Вы здесь несколько путаете читателей. Функциональный и процедурный подход — разные вещи.
> Не удержав себя от сравнения процедурного и объектно-ориентированного подхода, я задался простым вопросом — где бы я мог использовать процедурный подход, вместо объектного? Если честно, то я не знаю такие области, в которых ООП явно проигрывало функциональному подходу
Вы здесь несколько путаете читателей. Функциональный и процедурный подход — разные вещи.
Да, спасибо, про путаницу в процедурном и функциональном подходе мне уже объяснили. Дело в том, что я не большой специалист в области функционального программирования, поэтому и спутал. Изначально, наверное, не стоило подходить к сравнению таких вещей.
Есть в планах задачка, которую хочется попробовать сделать, применив функциональный подход. Тогда, наверное, и к ООП отношение поменяется вновь
Есть в планах задачка, которую хочется попробовать сделать, применив функциональный подход. Тогда, наверное, и к ООП отношение поменяется вновь
На самом деле, если код пишется хорошо, в нем функциональщина появляется сама собой. И это возникакет одинаково часто как при процедурном подходе, так и при ООП-подходе. Очень интересны с этой точки зрения шаблоны проектирования. Они оперируют терминами ООП (классы, взаимодействие), а реализуют вполне функциональный подход. Хотя, конечно, не в чистом виде.
Все хорошо, но вот тут:
Процедурный (императивный) и фнукциональный — совершенно разные подходы к программированию. Не мешайте их в одну кучу, пожалуйста.
сравнения процедурного и объектно-ориентированного подхода, я задался простым вопросом — где бы я мог использовать процедурный подход, вместо объектного? Если честно, то я не знаю такие области, в которых ООП явно проигрывало функциональному подходу
Процедурный (императивный) и фнукциональный — совершенно разные подходы к программированию. Не мешайте их в одну кучу, пожалуйста.
Тем неменее, не лишним будет напомнить читателю, что ООП, ФП и императивная парадигмы в некоторых языках вполне себе сосуществуют. Например, в OCaml, F#, Lisp.
Но я почему-то в некоторой степени пурист в плане парадигм.
Но я почему-то в некоторой степени пурист в плане парадигм.
От себя хочу добавить, что у абстрактных типов данных (АТД) какого-нибудь Haskell больше общего с классами ООП, чем различий. Подробнее об этом можно прочитать здесь.
И да, забавно слышать рассуждения автора о различиях ФП и ООП, если он путает ФП с процедурным программирование.
И да, забавно слышать рассуждения автора о различиях ФП и ООП, если он путает ФП с процедурным программирование.
Learn You a Haskell For Great Good: Type Classes 102:
Remember that type classes have nothing to do with classes in languages like Java or Python. This confuses many people, so I want you to forget everything you know about classes in imperative languages right now!
> Каждый этап калькуляции — это объект, который будет участвовать во всем процессе.
Тут то есть проблема. Объекты и классы придуманы для удобной связи состояния и поведения с поддержкой сокрытия первого. Когда нет состояния (как в случае если объект представляет собой шаг вычислений) все ОО конструкции теряют смысл. Остаётся только ритуал создания объекта не имеющий ничего общего с задачей.
> Для общения между шагами, чтобы дать им возможность обмениваться данными, создадим еще один вспомогательный объект, который будет хранить в себе все промежуточные рассчеты.
На самом деле в подавляющем большинстве языков такой объект уже создан. Называется стэк :)
Тут то есть проблема. Объекты и классы придуманы для удобной связи состояния и поведения с поддержкой сокрытия первого. Когда нет состояния (как в случае если объект представляет собой шаг вычислений) все ОО конструкции теряют смысл. Остаётся только ритуал создания объекта не имеющий ничего общего с задачей.
> Для общения между шагами, чтобы дать им возможность обмениваться данными, создадим еще один вспомогательный объект, который будет хранить в себе все промежуточные рассчеты.
На самом деле в подавляющем большинстве языков такой объект уже создан. Называется стэк :)
Тут то есть проблема. Объекты и классы придуманы для удобной связи состояния и поведения с поддержкой сокрытия первого. Когда нет состояния (как в случае если объект представляет собой шаг вычислений) все ОО конструкции теряют смысл. Остаётся только ритуал создания объекта не имеющий ничего общего с задачей.
А это уже не ООП, а технология использования языка. Как пример — паттерн DAO.
На самом деле в подавляющем большинстве языков такой объект уже создан. Называется стэк :)
Если это про стек вызовов, то использовать его в некоторых ситуациях чудовищно неудобно.
На самом деле злоупотребление всякими сервисами превращает доменную модель в классы с набором геттеров и сеттеров. Она не несет в себе никакой смысл, ее трудно понимать, напрмер, нельзя сказать, что же можно сделать с этим объектом, а что нет. Есть даже термин такой — anemic domain model. У Фаулера есть интересная статейка об этом
Как раз, чтобы программисту развиваться — ему надо совершать ошибки. Пусть лучше добавит лишней ответственности классу и потом на этом научится, чем будет просто писать сервисы.
В дополнение к минусам сервисов — неудобно писать тесты. Неизвестно, какие правила создания объектов и можно создать невалидный объект и подпихнуть его сервису. При богатом домене часто валидация происходит в момент создания.
В дополнение к минусам сервисов — неудобно писать тесты. Неизвестно, какие правила создания объектов и можно создать невалидный объект и подпихнуть его сервису. При богатом домене часто валидация происходит в момент создания.
Проблему ADM против «наделение сущностей предметной области поведением, не относящимся на прямую к ним» может решить парадигма DCI (http://en.wikipedia.org/wiki/Data,_Context_and_Interaction).
Если кратко, то следует задуматься о том, что кроме самих объектов есть ещё роли, которые они играют и с точки зрения программирования выгодно разделить объект предметной области (не несущий функционала специфичного для юз кейсов программы) и роли (которые уже несут специфичный функционал).Это не единственная и не главная идея DCI, там есть ещё несколько клёвых, например о явном выделении шагов алгоритма (юз кейса), за что часто ругают ооп (вот у нас есть много объектов со многимим методами, а как понять когда и как они используются).
Если кратко, то следует задуматься о том, что кроме самих объектов есть ещё роли, которые они играют и с точки зрения программирования выгодно разделить объект предметной области (не несущий функционала специфичного для юз кейсов программы) и роли (которые уже несут специфичный функционал).Это не единственная и не главная идея DCI, там есть ещё несколько клёвых, например о явном выделении шагов алгоритма (юз кейса), за что часто ругают ооп (вот у нас есть много объектов со многимим методами, а как понять когда и как они используются).
Сейчас все больше пытаюсь закопаться в объектно-ориентированное программирование, но никак не могу нормально представить, как решается такая простая задача через ООП, как следующая (такие задачи приходиться решать очень часто по ходу работы). Скажите ваше мнение как её элегантно решить через ООП?
Дано: список Работников, у класса Работник есть свойство Дети, у ребёнка есть поле Возраст и Пол.
На новый год начальство решило сделать подарки детям до 14 лет. От нас требуется составить список детей работников (группируем по полу, т. к. подарки должны быть разные). Учитывать, что на фирме может работать оба родителя, но подарок должен быть один.
Очень хотел бы взглянуть на вашу версию реализации данной задачи. Ко мне в голову приходят десятки классов, особенно учитывая принципы SOLID и т. п. Хотя как я узнал — через «функциональщину» это решается парой функций.
Дано: список Работников, у класса Работник есть свойство Дети, у ребёнка есть поле Возраст и Пол.
На новый год начальство решило сделать подарки детям до 14 лет. От нас требуется составить список детей работников (группируем по полу, т. к. подарки должны быть разные). Учитывать, что на фирме может работать оба родителя, но подарок должен быть один.
Очень хотел бы взглянуть на вашу версию реализации данной задачи. Ко мне в голову приходят десятки классов, особенно учитывая принципы SOLID и т. п. Хотя как я узнал — через «функциональщину» это решается парой функций.
При чем тут ООП?
Где эти данные хранятся, в памяти всегда (на Smalltolke пописываете)? Если в базе, то посмотрите в сторону en.wikipedia.org/wiki/Active_record_pattern или martinfowler.com/eaaCatalog/dataMapper.html
Если вас интересует реализация какого-то языка запросов на объектах, посмотрите как это было реализовано в Hibernate или github.com/rails/arel. Согласен все эти gt, lt выглядят чужеродно, но не стоит забывать, что это надстройки над декларативным SQL (диктовалось требованиями совместимости с интерфесом).
Где эти данные хранятся, в памяти всегда (на Smalltolke пописываете)? Если в базе, то посмотрите в сторону en.wikipedia.org/wiki/Active_record_pattern или martinfowler.com/eaaCatalog/dataMapper.html
Если вас интересует реализация какого-то языка запросов на объектах, посмотрите как это было реализовано в Hibernate или github.com/rails/arel. Согласен все эти gt, lt выглядят чужеродно, но не стоит забывать, что это надстройки над декларативным SQL (диктовалось требованиями совместимости с интерфесом).
Это задача проще всего решается на SQL ИМХО.
Коллекция (список, массив) объектов Ребёнок, объекты Работник имеют свойство Дети — список или массив ссылок на объекты Ребёнок из первой коллекции.
Формируем пустые массивы или списки Мальчики и Девочки.
Идем по списку Работники, далее по списку Дети конкретного работника, проверяем возраст и, если подходит, то в зависимости от пола помещаем его в список Мальчики или Девочки, если его там ещё нет.
Главное использовать агрегацию, а не композицию. Объект Работник должен ссылаться на объект Ребёнок, а не содержать его.
Формируем пустые массивы или списки Мальчики и Девочки.
Идем по списку Работники, далее по списку Дети конкретного работника, проверяем возраст и, если подходит, то в зависимости от пола помещаем его в список Мальчики или Девочки, если его там ещё нет.
Главное использовать агрегацию, а не композицию. Объект Работник должен ссылаться на объект Ребёнок, а не содержать его.
*помещаем ссылку на него в список Мальчики или девочки, если её ещё там нет.
Ваш коммент почему-то наводит на мысли о тяжелом 1Сном детстве :)
Детство у меня было на ASM-8080 и BASIC
Вот не пойму за что минусуют. Вроде задачу решил, или нужно приводить работающий код? Или мой алгоритм избыточен или сильно не оптимален?
Как по мне, здесь достаточно 4 классов: Работник, Ребенок и две колекции для работы с двумя предыдущими классами. Список детей тут будет узнать проще простого: если ребенок есть в базе (он не сирота ведь) — значит родители работают на предприятии. Просто выбираем коллекцией детей всех детей до 14 лет, берем у них свойство родитель и даем родителю подарок для соответствующего пола. Т.е. плящем именно от ребенка. Конкретная реализация всего этого зависит от языка и фреймворка на котором вы будете это писать.
Можно попробовать взглянуть на проблему используя те идеи, что предлагает автор статьи и попытаться выделить ключевые концепции, помня, что объектами могут быть не только некие существительные, но и процессы/действия.
Получим примерно такой список сущностей с которыми нам придётся оперировать:
— самое очевидное это: Сотрудник, Ребёнок;
— раз мы дарим подарки то нам надо их как-то обозначить, соответсвенно появляется — Подарок;
— так как нам надо выбирать подарок для ребёнка основываясь на каких то правилах, которые могут в том числе и поменяться, то надо бы изолировать способ выбора подарка в отдельную сущность, например, ВыбиралкаПодарка. Всё что она делает — получает на вход Ребёнка и возвращает для него Подарок;
— так как нам надо как-то связать Подарок и Ребёнка, то появится, например, сущность ПодарочныйСертификат;
— так как нам необходим сам процесс раздачи подарков детям, то появится сущность которая перебирает этих самых Сотрудников и для каждого Ребёнка этого самого сотрудника с помощью ВыбиралкиПодарков выбирает этот самый Подарок. Назовём этот процесс РаспределительПодарков;
— но так как в чистой теории Подарки выбираются не из воздуха, то появляется некое ХранилищеПодарков из которого этот самый РаспределительПодарков будет таскать Подарки и скорее всего надо бы учесть что Подарки иногда могут и закончиться :(
— сам по себе процесс выбора Подарка с помощью ВыбиралкиПодарков и последующее получение Подарка из ХранилищаПодарков с последующей выдачей этого Подарка Ребёнку (т.е. созданием ПодарочногоСертификата) тоже весьма хороший кандидат на выделение в отдельную сущность, назовём его мммм… ВыдавательПодарочныхСертификатов :)
— если мы хотим быть справедливыми и выдать каждому Ребёнку по Подарку и никого при этому не забыть или никому не дать два, то нам надо ещё какая-нибудь структурка где мы будем хранить сведения о том кому чего дали. А если учесть что Подарки у нас в ХранилищеПодарков могут и кончиться, а потом опять появиться (мало ли завезли ещё) то она будет вообще полезной штуковиной.
Понятное дело что результатом работы РаспределителяПодарков будет список ПодарочныхСертификатов. Если надо сгенерировать только список то ХранилищеПодарков можно выкинуть.
Вроде всё :)
Получим примерно такой список сущностей с которыми нам придётся оперировать:
— самое очевидное это: Сотрудник, Ребёнок;
— раз мы дарим подарки то нам надо их как-то обозначить, соответсвенно появляется — Подарок;
— так как нам надо выбирать подарок для ребёнка основываясь на каких то правилах, которые могут в том числе и поменяться, то надо бы изолировать способ выбора подарка в отдельную сущность, например, ВыбиралкаПодарка. Всё что она делает — получает на вход Ребёнка и возвращает для него Подарок;
— так как нам надо как-то связать Подарок и Ребёнка, то появится, например, сущность ПодарочныйСертификат;
— так как нам необходим сам процесс раздачи подарков детям, то появится сущность которая перебирает этих самых Сотрудников и для каждого Ребёнка этого самого сотрудника с помощью ВыбиралкиПодарков выбирает этот самый Подарок. Назовём этот процесс РаспределительПодарков;
— но так как в чистой теории Подарки выбираются не из воздуха, то появляется некое ХранилищеПодарков из которого этот самый РаспределительПодарков будет таскать Подарки и скорее всего надо бы учесть что Подарки иногда могут и закончиться :(
— сам по себе процесс выбора Подарка с помощью ВыбиралкиПодарков и последующее получение Подарка из ХранилищаПодарков с последующей выдачей этого Подарка Ребёнку (т.е. созданием ПодарочногоСертификата) тоже весьма хороший кандидат на выделение в отдельную сущность, назовём его мммм… ВыдавательПодарочныхСертификатов :)
— если мы хотим быть справедливыми и выдать каждому Ребёнку по Подарку и никого при этому не забыть или никому не дать два, то нам надо ещё какая-нибудь структурка где мы будем хранить сведения о том кому чего дали. А если учесть что Подарки у нас в ХранилищеПодарков могут и кончиться, а потом опять появиться (мало ли завезли ещё) то она будет вообще полезной штуковиной.
Понятное дело что результатом работы РаспределителяПодарков будет список ПодарочныхСертификатов. Если надо сгенерировать только список то ХранилищеПодарков можно выкинуть.
Вроде всё :)
Вот это я никогда не понимал, получается, если выделять таким образом сущности, выделять ответственности конкретные ответственности и т. п. То в итоге мы приходим к тому, что у нас есть множество классов, которые содержат по одному методу (без какого-либо состояния) (например: ВыбиралкаПодарка, ВыдавательПодарочныхСертификатов, РаспределителяПодарков). Но для чего тогда нужен сам класс, почему нельзя просто создать отдельный метод, который назвать ВыбратьПодарок, ВыдатьПодарочныйСертификат, РаспределитьПодарки. Если нужно деление — делите на мелкие функции, внутри этой задачи (метода), зачем их выносить отдельно на тот же уровень абстракции, что и сущности, причем чаще всего такие вспомогательные методы больше никто и никогда не будет использовать (они очень и помечаются как private). Если нужно группировать такие функции, используйте Модули, Namespace'ы и т. п.
Чем такой подход — создание виртуального существительного для реализации глагола, лучше чем создания отдельного глагола? Ведь нам не важно, кто или что раздает подарки, нам важен алгоритм отбора и раздачи подарков, зачем его прятать за виртуальными сущностями?
Чем такой подход — создание виртуального существительного для реализации глагола, лучше чем создания отдельного глагола? Ведь нам не важно, кто или что раздает подарки, нам важен алгоритм отбора и раздачи подарков, зачем его прятать за виртуальными сущностями?
хорошо, допустим мы сделаем так, как вы предлагаете, и оставим всё в одном классе но разобьём всё на кучку методов. Что вы будете делать когда вас попросят раздавать подарки не только на Новый Год но и, допустим, на Рождество и выбирать надо будет по абсолютно разным критериям?
И сразу про YAGNI. Эта задача, в том, вырванном из контекста виде, в каком нам её показали, понятное дело абсолютно прекрасно решается вообще без какого-либо ООП и прочего, но, раз уж мы договорились о том, что будем использовать для её решения ООП, давайте всё же предполагать что это часть какой-то большой системы которая претендует пережить один запуск.
И сразу про YAGNI. Эта задача, в том, вырванном из контекста виде, в каком нам её показали, понятное дело абсолютно прекрасно решается вообще без какого-либо ООП и прочего, но, раз уж мы договорились о том, что будем использовать для её решения ООП, давайте всё же предполагать что это часть какой-то большой системы которая претендует пережить один запуск.
Полностью согласен, уже была статья на хабре о том, как можно сделать из простого сложное с помощью ООП.
Но больше всего мне нравиться то, почему используют ООП, обычно эта фраза произноситься с легким пафосом, прям в лицо стоящему напротив человеку: «ООП позволяет реализовать задачу в разы проще!» и обычно добавляется: «Ты что не видишь, что ли?!». А там лес классов, тысячи взаимосвязей, но зато очень низкая связанность сущностей, как будто мы в день делаем тысячи приложений, в которых надо выдавать подарки и обязательно, прям завтра, используем повторно наш тщательно написанный сегодня код.
Но больше всего мне нравиться то, почему используют ООП, обычно эта фраза произноситься с легким пафосом, прям в лицо стоящему напротив человеку: «ООП позволяет реализовать задачу в разы проще!» и обычно добавляется: «Ты что не видишь, что ли?!». А там лес классов, тысячи взаимосвязей, но зато очень низкая связанность сущностей, как будто мы в день делаем тысячи приложений, в которых надо выдавать подарки и обязательно, прям завтра, используем повторно наш тщательно написанный сегодня код.
Не соглашусь. Пока просто не соглашусь. Перед тем как вступать в дискуссию было бы очень интересно послушать по каким причинам всё это не удовлетворяет принципу YAGNI. И предлагаю начать с ВыбиралкиПодарка. Также было бы очень интересно если бы вы провели параллели с SOLID.
В общем по поводу моего решения.
Если мы действительно решаем одноразовую задачу получить список и ничего более, то формально я соглашусь с тем что предложил VolCh. И на этом всё, делайте потом с этим списком что хотите и как хотите ;)
Если же мы пытаемся решать какую то более сложную задачу являющуюся частью более сложной системы то я всё же использовал бы более обобщенное решение. Хотя тоже проще чем то, что я предложил изначально.
я бы разбил задачу на две части.
1. Выборка детей из списка по некоему критерию. Тут возможно несколько решений, но я всё же вынес бы тот код который принимает решение о том попал ребёнок в список или нет в какую-то внешнюю сущность.
2. Пробежаться по полученному списку и раздать Подарки. Предыдущие оппоненты действительно убедили меня, что я слишком мало знаю о задаче, потому, на самом деле, делайте с этим результирующим списком что угодно :)
Ну и опять же, при желании оба этапа можно объединить :)
Дальнейшие рассуждения можно делать только получив больше информации.
Но, как по мне, единственное о чём это говорит, так это то, что я зря взялся выдавать какие-то решения имея столько общую постановку :) и ни разу не является аргументом в споре «все остальные» vs ООП (это в основном к выводу «Мы опять пришли к процедурному программированию»)
Если мы действительно решаем одноразовую задачу получить список и ничего более, то формально я соглашусь с тем что предложил VolCh. И на этом всё, делайте потом с этим списком что хотите и как хотите ;)
Если же мы пытаемся решать какую то более сложную задачу являющуюся частью более сложной системы то я всё же использовал бы более обобщенное решение. Хотя тоже проще чем то, что я предложил изначально.
я бы разбил задачу на две части.
1. Выборка детей из списка по некоему критерию. Тут возможно несколько решений, но я всё же вынес бы тот код который принимает решение о том попал ребёнок в список или нет в какую-то внешнюю сущность.
2. Пробежаться по полученному списку и раздать Подарки. Предыдущие оппоненты действительно убедили меня, что я слишком мало знаю о задаче, потому, на самом деле, делайте с этим результирующим списком что угодно :)
Ну и опять же, при желании оба этапа можно объединить :)
Дальнейшие рассуждения можно делать только получив больше информации.
Но, как по мне, единственное о чём это говорит, так это то, что я зря взялся выдавать какие-то решения имея столько общую постановку :) и ни разу не является аргументом в споре «все остальные» vs ООП (это в основном к выводу «Мы опять пришли к процедурному программированию»)
Вот наворотили-то, в задании сказано «список детей до 14 лет, сгруппированных по полу».
ну и ещё одно ограничение вы забыли, как и многие кто предлагает решить это простым sql запросом ;) просили не выдавать два подарка ребёнку если оба его родителя являются сотрудниками. Это конечно скорее всего всё ещё решается в терминах sql, но я бы уже не стал назвать это простыми запросами.
В моём алгоритме выше это учтено. Я к тому, что все эти классы, кроме Работник и Ребёнок (плюс их коллекции) излишни для сформулированной задачи. Есть работники, есть их дети, нужно получить список детей младше 14 лет, сгруппированных по полу без повторений. Никаких подарков и, тем более, сертификатов программа выдавать не должна. Налицо вольная трактовка ТЗ и не затребованная «заказчиком» функциональность.
select * from children where age <= 14 order by sex
Cделать один select в две строчки, скопировать результат в письмо, отправить начальству.
Если вам нужно решить задачу, пользуйтесь тем инструментом, который больше всего подходит. Тут — SQL. А если действительно понадобится ООП (по причинам, которые у вас не указаны), нужно планировать структуру классов под решаемые задачи (как в комментарии ghostWhite выше), как написано в последней части статьи. Разумеется, скорость и удобство разработки будут ниже, но в некоторых случаях бывает оправданно написать один класс, который решает серию похожих задач, чем кучу однострочников, раскиданных по всей программе.
Если данные из базы — используйте SQL, однозначно.
Он как раз предназначен для выборок.
Если же данные из внешнего источника (не БД), то используйте hash set для списка детей и обход всех детей (предлагается использовать итератор — абстрагируемся от структуры хранения).
Насчет обоих родителей. В задаче необходимо уточнить, как идентифицируются дети.
Он как раз предназначен для выборок.
Если же данные из внешнего источника (не БД), то используйте hash set для списка детей и обход всех детей (предлагается использовать итератор — абстрагируемся от структуры хранения).
Насчет обоих родителей. В задаче необходимо уточнить, как идентифицируются дети.
ООП здесь будет прослеживаться в:
Все это можно реализовать и с использованием процедурного подхода, но в ООП оно ложится естественным образом.
- Абстрагировании алгоритма составления списка от структуры хранения исходных данных
- Использование объекта, работающего по принципу hash set, независимо от его внутренней реализации
- Работать напрямую с массивами неудобно — придется заранее вычислять размер. Проще сделать оценку сверху и использовать абстракцию списка
Все это можно реализовать и с использованием процедурного подхода, но в ООП оно ложится естественным образом.
>Работать напрямую с массивами неудобно — придется заранее вычислять размер.
Зависит от языка.
Зависит от языка.
Да, условие немного расплывчато, хотя довольно четко написано. Есть список родителей, у них поле Дети, у Ребёнка есть такие-то свойства. И как мне кажется, не правильно менять условие задачи, чтобы она подходила под реализацию через SQL или hash set'ы. Редко бывает, что мы можем в готовой системе что-то поменять, а тут требовалась именно доработать.
Мне именно интересен подход ООП, так как после прочтения разных методик написания (SOLID, YAGNI), у меня вышла каша из десятков классов. Хотя задача в том же C#, решается простым LINQ выражением. Каюсь, задачу намеренно усложнил, чтобы было нагляднее видно сложность работы с наборами данных при помощи ООП.
ГотовыеСписки = Работники
.SelectMany(работник=>работник.дети)
.Where(детё=>детё.Возраст <= 12)
.Distinct()
.GroupBy(детё=>детё.Пол)
Console.WriteLine(string.Join("\r\n", ГотовыеСписки[Мальчик].Select(детё=>детё.Имя));
Console.WriteLine(string.Join("\r\n", ГотовыеСписки[Девочка].Select(детё=>детё.Имя));
Самое интересное, что это не псевдокод, это вполне рабочий код, который НЕ НУЖНО реиспользовать где-нибудь, т. к. его значительно проще написать там, где нужно ещё раз. Это как раз вариант нарушения всех принципов ООП: для чего нужно писать сложный универсальный код, когда можно написать красивый идеально подходящий именно для этой задачи.
У LINQ есть ещё один плюс, вы почти (!!!) можете не думать о том, где лежат у вас данные, это может быть база, сервис или объекты.
Мне именно интересен подход ООП, так как после прочтения разных методик написания (SOLID, YAGNI), у меня вышла каша из десятков классов. Хотя задача в том же C#, решается простым LINQ выражением. Каюсь, задачу намеренно усложнил, чтобы было нагляднее видно сложность работы с наборами данных при помощи ООП.
ГотовыеСписки = Работники
.SelectMany(работник=>работник.дети)
.Where(детё=>детё.Возраст <= 12)
.Distinct()
.GroupBy(детё=>детё.Пол)
Console.WriteLine(string.Join("\r\n", ГотовыеСписки[Мальчик].Select(детё=>детё.Имя));
Console.WriteLine(string.Join("\r\n", ГотовыеСписки[Девочка].Select(детё=>детё.Имя));
Самое интересное, что это не псевдокод, это вполне рабочий код, который НЕ НУЖНО реиспользовать где-нибудь, т. к. его значительно проще написать там, где нужно ещё раз. Это как раз вариант нарушения всех принципов ООП: для чего нужно писать сложный универсальный код, когда можно написать красивый идеально подходящий именно для этой задачи.
У LINQ есть ещё один плюс, вы почти (!!!) можете не думать о том, где лежат у вас данные, это может быть база, сервис или объекты.
С одной стороны да, с другой по ООП (по крайне мере, которому меня учили): я должен был как минимум создать класс фильтр (чтобы его можно было заменять), реализовать класс группировки и т. п. Здесь нет этого — для многих это не ООП.
На функциональном языке код будет выглядеть почти так же, только вместо обращения к методам SelectMany,Where и т. п. Будут, что-то типа Seq.Iter, Seq.Filter, Seq.Distinct
И в ФЯ не будет ниодного объекта или класса :) хотя не знаю последовательности в функциональном программировании считаются объектами или нет? — получается вроде не ООП.
И в ФЯ не будет ниодного объекта или класса :) хотя не знаю последовательности в функциональном программировании считаются объектами или нет? — получается вроде не ООП.
грязное грязное решение=)
www.ideone.com/LKz5m
www.ideone.com/LKz5m
Если честно, то я не знаю такие области, в которых ООП явно проигрывало функциональному подходу по тем или иным параметрам.
В принципе ООП можно использовать и для функционального программирования(функторы), так что таких задач, в принципе нет, хотя это уже извращение.
В принципе ООП можно использовать и для функционального программирования(функторы), так что таких задач, в принципе нет, хотя это уже извращение.
В дополнение всего сказанного автором этой замечательной статьи, есть ещё один, не менее интересный материал по этой теме (только в противоположную сторону):
Почему объектно-ориентированное программирование провалилось?
Почему объектно-ориентированное программирование провалилось?
да-да, знакомые материалы.
В ответ на это есть статья с противоположным названием Objects have not failed
В ответ на это есть статья с противоположным названием Objects have not failed
> Вы никогда не будете писать класс, а потом думать, чем бы ему заняться. То есть, цепочка всегда начинается от поведения.
В Common Lisp это понять проще, т.к. методы (глаголы) внешние по отношению к классам (существительным) и им не принадлежат. В большинстве случаев вы прямо в коде будете сначала писать методы, а потом классы с полями.
В Common Lisp это понять проще, т.к. методы (глаголы) внешние по отношению к классам (существительным) и им не принадлежат. В большинстве случаев вы прямо в коде будете сначала писать методы, а потом классы с полями.
Абзац про мое несогласие с тем, что в ООП начинают с классов как раз и вызван этим отрывком
Ещё один прекрасный пример того, что любой человек может ошибаться.
Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома.
А как же вот это:
Аксио́ма (др.-греч. ἀξίωμα — утверждение, положение) — утверждение, принимаемое истинным без доказательств, и которое в последующем служит «фундаментом» для построения доказательств в рамках какой-либо теории, дисциплины и т.д.
Вот многие в комментариях приписывают ООП такие эпитеты как «философия» и.т.д. Проснитесь люди.
ООП это лишь очередной уровень программирования.
Как от машинных кодов (одномерное, так сказать порядковое исполнение инструкций, только с переходами назад-вперёд) пришло процедурное (так называемое двухмерное) программирование (когда переходы стали делаться в отдельные процедуры которые можно повторно использовать в разных проектах) точно также пришло и ООП. Просто программирование стало ещё на уровень выше. Теперь можно написать процедуру которая вызовет 10 процедур каждая из которых вызовет по 20 процедур и так на любую глубину. Это было возможно и при процедурном программировании, но разница лишь в том что теперь от этого не кипят мозги и это под силу сделать быстро и наделать меньше ошибок… Это просто очередной уровень абстракции… Так сказать очередной шаг в эволюции программирования, позволяющий держать в голове меньше мусора, и сосредоточиться на логике приложения.
ООП это лишь очередной уровень программирования.
Как от машинных кодов (одномерное, так сказать порядковое исполнение инструкций, только с переходами назад-вперёд) пришло процедурное (так называемое двухмерное) программирование (когда переходы стали делаться в отдельные процедуры которые можно повторно использовать в разных проектах) точно также пришло и ООП. Просто программирование стало ещё на уровень выше. Теперь можно написать процедуру которая вызовет 10 процедур каждая из которых вызовет по 20 процедур и так на любую глубину. Это было возможно и при процедурном программировании, но разница лишь в том что теперь от этого не кипят мозги и это под силу сделать быстро и наделать меньше ошибок… Это просто очередной уровень абстракции… Так сказать очередной шаг в эволюции программирования, позволяющий держать в голове меньше мусора, и сосредоточиться на логике приложения.
Почему инкапсуляция состояния всегда приписывается ООП, разве в модулях нельзя было создать скрытые переменные, которые доступны только этому модулю?
Вообще к ООП обычно приписывают горы дополнительных возможностей:
— абстракция — как будто функция не может абстрагировать (или модуль);
— инкапсуляция — попробуйте получить доступ к локальным переменным функции;
— полиморфизм — почему я не могу написать функцию использующую более общую функцию, а реализацию подставить во время выполнения;
Единственное, по моему мнению (где-то читал, но к сожалению источник указать не смогу, вроде у Вирта, про его Оберон): ООП дало нам наследование, но при этом в каждой умной книжке, которая учит нас писать идеальный код, обязательно будет упоминание об ограниченном использовании наследования (обычно сводиться к тому, что не более двух уровней, иногда — только реализация интерфейсов). Так как глубокое наследование это ад для отлова ошибок (особенно если не соблюдать разных принципов, типа Лискоу(в)).
Вообще к ООП обычно приписывают горы дополнительных возможностей:
— абстракция — как будто функция не может абстрагировать (или модуль);
— инкапсуляция — попробуйте получить доступ к локальным переменным функции;
— полиморфизм — почему я не могу написать функцию использующую более общую функцию, а реализацию подставить во время выполнения;
Единственное, по моему мнению (где-то читал, но к сожалению источник указать не смогу, вроде у Вирта, про его Оберон): ООП дало нам наследование, но при этом в каждой умной книжке, которая учит нас писать идеальный код, обязательно будет упоминание об ограниченном использовании наследования (обычно сводиться к тому, что не более двух уровней, иногда — только реализация интерфейсов). Так как глубокое наследование это ад для отлова ошибок (особенно если не соблюдать разных принципов, типа Лискоу(в)).
Повторное использование кода, и прочие фишки приписываемые сугубо ООП можно было делать и до его появления. Просто некоторые из них с появлением ООП стало делать проще и быстрее. Не это ли естественный шаг программирования?
А стало ли? Было бы интересно сравнить… Я перешел с Pascal/Delphi на C#, и не очень понял, чем стало удобнее. C# идеальный язык, мне он нравится на много больше, но не ООП, а как раз наоборот: функциональные штучки (LINQ, лямбды, делегаты, анонимные классы), свое библиотекой, где-то синтаксисом и т. п. Но не как не ООП, не понимаю, для чего меня заставляют писать static class, если мне нужна функция?
Стало проще для тех кто понял фишку… и стало труднее кто забивает гвозди микроскопом.
Был код
Для «hello world» больше и не надо (на этом и споры «ООП vs процедурка») однако если мы пишем приложение посложнее можно сделать
И можно пойти дальше, и в сложных проектах нужно идти дальше, например
НО
Если ты пишешь «hello world» в классическом его виде, то да. ООП это никому не нужный онанизм…
Был код
echo "hello world"Для «hello world» больше и не надо (на этом и споры «ООП vs процедурка») однако если мы пишем приложение посложнее можно сделать
echo "hello" ? something() : something_else()
retrun 0
function something() { return "World" }
function something_else() { return "Wife" }И можно пойти дальше, и в сложных проектах нужно идти дальше, например
echo = new (Russian)
echo->hello->world
class hello
class goodby
class fuck_you
class world
class baby
class bitch
НО
Если ты пишешь «hello world» в классическом его виде, то да. ООП это никому не нужный онанизм…
Потому что путается ооп с «модульностью объектов с состояниями», потому что банда четырех модно и на каждом собеседовании паттерны спрашивают, а, например, sicp — нет.
В большинстве языков модуль нельзя передать параметром в функцию/процедуру.
Странный опус и не менее странные комментарии. Извините, но каша в головах полная.
Я в 25 лет научился качественно косить сено. Но я не требую, что косили сено другие и чтобы еще косили качественно.
Если у Вас не получается или Вы что-то не понимаете это не значит, что у других тоже самое.
Я в 25 лет научился качественно косить сено. Но я не требую, что косили сено другие и чтобы еще косили качественно.
Если у Вас не получается или Вы что-то не понимаете это не значит, что у других тоже самое.
>>где бы я мог использовать процедурный подход, вместо объектного
Там, где важна скорость выполнения, и временные затраты на поиск нужной функции в иерархии классов неприемлимы — системное программирование.
Там, где важна скорость разработки, и временные затраты на расписывание ненужного объектно-ориентированного оформления кода неприемлимы — небольшие, часто одноразовые скрипты.
Там, где важна скорость выполнения, и временные затраты на поиск нужной функции в иерархии классов неприемлимы — системное программирование.
Там, где важна скорость разработки, и временные затраты на расписывание ненужного объектно-ориентированного оформления кода неприемлимы — небольшие, часто одноразовые скрипты.
ООП головного мозга. Терминальная стадия.
Не надо путать ооп (с наследованием и прочим) и фп (с комбинаторами и прочим)-языки и способы декомпозиции на объекты и потоки соответственно. Если первое описывает язык и способ кодирования, то второе намного важнее с более абстрактной точки зрения и от языка зависит слабее. Например, на С можно закодировать как с имитацией ооп, так и с имитацией датафлоу, хотя язык процедурный (и противопоставляя объектную декомпозицию поцедурному программированию, автор сравнивает теплое с мягким). Для примера советую посмотреть исходники игры на си (quake), с программой, которая активно пользуется библиотеками типа blas. Наличие классов в коде ни о чем не говорит — в stl тоже классы, но это не ооп.
Адепты ооп часто пытаются расчленить предметную область на объекты там, где этого не надо, получая гигантские конструкции где достаточно sql-запроса, как в обсуждении выше.тственно. Если первое описывает язык и способ кодирования, то второе намного важнее с более абстрактной точки зрения и от языка зависит слабее. Например, на С можно закодировать как с имитацией ооп, так и с имитацией датафлоу, хотя язык процедурный (и противопоставляя объектную декомпозицию поцедурному программированию, автор сравнивает теплое с мягким). Для примера советую посмотреть исходники игры на си (quake), с программой, которая активно пользуется библиотеками типа blas. Наличие классов в коде ни о чем не говорит — в stl тоже классы, но это не ооп.
Адепты ооп часто пытаются расчленить предметную область на объекты там, где этого не надо, получая гигантские конструкции где достаточно sql-запроса, как в обсуждении выше.
Адепты ооп часто пытаются расчленить предметную область на объекты там, где этого не надо, получая гигантские конструкции где достаточно sql-запроса, как в обсуждении выше.тственно. Если первое описывает язык и способ кодирования, то второе намного важнее с более абстрактной точки зрения и от языка зависит слабее. Например, на С можно закодировать как с имитацией ооп, так и с имитацией датафлоу, хотя язык процедурный (и противопоставляя объектную декомпозицию поцедурному программированию, автор сравнивает теплое с мягким). Для примера советую посмотреть исходники игры на си (quake), с программой, которая активно пользуется библиотеками типа blas. Наличие классов в коде ни о чем не говорит — в stl тоже классы, но это не ооп.
Адепты ооп часто пытаются расчленить предметную область на объекты там, где этого не надо, получая гигантские конструкции где достаточно sql-запроса, как в обсуждении выше.
Следующими шагами для вас будет видимо осознание абстрактизации и полиморфизма. По вашему посту не прослеживается ясное понимание этих вещей.
цели показать свое понимание абстракции и полиморфизма не было, поэтому и не прослеживается
Но это же основополагающие вещи. Если они не нужны для решения задачи, то действительно иногда проще 15 строк процедурного кода написать чем 3 класса.
Конечно, я с этим полностью согласен. Применение ООП только ради ООП может привести к усложнению и самой системы, так еще и взаимоотношения с коллегами. Параноидального отношения вообще стоит избегать к любым вещам.
Но возвращаясь к вопросу о полиморфизме и абстракции, еще раз повторю — цели такой не было. Здесь описано именно то, что менялось в моем понимании. Понимание абстракции как было, так и осталось. С полиморфизмом та же штука
Но возвращаясь к вопросу о полиморфизме и абстракции, еще раз повторю — цели такой не было. Здесь описано именно то, что менялось в моем понимании. Понимание абстракции как было, так и осталось. С полиморфизмом та же штука
ООП это хорошо… но только бы не «ООП ради ООП»…
OMG, где все программисты? )
Читаем внимательно On Understanding Data Abstraction
Читаем внимательно On Understanding Data Abstraction
Ещё одна маленькая задача которую удалось решить без ООП. Да я используя классы коллекций, да внутри много ООП, которое позволяет мне делать такие вещи. Но почему получается, чем меньше ООП снаружи, тем проще мой код?
Regex reg = new Regex(@«src=»"/media/posters/(?[0-9_a-zA-Z\-]*?)\.thumbnail\.jpg""", RegexOptions.Singleline);
Enumerable.Range(1, int.MaxValue)
.Select(page => new WebClient().DownloadString(string.Format(«demotivators.ru/?page={0}», page)))
.Select(html => reg.Matches(html))
.SelectMany(_ => _.Cast())
.Select(_ => _.Groups[«url»].Value)
.AsParallel().WithDegreeOfParallelism(40)
.Select(name => new
{
name,
url = string.Format(«demotivators.ru//media/posters/{0}.jpg», name),
path = string.Format(@«D:\temp\dem\{0}.jpg», name)
})
.Where(image => !File.Exists(image.path))
.Select(image => new { image.name, image.url, image.path, data = new WebClient().DownloadData(image.url) })
.ForAll(image => File.WriteAllBytes(image.path, image.data));
(извиняюсь, нету кармы, поэтому не могу оформить красиво код).
Но вы только посмотрите, ведь это многопоточная программа по скачиванию картинок с demotivators.ru. Причем нам предварительно нужно скачивать страницу и только потом скачивать картинку. Кто решиться его переписать на ООП с использованием потоков? Сколько получиться кода? Будет ли он таким же прозрачным? Заметьте этот кусок кода умещается на четверть экрана, это можно сказать идеальный код для такой качалки.
(пробовал другие варианты, но обычно очень сложно заставить код скачивать следующую страницу не после того, как на разобранной странице скачены все картинки, а сразу по освобождению выделенного потока)
Regex reg = new Regex(@«src=»"/media/posters/(?[0-9_a-zA-Z\-]*?)\.thumbnail\.jpg""", RegexOptions.Singleline);
Enumerable.Range(1, int.MaxValue)
.Select(page => new WebClient().DownloadString(string.Format(«demotivators.ru/?page={0}», page)))
.Select(html => reg.Matches(html))
.SelectMany(_ => _.Cast())
.Select(_ => _.Groups[«url»].Value)
.AsParallel().WithDegreeOfParallelism(40)
.Select(name => new
{
name,
url = string.Format(«demotivators.ru//media/posters/{0}.jpg», name),
path = string.Format(@«D:\temp\dem\{0}.jpg», name)
})
.Where(image => !File.Exists(image.path))
.Select(image => new { image.name, image.url, image.path, data = new WebClient().DownloadData(image.url) })
.ForAll(image => File.WriteAllBytes(image.path, image.data));
(извиняюсь, нету кармы, поэтому не могу оформить красиво код).
Но вы только посмотрите, ведь это многопоточная программа по скачиванию картинок с demotivators.ru. Причем нам предварительно нужно скачивать страницу и только потом скачивать картинку. Кто решиться его переписать на ООП с использованием потоков? Сколько получиться кода? Будет ли он таким же прозрачным? Заметьте этот кусок кода умещается на четверть экрана, это можно сказать идеальный код для такой качалки.
(пробовал другие варианты, но обычно очень сложно заставить код скачивать следующую страницу не после того, как на разобранной странице скачены все картинки, а сразу по освобождению выделенного потока)
сорри не удалось отказаться от Regex, но это только потому что, мне не удалось завести код Regex.Matches(строка, шаблон).
>Но почему получается, чем меньше ООП снаружи, тем проще мой код?
Так в том одно из основных свойств ООП и заключается, что инкапсулируя код внутри объектов мы получаем простой код снаружи.
Так в том одно из основных свойств ООП и заключается, что инкапсулируя код внутри объектов мы получаем простой код снаружи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция понимания ООП