ООП решения сложны для понимания.
Каждый раз для внесения изменений нужно заново пройти квест наследования,
чтобы понять где находится суть действия над данными.
Единственно верное решение сложной задачи без усложения — модули.
И еще храните состояние в базе, если есть база.
не нужно без необходимости использовать ООП.
например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.
Согласен. Я считаю, что ООП не нужен. Если брать Java, как пример, то нужны интерфейсы, наследование интерфейсов, реализация интерфейсов, и всё. Наследование классов не нужно.
Здравствуйте, vaa, Вы писали:
vaa>ООП решения сложны для понимания.
Любые?
vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,
Абсолютно каждый раз?
vaa>Единственно верное решение сложной задачи без усложения — модули.
ООП противоречит модулям?
vaa>И еще храните состояние в базе, если есть база.
Ага, а еще используйте протокол HTTP для работы в интернете.
vaa>не нужно без необходимости использовать ООП.
Я тебе больше скажу, не нужно без необходимости использовать Х, где Х — любая технология.
vaa>например очередь. зачем?
Что зачем?
vaa>если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать vaa>и в другом потоке доставай сущности по айдихи в транзакции, обработай и удали из таблицы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vaa, Вы писали:
vaa>>ООП решения сложны для понимания.
НС>Любые?
Да
vaa>>Каждый раз для внесения изменений нужно заново пройти квест наследования,
НС>Абсолютно каждый раз?
Да
vaa>>Единственно верное решение сложной задачи без усложения — модули.
НС>ООП противоречит модулям?
Модуль — набор функций. Да, ООП решение это сложная лапша интерфейсов и реализаций.
vaa>>И еще храните состояние в базе, если есть база.
НС>Ага, а еще используйте протокол HTTP для работы в интернете.
не вдупляю.
vaa>>не нужно без необходимости использовать ООП.
НС>Я тебе больше скажу, не нужно без необходимости использовать Х, где Х — любая технология.
согласен.
vaa>>например очередь. зачем?
НС>Что зачем?
см. ниже.
vaa>>если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать vaa>>и в другом потоке доставай сущности по айдихи в транзакции, обработай и удали из таблицы.
НС>Для чего все это?
НС>Резюме: ты чего сказать то хотел?
Здравствуйте, vaa, Вы писали:
vaa>ООП решения сложны для понимания.
Между тем в основе ООП модель мышления человека, т.е. роднее ничего другого нет.
vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,
Не надо
vaa>чтобы понять где находится суть действия над данными.
Потому, что у вас не ооп, а просто классы
vaa>Единственно верное решение сложной задачи без усложения — модули.
Правильно. В ооп все вертится как ни странно, вокруг модулей. Класс — модуль. Экземпляр — модуль. Итого — остается сорганизовать взаимодействие модулей.
vaa>И еще храните состояние в базе, если есть база.
что база, что её отсутствие, никакого отношения к ооп не имеет.
vaa>не нужно без необходимости использовать ООП.
ооп используется само, если человек записывает, например, как бы он проделал ту или иную задачу.
vaa>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать vaa>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.
Так чудовища и рождаются. В данном случае ты предложил известную всем очередь реализовать на коленке при помощи таблицы и многотопочной механики. И не ясно, что она там поддерживает, какие фейлы умеет обрабатывать, какие гарантии предоставляет и тд. В твоем случае все это надо рыть по коду.
Если каждый член команды будет руководствоваться таким принципом, то вы или договоритесь и напишете свою очередь, что маловероятно, или же разведете зоопарк велосипедов, что наиболее вероятно.
Здравствуйте, vaa, Вы писали:
vaa>ООП решения сложны для понимания. vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования, vaa>чтобы понять где находится суть действия над данными.
Тогда видимо не ООП, а наследование реализации.
vaa>Единственно верное решение сложной задачи без усложения — модули.
Тут без примера крайне сложно сказать.
vaa>И еще храните состояние в базе, если есть база. vaa>не нужно без необходимости использовать ООП.
Убрать все нелокальные переменные и на каждое изменнение писать в БД ?
vaa>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать vaa>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.
Вам не кажется что это усложнение на пустом песте?
Здравствуйте, vsb, Вы писали:
vsb>Согласен. Я считаю, что ООП не нужен. Если брать Java, как пример, то нужны интерфейсы, наследование интерфейсов, реализация интерфейсов, и всё.
У тебя здесь противоречие — ООП не нужно, вместо него нужно ООП, и всё
ООП это не про три, четыре, пять, N китов. Для ооп не нужны ни классы, ни наследование, хоть какое.
Вот например, наследование интерфейсов — определяем иммутабл интерфейс. Всё ж круто?
И пронаследуем его. Всё ж класнно, можно наследовать интрерфейсы.
А наследник будет мутабл. Гыгы. Получаем тот же приплызд, что и с наследованием реализации
Нужно вспомнить, что такое ООП.
ООП это управление сложностью взаимодействия и поведения. Для всего этого нам нужны
механизмы абстрагирования, т.е. интерфейсы, и реализация интерфейсов, и реализация поведения, т.е. состояние.
Все остальное, модули, классы, наследование хоть интерфейсов, хоть, это уже конкретный вариант, нужно исключительно для экономики проекта.
Например, оо система может быть единого класса-модуля-наследования. Зато если мы уберем отсюда интерфейс или поведение, то всё порушится.
Для сравнения, ФП это управления сложностью вычислений. Здесь нам нужны по большому счету только функции. Всё остальное нужно исключительно для экономики проекта.
Здравствуйте, gandjustas, Вы писали:
vaa>>И еще храните состояние в базе, если есть база. vaa>>не нужно без необходимости использовать ООП. G>Убрать все нелокальные переменные и на каждое изменнение писать в БД ?
так точно.
vaa>>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать vaa>>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы. G>Вам не кажется что это усложнение на пустом песте?
по ситуации
. Но тут сам понимаешь, что-то находишь в парадигме программирования, что-то теряешь. Даже безусловный переход в любую точку программы имеет смысл в некоторых обстоятельствах.
Здравствуйте, vaa, Вы писали:
vaa>ООП решения сложны для понимания. vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования,
Это просто плохо написанный код в ООП-стиле. Я и на процедурах такой код видел, надцать вложений, логика размазана между всеми. Да мне кажется, в любой парадигме так можно запутать.
В хорошо написанном ООП-коде заранее понятно, на каком уровне искать. Это, кагбе, критерий правильности декомпозиции (которая и определяет «хорошесть» ООП-решения).
vaa>>>И еще храните состояние в базе, если есть база. vaa>>>не нужно без необходимости использовать ООП. G>>Убрать все нелокальные переменные и на каждое изменнение писать в БД ? vaa>так точно.
vaa>>>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать vaa>>>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы. G>>Вам не кажется что это усложнение на пустом песте? vaa>по ситуации
Ну вы прям революционЭр какой-то Поди молодой, с горячей головой, энергии много, все вокруг дураками кажутся. А ты при этом лучше всех знаешь Так и тянет переизобрести велосипед.
vaa>ООП решения сложны для понимания.
ООП какого решения? Надо сравнивать решение 1 и той же задачи с ООП и без ООП. А не сферическое решение в воздухе.
Есть примеры чего-то вроде 1с УПП с ООП и без ООП?
Здравствуйте, vaa, Вы писали:
vaa>ООП решения сложны для понимания. vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования, vaa>чтобы понять где находится суть действия над данными. vaa>Единственно верное решение сложной задачи без усложения — модули.
Да нет серебряной пули — нет!!! Не нужно вообще для всего применять ООП! Ибо да, для крайне многих задач это неоправданное усложнение на ровном месте. Однако встречается задачи, для которых применение ООП — как раз способ борьбы со сложностью и способ уменьшения кода. Думать всегда нужно о границах применимости того или иного инструмента!
Здравствуйте, vaa, Вы писали:
vaa>ООП решения сложны для понимания. vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования, vaa>чтобы понять где находится суть действия над данными. vaa>Единственно верное решение сложной задачи без усложения — модули.
Вообще ООП появился именно как механизм для борьбы со сложностью. Сначала было много интузиазма: мы можем представить все сущности в виде объектов, а все объекты разделить на классы, в итоге мы имеем строгую иерархию классов, а программа, состоит из взаимодействующих объектов, каждый из которыйх имеет свое место в этой иерархии. Если нам нажна какая-то обобая функциональность мы наследуемся и переопределяем нужные методы, благодаря этому мы можем менять поведение объектов, не переписывая кучу кода, и наши новые объекты тоже отлично вписываются в классификацию. ООП стала очень популярна и стала считаться чуть ли не единственной верной концепцией, этому способствовало повсеместное распространение GUI программ, которое очень хорошо ложится на объектно ориентированную модель.
Но потом выяснилось, что все не так просто.
Во первых объекты не всегда легко классифицировать. Далеко не все сущьности можно можно засунуть в одно дерево классов. Это попытались решить с помощью множественного наследования. Да, кое что это решило, но в итоге у нас получается уже не дерево классов а беспорядочный граф. Спроектировать красивую иерархию это искусство, и мало у кого это получается, как правило в итоге иерарархия получается уродливой. Всякие техники борьбы с этим,
типа разрешения множественного наследования только для интерфейсов и запрет для реализации, или использования агрегации вместо наслоедования, лишь прикрывает проблему.
Во вторых, большое желание сделать все максимально абстрактно, а программисты всегда любят обобщать и абстрагировать привело к появлению огромных ветвистых иерархий. Логика работы размазывалась по иерархии, понять, что делает какой-либо фрагмент кода становится практически невозможно, код состоит из взаимодействия объектов, а понять каких они типов часто очень непросто. Плюс огромное количество неиспользуемого кода, ты разбираешься как работает какой то метод, но оказывается он давно переопределен в потомке и ты вообще смотришь не туда.
Чтобы бороться с этой проблемой придумали паттерны проектирования. Появилась рекомендация использовать наследование по минимуму. Программистам рекомендовали не просто переопределять методы и добавлять новые уровни абстракции, а пытаться использовать паттрены для того, чтобы сделать красивые и правильные иерархии. Не скажу, что это спасло ситуацию, многие стали применять паттерны ради того чтобы применить паттерны. Программы стали превращаться в жуткие нагромождения разных там обзерверов, которые как-то друг друга слушали, и совершенно нельзя было понять на что может повлиять то или иное событие, в итоге от идеи строгой иерархии ушли довольно далеко.
Что касается модулей, то это не новая идея. Мне кажется она более старая чем ООП, хотя я точно не знаю. У меня есть большие сомнения, что это что-то поменяет. В любом слачае все дело в кривых руках, от которых никак не избавиться.
vaa>И еще храните состояние в базе, если есть база. vaa>не нужно без необходимости использовать ООП. vaa>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать vaa>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.
Честно говоря, тут вообще не понял о чем ты. То вроде говорил опарадигмах и концепциях типа ООП и модулей. А тут резко перешел на базы данных, что уже касается деталей реализации. Если для твоих задачь подходит база данных, тебе никто не запрещает ее использовать. Но базы данных подходят далеко не для всех задач, иногда базы просто нет, иногда производительность недостаточна, а иногда база просто нафиг не нужна. К ООП это вообще мало отношения имеет.
Здравствуйте, vaa, Вы писали:
vaa>ООП решения сложны для понимания.
Если взять классическое определение ООП, это когда объекты обмениваются сообщениями, то я согласен, трудно найти что-то более сложное.
vaa>Каждый раз для внесения изменений нужно заново пройти квест наследования, vaa>чтобы понять где находится суть действия над данными.
И вот это вы называете "сложно"? Это вообще рутина.
vaa>Единственно верное решение сложной задачи без усложения — модули.
Что есть модуль? Чем он отличается от слоя?
vaa>И еще храните состояние в базе, если есть база.
Если у вас есть состояние, значит у вас есть проблемы. А в базе это состояние или в памяти — не важно.
vaa>не нужно без необходимости использовать ООП.
Нет никакой "необходимости"! Некоторые умеют в ООП, а некоторые нет. Это от способа мышления программиста зависит.
vaa>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать
Это всё равно очередь.
У меня складывается впечатление, что кто-то не умеет в многопоточность...
vaa>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.
А! Точно! Кто-то не смог написать потокобезопасную очередь.
Здравствуйте, vaa, Вы писали:
vaa>Единственно верное решение сложной задачи без усложения — модули.
Угу я как бывший 1С ник скажу, что херня. Ибо там сразу применяют утиную типизацию.
И уж хрен поймешь код.
ООП нужен. Прежде всего для уменьшения кода по сравнению с интерфейсами.
Да бывают проблемы с чтением виртуальных методов. Когда методы переопределены. Но всегда можно посмотреть реализацию наследников в студии.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, ksandro, Вы писали:
K>Вообще ООП появился именно как механизм для борьбы со сложностью.
Любая парадигма это механизм для управления сложностью. Только в каждом случае мы управляем сложностью разных аспектов. Например, в модели актёров нас интересует многозадачность. В функциональном — вычисления. В реактивном — обработка потока событий.
K>Но потом выяснилось, что все не так просто.
K>Во первых объекты не всегда легко классифицировать.
Это не проблема исключительно ООП. Вообще всё и везде трудно классифицировать. В каждой парадигме надо чтото классифицировать. Неверная классификация ведет к чудовищным переусложнениям.
K>Во вторых, большое желание сделать все максимально абстрактно,
Основной инструмент управления сложностью во всех парадигмах это абстракция, обычно реализуется при помощи инкапсуляции. Только реализация инкапсуляции везде разная, в зависимости от целей. В ФП наша цель — вычисления, абстрагируемся за счет инкапсуляции лишних деталей внутрь функций.
В ООП наша цель — взаимодействие и поведение, абстрагируеся за счет инкапсулиляции доступа к состоянию.
K>Чтобы бороться с этой проблемой придумали паттерны проектирования.
Паттерны не придумывали. Их обнаружили. По мере накопления опыта вдруг выяснилось, что большинство задач — типовые. Т.е. паттерны никто не изобретал, они были и до написания книжек, ровно как и гравитация до Ньютона.
> Появилась рекомендация использовать наследование по минимуму.
Не по минимуму, а по назначению. Есть у тебя отношения вида is-a, subtype, бери, наследуйся, сколько влезет. Есть у тебя модули — расширяй, сколько влезет. Главное не смешивать два этих кейса.
K>Что касается модулей, то это не новая идея. Мне кажется она более старая чем ООП, хотя я точно не знаю. У меня есть большие сомнения, что это что-то поменяет. В любом слачае все дело в кривых руках, от которых никак не избавиться.
ООП включает в себя эти модули. Класс это и модуль, и тип одновременно. Экземпляр класса это в т.ч. еще и модуль. Вот эта двойственность является некоторым барьером в использовании.
В любом случае, для моделивания взаимодействия, поведения лучше ооп ничего не придумали.
Например, вроде бы в ФП присобачили возможность писать "лучше чем в ООП", но на самом деле это просто переизобретение ООП поверх функционального языка с разной степерью чистоты. И все те самые проблемы-грабли-особенности-паттерны будут ровно там же и по тем же причинам.
vaa>>например очередь. зачем? если есть база, создай таблицу в которую кидай айдихи сущностей которые нужно обработать vaa>>и в другом потоке доставай сущности по айди в транзакции, обработай и удали из таблицы.
K>Честно говоря, тут вообще не понял о чем ты. То вроде говорил опарадигмах и концепциях типа ООП и модулей. А тут резко перешел на базы данных, что уже касается деталей реализации. Если для твоих задачь подходит база данных, тебе никто не запрещает ее использовать. Но базы данных подходят далеко не для всех задач, иногда базы просто нет, иногда производительность недостаточна, а иногда база просто нафиг не нужна. К ООП это вообще мало отношения имеет.
Каждая из парадигм так или иначе работает со временем и состоянием. Теоретически, они все об одном и том же. Штука в том, что всеобемлющей парадигмы не существует — человеку приходится абстрагироваться, классифицировать что бы работать с этим всеобъемлющим.
Потому семейства некоторых типовых задач естественным путём оформились в парадигмы.
Взаимодействие, поведение — ООП
Вычисления — ФП
Поток событий — реактивное
Многозадачность — модель актеров
Здравствуйте, Serginio1, Вы писали:
S> Угу я как бывший 1С ник скажу, что херня. Ибо там сразу применяют утиную типизацию. S>И уж хрен поймешь код. S> ООП нужен. Прежде всего для уменьшения кода по сравнению с интерфейсами. S>Да бывают проблемы с чтением виртуальных методов. Когда методы переопределены. Но всегда можно посмотреть реализацию наследников в студии.
Как тоже бывший — в 1С фактически-то ООП присутствует, хоть и в урезанном виде. Каждый новый документ — наследник общего «Документа», переопределяющий виртуальные методы. Всякие журналы — это интерфейсы, позволяющие однообразно работать с документами разных типов. Ну и т.п.
Типизация динамическая, но это уже другой вопрос. И набор базовых классов ограничен. А так вполне себе ООП
Между тем в основе ООП модель мышления человека, т.е. роднее ничего другого нет. 
Так и тянет переизобрести велосипед.
