Стоит ли использовать ООП?

@@KOT@ · Регистрация: 29.01.2010

Студворк — интернет-сервис помощи студентам

Здравствуйте.
Возник такой вопрос: стоит ли использовать ооп. Даже не так, когда использовать ооп?
Иногда (даже чаще всего) легче написать простые функции, а не мутить с классами обектами и методами.
Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени.

@CoderHuligan · 04.09.2017, 15:19

Сообщение от Fulcrum_013

В данном случае не наследует а содержит объект типа другого класса.

А что - объект другого класса не может пользоваться полями родительского?
Может, и пользуется как своими собственными.

Сообщение от Fulcrum_013

НУ в общем вы против программирования вообще. Вы только за быдлокодинг.

Я за повторное использование и независимость описаний.
Я против спагетти. Любого.

Сообщение от Fulcrum_013

Необходимость композиции вытекает из необходимости декомпозиции.

Декомпозиция происходит по функциям, а не по типам.
Это если по уму.

Сообщение от Fulcrum_013

А какая разница где их писать если все равно писать?

Все эти деструкторы-конструкторы, virtual, public и т.п. это всё совершенно не относится к алгоритму решения задачи.
Лучше чтобы их вовсе не было ни в коде, ни в препроцессоре. А препроцессор нужно использовать в совершенно обычных целях, в каких его используют в си.

Добавлено через 23 минуты

Сообщение от Fulcrum_013

Необходимость композиции вытекает из необходимости декомпозиции.

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

@Fulcrum_013 · 04.09.2017, 15:33

Сообщение от CoderHuligan

А что - объект другого класса не может пользоваться полями родительского?
Может, и пользуется как своими собственными.

Он не является экземпляром родительского класса в отличии от наследования.

Добавлено через 56 секунд

Сообщение от CoderHuligan

Я за повторное использование и независимость описаний.
Я против спагетти. Любого.

Спагетти и взаимосвязи это две большие разницы. К примеру проблема спагетти в блок-схемах против которых к примеру Дейкстра выступал в принципе по причине спагетти взаимосвязей полностью пофиксилась запретом на пересечение линий взаимосвязей.

Добавлено через 5 минут

Сообщение от CoderHuligan

Они разные сущности, поэтому они должны описываться совершенно независимо друг от друга.

Человек и рука человека друг без друга существовать не могут. При этом рука человека к примеру в плане кинематики абсолютно ничем не отличается от лапы медведя и лапки паука. Соответсвенно и описываться оная лапка должна независимо от владельца. При этом таки как не крути а в некоторых предметных областях ( особенности в геймдеве) cуществует операция отделения лапок у любой сущности.

@CoderHuligan · 04.09.2017, 16:28

Сообщение от Fulcrum_013

Он не является экземпляром родительского класса в отличии от наследования.

Ну, класс, а не обьект.

Сообщение от Fulcrum_013

К примеру проблема спагетти в блок-схемах против которых к примеру Дейкстра выступал в принципе по причине спагетти взаимосвязей полностью пофиксилась запретом на пересечение линий взаимосвязей.

Блок схемы - устаревшая концепция. Язык дракон-схем - последний жалкий писк этой концепции. Диаграммы состояний - вот, что действительно необходимо для правильного понимания алгоритма в сжатом отображении.

Сообщение от Fulcrum_013

Человек и рука человека друг без друга существовать не могут. При этом рука человека к примеру в плане кинематики абсолютно ничем не отличается от лапы медведя и лапки паука.

Чем? Чем она не отличается? наличием суставов-сочленений? Во первых их количество может различаться, а во-вторых их конструкция тоже различна, как и радиусы движения. Тогда давайте экскаватор тоже обьединим - у него тоже есть "рука" оканчивающаяся ковшом.. Вот до чего может довести ооп-головного мозга...

Сообщение от Fulcrum_013

Соответсвенно и описываться оная лапка должна независимо от владельца. При этом таки как не крути а в некоторых предметных областях ( особенности в геймдеве) cуществует операция отделения лапок у любой сущности.

Отдельно для того чтобы иметь особенность летать отдельно от владельца? Очень смешно. А в типе прописать отделилась-неотделилась? Функционал оной лапки описывается функциями.. Да и зачем мне отделять описание составной его части от самого обьекта? Может ему потребуется обратно пришить оторванную часть путём магии? А тут возьмёт и лапка паука пришьётся?

Да.. Интересно как вы сохраняете контекст обьекта например в файл? Пишите отдельный метод в класс, который выбирает что сохранять только из статических типов(не методов)? А мне достаточно структуру скинуть в файл и не париться.

@Fulcrum_013 · 04.09.2017, 19:09

Сообщение от CoderHuligan

Язык дракон-схем - последний жалкий писк этой концепции.

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

Добавлено через 2 минуты

Сообщение от CoderHuligan

Отдельно для того чтобы иметь особенность летать отдельно от владельца?

Для того чтобы оная лапка лепилась и к медведю и к пауку и к человекоподобной обезьяне.

@CoderHuligan · 04.09.2017, 20:13

Сообщение от Fulcrum_013

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

Ну, вообще то, ПО Бурана писалось на текстовых языках ПРОЛ2, ДИПОЛЬ и ЛАКС. А Дракон использовался для написания системы морского старта Графит-Флокс.

Сообщение от Fulcrum_013

Для того чтобы оная лапка лепилась и к медведю и к пауку и к человекоподобной обезьяне.

То есть, чтобы паучья лапка прилепилась к обезьяне по сценарию игры? Понятно. Тогда эту универсальную лапку надо представить в виде отдельного типа.

@Fulcrum_013 · 05.09.2017, 02:40

Сообщение от CoderHuligan

Ну, вообще то, ПО Бурана писалось на текстовых языках ПРОЛ2, ДИПОЛЬ и ЛАКС

Которые есть ничто иное как диалекты Дракона заточенные под определенную предметную область. Разница в наличии средств синхронизации алгоритма при выполненнии на нескольких ЭВМ.

Добавлено через 3 минуты

Сообщение от CoderHuligan

То есть, чтобы паучья лапка прилепилась к обезьяне по сценарию игры? Понятно. Тогда эту универсальную лапку надо представить в виде отдельного типа.

Ну это уже от количества LSD принятого разрабами зависит. Ну а чтобы паучья только к пауку лепилась а обезьянья толко к обезьяне и при этом код кинематики переписывать не надо было паучья и обезьянья лапки должны быть потомками универсальной лапки а паук и обезьяна потомком универсального ~~солдата~~ существа.

Добавлено через 2 часа 44 минуты

Сообщение от CoderHuligan

Ну, класс, а не обьект.

Класс не объект а прототип объекта. В общем случае композиции функции принимающие предка не смогут принять вместо него потомка как при наследовании. В необщем будут унсафе финты ушам с калабуром типизации.

Добавлено через 2 часа 1 минуту

Сообщение от CoderHuligan

Это если по уму.

Если по уму то функции группируются по применимости к наборам данных. Ну а если у разных типов наборы незначительно отличаются то по уму выделить общее и набор функций для обработки этого общего а так же набор функций для обработки каждого из отдельных случаев. К примеру комбобокс отличается от едита вообще на децел - наличием списка итемов. Не переписывать же из за этого различия всю обработку ресайза/аллигна и т.д. и т.п для каждого из них? Логично написать эту обработку один раз а потом породить пару потомков каждый из которых умеет установить/прочитать/модифицировать свой набоор вводимых данных.

Добавлено через 1 минуту

Сообщение от CoderHuligan

В общем я об этом уже писал другими словами, говоря о генно-модифицированном гипер-существе, но мало кто слушает

Потому что вы пишете полный бред.

Сообщение от CoderHuligan

и может содержаться в одном файле-модуле.

Модуль в отличии от классов не может иметь инстансов.

Добавлено через 1 минуту

Сообщение от CoderHuligan

Я за повторное использование и независимость описаний.

Вы за копи-паст кашу

Добавлено через 3 минуты

Сообщение от CoderHuligan

Все эти деструкторы-конструкторы, virtual, public и т.п. это всё совершенно не относится к алгоритму решения задачи.

Очень даже относится. Задача это не 2+2 посчитать а смоделировать работу того или иного механизма. При этом у любого механизма существуют как закрываемые от внешнего вмешательства узлы так и используемые для связи с другими механизмами узлы (интерфейсы). Даже к примеру у банальных редуктора или лампочки.

Добавлено через 3 минуты

Сообщение от CoderHuligan

Интересно как вы сохраняете контекст обьекта например в файл?

Представление объекта в памяти абсолютно ничем не отличается от представления структуры. Во всяком случае в симуловской модели объектов. Ну а в общем задача сериализации особенно полиморфных данных в любом случае штука нетривиальная даже при наличии полного рефлекшина. К примеру всегда есть данные которые сохранять не надо (к примеру хендлы WinAPI и т.п) а есть такие которые нужно сконвертировать в другой формат (к примеру указатели на взаимосвязанные объекты/структуры).

Добавлено через 9 минут

Сообщение от CoderHuligan

Во первых их количество может различаться, а во-вторых их конструкция тоже различна, как и радиусы движения

Радиусы отличны а кинематиака одинаковая. Матушка природа позаботилась о том чтобы задача инверсной кинематики для одной отдельно взятой конечности решалась очень просто. Подсказка - у любых существ конечность имеет 2 сегмента равной длины. У некоторых еще захват на конце но это имеет отношение не к решению задачи инверсной кинематики отлельно взятой конечности а к генерации задания для системы инверсной кинематики конечности.

@CoderHuligan · 05.09.2017, 15:24

Сообщение от Fulcrum_013

при этом код кинематики переписывать не надо было

То есть проблема в дополнительной писанине, и только?

Сообщение от Fulcrum_013

паучья и обезьянья лапки должны быть потомками универсальной лапки а паук и обезьяна потомком универсального солдата существа.

А что есть "универсальная лапка"?
А почему обязательно "должны"? Может вовсе и "не должны"?
Паук и обезьяна потомки универсального существа, - это круто! Это уже какую-то мистику навевает - "Унивесральное Существо", - это что-то из времён французской революции, - там как раз было это "универсальное существо"..
Насекомое и человек потомки от одной сущности? Представляю себе эту сущность: какое-то двуного насекомоподбное существо представляется, выкидашами которого оказались паук с человеком...
Это действительно смешно.

Сообщение от Fulcrum_013

К примеру комбобокс отличается от едита вообще на децел - наличием списка итемов. Не переписывать же из за этого различия всю обработку ресайза/аллигна и т.д. и т.п для каждого из них? Логично написать эту обработку один раз а потом породить пару потомков каждый из которых умеет установить/прочитать/модифицировать свой набоор вводимых данных.

А почему бы не переписать? Один раз написал и пользуйся всю жизнь. Ничего не придётся тащить следом. Они будут независимы ни от кого, так как используют только элементарные типы данных, как и должно быть. Программирование не должно подменить собой реальную жизнь. Оно имеет свою ограниченную область применения, в которой типы данных - плоские типы. Как только мы пытаемся выйти за рамки разумного, пытаясь определить одни типы через другие, то сразу же возникают множественные проблемы. Есть атомы и есть молекулы. Атомы - элементарные типы. Молекулы - наборы элементарных типов. Атомов и молекул ограниченное количество, но этого совершенно достаточно чтобы из них построить всё мироздание.

Сообщение от Fulcrum_013

Модуль в отличии от классов не может иметь инстансов.

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

Сообщение от Fulcrum_013

Вы за копи-паст кашу

Да нифига.
Повторяю: я за "один раз написал и забыл." А вы просто не думаете о тех, кто будет разгребать ваш код. Да его никто и не будет никогда разгребать, легче всё заново переписать.

Сообщение от Fulcrum_013

При этом у любого механизма существуют как закрываемые от внешнего вмешательства узлы так и используемые для связи с другими механизмами узлы (интерфейсы). Даже к примеру у банальных редуктора или лампочки.

Самому узлу от этого ни горячо ни холодно. Это нужно разрабам, чтобы не потеряться в джунглях кода. А чтобы не потеряться нужно всего лишь правильно расставить ориентиры.

Сообщение от Fulcrum_013

Ну а в общем задача сериализации особенно полиморфных данных в любом случае штука нетривиальная даже при наличии полного рефлекшина.

Ну, дык это у вас так всё сложно. Всё переплетено. Методы в структурах-классах. Как это всё разгребать?

Сообщение от Fulcrum_013

Матушка природа позаботилась о том чтобы задача инверсной кинематики для одной отдельно взятой конечности решалась очень просто.

Пишем функцию, которая отвечает за кинематику в общем.

@Fulcrum_013 · 05.09.2017, 16:02

Сообщение от CoderHuligan

Методы в структурах-классах.

Методы они только в вображении программиста. Виртуальные в только в VMT но никак не в стркуткурах классах

Добавлено через 2 минуты

Сообщение от CoderHuligan

Это нужно разрабам, чтобы не потеряться в джунглях кода.

Не только для этого. А еще и для того чтобы эти джунгли конктертно проредить. Толковый ООП код для крупных задач в 50-100 а то и более раз меньше процедурной лапши.

Добавлено через 5 минут

Сообщение от CoderHuligan

Пишем функцию, которая отвечает за кинематику в общем.

Кроме функции потребуется еще и хранение текущего состояния лапки по определению задачи инверсной кинематики.

Добавлено через 1 минуту

Сообщение от CoderHuligan

Самому узлу от этого ни горячо ни холодно.

Если бы электродвигателю не было бы жарко можно было бы делать корпус не люминиевым а деревянным. А вообще корпус у него для того чтобы всяких хулиганов током не долбануло.

Добавлено через 42 секунды

Сообщение от CoderHuligan

Да его никто и не будет никогда разгребать, легче всё заново переписать.

Легче переписать процедурную кашу. С ООП все очень даже наоборот.

Добавлено через 44 секунды

Сообщение от CoderHuligan

Повторяю: я за "один раз написал и забыл."

Вот именно этот принцип и позволяет реализовывать исключительно ООП.

Добавлено через 1 минуту

Сообщение от CoderHuligan

А почему бы не переписать?

А потому что подобных типов контролов с подобными отличиями штук как минимум 50. И номенклатура имеет свойство расти. Для каждого переписывать будете? А потом про какие то дебри кода рассказываете.

Добавлено через 7 минут

Сообщение от CoderHuligan

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

Пруф того что это гарантированно ведет к проблемам. Проблемы возникающие у евангелистов ФП и прочих быдлоархитекторов не осиливших формализацию задач пруфом не является.

Добавлено через 2 минуты

Сообщение от CoderHuligan

Ну, дык это у вас так всё сложно. Всё переплетено.

Что переплетено? С чем переплетено? Оно может быть переплетено только при эмуляции ООП средствами ФП.

Добавлено через 2 минуты

Сообщение от CoderHuligan

Да его никто и не будет никогда разгребать

А я его пишу не для того чтобы разгребать а для того чтобы использовать. А области видимости как раз и нужны чтобы случайно не уронить отвертку в редуктор при прикручивании редуктора к приводу и приводимому агрегату.

Добавлено через 11 минут

Сообщение от CoderHuligan

Насекомое и человек потомки от одной сущности?

Учите матчасть. Человек и насекомое восходят к общему узлу в классификации видов. А именно к животным.

@CoderHuligan · 05.09.2017, 16:35

Сообщение от Fulcrum_013

Методы они только в вображении программиста. Виртуальные в только в VMT но никак не в стркуткурах классах

Ну да: указателей в структурах классов разве не имеется? Просто их спрятали от вас. А как указатель скинуть в файл? То-то и оно..

Сообщение от Fulcrum_013

Не только для этого. А еще и для того чтобы эти джунгли конктертно проредить. Толковый ООП код для крупных задач в 50-100 а то и более раз меньше процедурной лапши.

Хо-хо.
А вы поглядите во что выльется ваш реальный код: процедурный как раз и будет в 10-100 раз меньше В РЕАЛЕ, то бишь, exe программа. Обман потребителя. ООП программы такие пухлые от чего? Примеры привести?
В процедурщине как раз может быть пухлый листинг, но короткая исполняемая программа. Но этот пухлый листинг легко структурируется.

Сообщение от Fulcrum_013

А потому что подобных типов контролов с подобными отличиями штук как минимум 50. И номенклатура имеет свойство расти. Для каждого переписывать будете? А потом про какие то дебри кода рассказываете.

Нет конечно. Не буду. Я же адекватный человек. Во всяком случае стремлюсь к этому ибо бывают конкретные заносы.
У каждого контрола есть свой тип. Небольшие отличия каждого(цвет глаз, форма носа) прописываются в типе этого контрола. Не надо обманывать самих себя: в типе каждого обьекта будет тоже самое нагромождение, которое просто скрыто от вас компилятором, но это не правильно - всё должно быть открыто для изменений независимо друг от друга.
Если растёт номенклатура, как вы выразились, то структурный тип находится у нас в одном месте, - именно в этом одном месте можно добавить дополнительные возможности. Причём методы-функции получают указатель на конкретную структуру-тип, поэтому такое изменение их никоим образом не затрагивает. Просто прописываются дополнительные функции для обработки " добавленной номенклатуры".

Сообщение от Fulcrum_013

Пруф того что это гарантированно ведет к проблемам.

Например. Один класс лежит у нас в одном файле. лежит себе и лежит. Другой тоже долго лежит в другом файле-модуле. Вдруг нам срочно понадобилось расширить свой функционал этого второго класса. Наследуем некоторые возможности первого. Теперь этот класс нельзя будет использовать отдельно от другого, в другом файле. Конечно, дело не в файлах, как таковых. Но повторное использование описания конкретного абстрактного обьекта осложняется. Да просто чтобы понять его поведение нужно будет рыться где-то ещё! Вместо того, чтобы собрать всё в одно место. Листинг распухнет? А моск не распухнет? До сих пор не распух?

Сообщение от Fulcrum_013

А области видимости как раз и нужны чтобы случайно не уронить отвертку в редуктор при прикручивании редуктора к приводу и приводимому агрегату.

Области видимости конечно полезная штука, но при определённы условиях они только мешают.

Добавлено через 1 минуту

Сообщение от Fulcrum_013

Человек и насекомое восходят к общему узлу в классификации видов. А именно к животным.

По дарвину? "Человек произошёл от обезьяны"? Есть другая теория - "обезьяна произошла от человека".

@Fulcrum_013 · 05.09.2017, 18:32

Сообщение от CoderHuligan

Ну да: указателей в структурах классов разве не имеется? Просто их спрятали от вас. А как указатель скинуть в файл? То-то и оно..

Указателей на что? На другие объекты? Так структур взаимосвязанных данных зависит от структуры обрабатываемых данных а не от парадигмы. И именно преобразование таких взаимосвязанных структур из одного адресного пространства в другое и является нетривиальной задачей особенно для полиморфных данных, вне зависимости от парадигмы. При этом указатель на VMT вообще не доступен. Он где то под капотом (обычно по отрицательному смещению) так что таким преобразованиям оно вообще никак не мешает, только помогает (к примеру возможно полиморфное получение RTTI путем хранения указателя на оное в VMT).

Добавлено через 1 минуту

Сообщение от CoderHuligan

Области видимости конечно полезная штука, но при определённы условиях они только мешают.

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

Добавлено через 8 минут

Сообщение от CoderHuligan

Но повторное использование описания конкретного абстрактного обьекта осложняется.

Вы похоже не понимаете смысл наследования. Оно нужно как раз для того чтобы расширять описания без дублирования. Да кстати с чего бы это расти листингу? Листинг этих двух библиотечных классов к листингу вашей программы в которой вы от них что то порождаете вообще никакого отношения не имеет. Для наследования листинг предков вообще не нужен, они могут существовать в уже скомпилированном виде.

Добавлено через 1 минуту

Сообщение от CoderHuligan

ричём методы-функции получают указатель на конкретную структуру-тип, поэтому такое изменение их никоим образом не затрагивает. Просто прописываются дополнительные функции для обработки " добавленной номенклатуры".

Это в первую очередь не функции а дополнения набора данных, причем не совместимые с другими дополнениями. К примеру эдит хранит строку, мемо список строк а имадж вообще битмап. А вот к примеру определение размеров и положения прямоугольника в которым им все это добро каждому по своему отрисовывать для всех одинаковое. Вот все это одинаковое выносим в базовый класс и расширяем его в потомках для обработки разных отрисовываемых/вводимых через оный прямоугольник данных для каждого по разному. В результате имеем 50-кратное повторное использование механизма позиционирования прямоугольника.

Добавлено через 6 минут

Сообщение от CoderHuligan

Да просто чтобы понять его поведение нужно будет рыться где-то ещё!

Не где то еще а в описании интерфейса. Оно сугубо пофиг как соответствие этому интерфейсу действует внутри. На то инкапсуляция и есть инкапсуляция чтобы реализация поведения одного класса/механизма остальным классам/механизмам взаимодействующим с ним была сугубо безразлична

Добавлено через 15 минут

Сообщение от CoderHuligan

По дарвину? "Человек произошёл от обезьяны"? Есть другая теория - "обезьяна произошла от человека".

Ну на самом деле немного не так. Люди и обезьяны произошли от общего предка. Одни осилили объединение самцов для совместной деятельности другие нет. Те кто осилили стали человеками те кто нет обезьянами. При этом эволюция идет и сейчас. Те человеки кто осилили ООП становятся Software Engeneer-ами а те кто не осилил деградируют до нового вида обезьян(monkey coders).

Добавлено через 56 минут

Сообщение от CoderHuligan

ООП программы такие пухлые от чего?

ООП программы обычно очень компактны. Пухлый код генерит тухлятина типа АТД с использованием статического полиморфизма вместо динамического. Да кстати гуй для которого ООП во всю пользовалось и пользоваться будет пухлым будет по определению. т.к. в екзешке/дллке хранится не только кот но и битмапки и прочие ресурсы. При отделении одних от других кота окажется кот наплакал. Но хранить их удобнее/надежнее в одном файле. Для этого собственно говоря PE формат и изобрели.

@CoderHuligan · 05.09.2017, 18:43

Сообщение от Fulcrum_013

Указателей на что? На другие объекты?

На методы.

Сообщение от Fulcrum_013

Вы похоже не понимаете смысл наследования. Оно нужно как раз для того чтобы расширять описания без дублирования.

Понятно. Чтобы стало быстрее кодить.. Оттуда забрал, здесь оттяпал, там занял.. Вот вам и спагетти. Листинга - децл, рабочего кода - море. Реальный обьект всё равно использует реальную память.
А почему, спрашивается нужно обязательно обойтись без дублирования?
Например инлайн функции помогают ускорить код за счёт увеличения рабочего кода программы именно за счёт дублирования.
Тут тоже: за счёт увеличения обьёма просто листинга программы, мы получаем преимущество повторного использования кода более мелкого описания обьектов. То есть, теперь можно повторно тащить более мелкие структуры и функции для работы с ними.
Что-то теряем второстепенного, но и что-то находим ценного..

Сообщение от Fulcrum_013

А вот к примеру определение размеров и положения прямоугольника в которым им все это добро каждому по своему отрисовывать для всех одинаковое. Вот все это одинаковое выносим в базовый класс и расширяем его в потомках для обработки разных отрисовываемых/вводимых через оный прямоугольник данных для каждого по разному.

Дак вы же всё равно будете описывать методы для каждого отдельного случая, и не важно что вызываться они будут под одним именем. То же самое можно сделать просто создав отдельную функцию для каждого случая.

Сообщение от Fulcrum_013

Не где то еще а в описании интерфейса.

А.. нужен ещё какое-то описание интерфейса без которого ничего не понять..

Сообщение от Fulcrum_013

Те кто осилили стали человеками те кто нет обезьянами. При этом эволюция идет и сейчас. Те человеки кто осилили ООП становятся Software Engeneer-ами

Коммерческими Software Engeneer-ами, а коммерция ничего не имеет с настоящим творчеством. Там надо штамповать, штамповать, штамповать...

@Fulcrum_013 · 06.09.2017, 11:38

Сообщение от CoderHuligan

Там надо штамповать, штамповать, штамповать...

Штампуют monkey-кодеры. А софтвер инжинер занимается софтвер инжинирингом, в результате штампует компутер.

Добавлено через 1 минуту

Сообщение от CoderHuligan

А.. нужен ещё какое-то описание интерфейса без которого ничего не понять..

А без описания интерфейса нигде ничего не понять. Даже в процедурной лапше. В недекмпозированной струкутурной лапше и интерфейсов как таковых нет.

Добавлено через 59 секунд

Сообщение от CoderHuligan

Дак вы же всё равно будете описывать методы для каждого отдельного случая, и не важно что вызываться они будут под одним именем. То же самое можно сделать просто создав отдельную функцию для каждого случая.

Только разница в том что объект будет знать какую именно функцию для него вызывать из этого набора.

Добавлено через 1 минуту

Сообщение от CoderHuligan

А почему, спрашивается нужно обязательно обойтись без дублирования?

По определению.

Добавлено через 4 минуты

Сообщение от CoderHuligan

Например инлайн функции помогают ускорить код за счёт увеличения рабочего кода программы именно за счёт дублирования.

Во первых это дублирование машинного кота а не исходного. Во вторых ускорение достигается далеко не во всех случаях. как только размер переходов между дублированными участками превышает 256 байт все никакого профита. При этом ощутимый профит от инлайнинга есть только на интеловской и подобных архитектурах по причине сброса кеша инструкций при длинном переходе.

Добавлено через 4 минуты

Сообщение от CoderHuligan

Чтобы стало быстрее кодить.. Оттуда забрал, здесь оттяпал, там занял..

ВО первых чтобы кодить было надежнее. Опять же вернемся к контролам. Есть механизм позиционирования. Он один раз реализован и отлажен для абстрактного контрола. Потомкам - конкретным контролам абсолютно не важно как он там внутри фунциклит, важно что он фунциклит, поэтому они просто без лишних заморочек включают его в себя да и все. Т.е. по принципу -продолжим построение своего конкретного механизма начиная с уже готового полуфабриката.

Добавлено через 5 минут
при этом в заголовке класса-потомка переписывается не весь интерфейс предка а только то чего у предка нету и те методы реализация которых переопределяется. К примеру в данном примере с контролами дублироваться из описания предка будет только перечисление абстрактных не реализованных в предке методов типа Paint и возможно деструктора. Всего остального что будет в их описании интерфейса в предке нет. Т.е. то что есть в слове класс описывает не только интерфейс но и какая его часть реализуется в этом классе.

Добавлено через 6 минут
Для примеру у меня в оконном фреймверке интерфейс абстрактного TControl около 150 строк. Интерфейсы его потомков -конкретных контролов пока что не более 10 строк при этом из того что есть в предке переопределяют не более 3 абстрактных методов каждый. Остальные просто используют в своем механизме не задумываясь как оно там устроено.

Добавлено через 26 минут

Сообщение от CoderHuligan

Листинга - децл, рабочего кода - море

Так это и есть производительность. К примеру на асме наоборот, Листинга море рабочего кода и его функционала -децел. Это низкая производительность называется. Да кстати в толково спроектированной ООП программе машкод обычно меньше исходника по объему. Ну естественно если не учитывать рантайм и т.п. который идет к любому коду.

Сообщение от CoderHuligan

Реальный обьект всё равно использует реальную память.

Ну как бы меньше памяти чем нужно для хранения моделируемых объектов предметной области и моделируемых взаимосвязей между ними использовать все равно не удастся. А накладные расходы при использовании ООП обычно мизерны. Даже при использовании двунаправленных указателей. Опять же в некоторых случаях для моделирования мелочи возможно применение мультиинстансных объектов (пулов и т.п.) для которых оверхед по памяти вообще стремится к нулю.

Добавлено через 37 минут

Сообщение от CoderHuligan

На методы.

Откуда им в объекте взяться?

Добавлено через 14 часов 41 минуту

Сообщение от CoderHuligan

Оттуда забрал, здесь оттяпал, там занял.. Вот вам и спагетти

Так говнокодеры кодят. А софтвер инженер который в первую очередь архитектор а потом уже кодер, сначала определяет степени готовности полуфабрикатов а потом уже кодит. в результате каждый полуфабрикат добавляет к тому что умеет предыдущий какой либо свой цельный и самодостаточный механизм, готовый к употреблению. При этом взаимодействующим объектам других классов достаточно взаимодействовать с каким либо одним из этих полуфабрикатов-механизмов не заботясь о том что там из этих полуфабрикатов запилят дальше. Ну к примеру с контролами - механизмы создания и отслеживания дерева отображения, приоритетов получения фокуса ввода, привязки и отображения попап-меню, хинтов, и т.д. реализуется на уровне базового TControl, а потомки этого уже не касаются, только дают данные в эти механизмы ну могут при этом и учитывать данные даваемые механизмами в своей жизнедеятельности.

Добавлено через 3 минуты
А к примеру скроллинг реализуется уже на уровне потомка-полуфабриката. Потому что не все контролы должны уметь скроллировать свое содержимое.

@pycture · 06.09.2017, 13:18

Сообщение от Fulcrum_013

Да кстати в толково спроектированной ООП программе машкод обычно меньше исходника по объему.

китайцы (и индусы) апплодируют стоя

@CoderHuligan · 06.09.2017, 13:51

Сообщение от Fulcrum_013

Только разница в том что объект будет знать какую именно функцию для него вызывать из этого набора.

А так разработчик будет знать какую функцию вызвать, ибо её имя ясно говорит о том к какому типу она относится. Не объект, а программист. Ведь при случае её можно вызвать из любой точки, а это иногда нужно.

Сообщение от Fulcrum_013

Потомкам - конкретным контролам абсолютно не важно как он там внутри фунциклит, важно что он фунциклит, поэтому они просто без лишних заморочек включают его в себя да и все. Т.е. по принципу -продолжим построение своего конкретного механизма начиная с уже готового полуфабриката.

Так всё равно обьекты-потомки неявно пользуются полями родителей в конкретном распределении памяти для конкретного обьекта.
Почему не сделать это явно, даже пользуясь декомпозицией по типам? Но лучше её не использовать.

Сообщение от Fulcrum_013

при этом в заголовке класса-потомка переписывается не весь интерфейс предка а только то чего у предка нету и те методы реализация которых переопределяется.

Ну.., а я этого не знал? Знаю ооп по Паскалю. Но ведь везде в общем одно и тоже? Надо бы подтянуть С++, тогда может быть я вам продемонстрирую на конкретных примерах. Просто раньше изучал другие языки: Паскаль, Бэйсик, Си, PHP, и некоторые другие.
Хорошо. Вот смотрю я на определение нового класса и вижу там, что он наследует от какого-то другого. Тут у меня сразу возникает дискомфорт от того, что нужно искать это "другое" чтобы понять "это самое". Ну, ладно пережили и нашли это другое(а это время). А в описании этого другого я вижу, что оно наследует тоже от другого, причём всего два поля данных и один виртуальный метод. Раздражение возрастает пропорционально глубине вложенности этого дубового дерева. Вроде вот он - объект, а вроде и нет его вовсе: он оказывается размазан по всему коду... Его части валяются повсюду: ноги здесь, руки там, а туловище висит на заборе.)) Прямо как после какого-то взрыва, наверное большого Ума?))
Скажете: какая разница как он написан и где? Большая разница, прежде всего для меня, как разработчика. Мне удобнее иметь на рабочем столе порядок: болтики разложены по своим коробкам, а гаечки по своим, да и отсортированы они по размерам. Тип одного обьекта должен быть описан в одном месте - это сокращает время на его понимание.
Кто-то сказал: "все методологии произошли от страха". А у страха, говорят, глаза велики..

Классифицируют по СМЫСЛУ, а не по типу..

Сообщение от Fulcrum_013

Откуда им в объекте взяться?

Разве их там в классе нет в реальности? В коде их нет понятно, их скрыли: высокий уровень, понимашь.

Сообщение от Fulcrum_013

Даже в процедурной лапше. В недекмпозированной струкутурной лапше и интерфейсов как таковых нет.

Если нужны, то будут.

@TRam_ · 06.09.2017, 15:49

Сообщение от CoderHuligan

болтики разложены по своим коробкам, а гаечки по своим, да и отсортированы они по размерам

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

А по поводу боязни наследования - никто и не заставляет принудительно им пользоваться. Но ведь намного же проще задать "поставить стирку стиралке" чем задать полный алгоритм для одной единственной модели стиралки, где искать дверцу/крышку для белья, для порошка, сколько белья класть, как и какой режим выставлять с помощью каких именно ручек/кнопок ...

@CoderHuligan · 06.09.2017, 16:22

Сообщение от TRam_

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

И правильно. Обьект - стиральная машина располагается в своём модуле, который представляет из себя, например, папку с файлами с её описанием и всей функциональностью. При этом, не нужно создавать монстра - общий тип-класс "стиральная машина" со всеми своими частями. Эти части представляют из себя отдельные, более мелкие типы данных: стиральный бак, мотор, подача воды и т.д. Они по смыслу обьединяются не общим классом, как в ООП, а общим модулем. При этом, все эти типы ничего у друг друга не наследуют, поэтому имеют в своем тельце чистые гены.

Сообщение от TRam_

А по поводу боязни наследования - никто и не заставляет принудительно им пользоваться.

Тогда это уже не ООП парадигма.

Сообщение от TRam_

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

У каждой модели имеются общие сущности, те же: стиральный бак, мотор, подача воды и т.д., которые отличаются в небольших пределах. Одинаковые вещи можно использовать напрямую для новой модели, которая может отличаться лишь своим дизайном и т.п.

@TRam_ · 06.09.2017, 16:30

Сообщение от CoderHuligan

У каждой модели имеются общие сущности, те же: стиральный бак, мотор, подача воды и т.д., которые отличаются в небольших пределах.

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

@CoderHuligan · 06.09.2017, 16:34

Сообщение от TRam_

Вот для того и используется наследование

А я твержу, что наследование в этом случае совершенно излишне. Подключаем к коду определённый файл с определённым функционалом и пользуем его типы и функции напрямую.

@TRam_ · 06.09.2017, 16:42

CoderHuligan, а у вас всегда получится из этих нескольких файлов сделать комбинацию таких функций? Чтобы не произошло конфликтов между ними, например из-за того, что функции имеют одно и то же название?

@Fulcrum_013 · 06.09.2017, 19:58

Сообщение от CoderHuligan

Не объект, а программист.

А накой ему это? Ему важно как дернуть тот или иной переключатель того или иного механизма конкретного объекта. А в каком именно классе оно реализовано - то заботы компилятора. При множественном наследовании вызов функций имеющихся у двоих и более предков обычно прячутся под капот потомка иначе в этом множественном наследовании просто нет смысла.
Типа вот так:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
class TEntity{
....
public:
    virtual TMovesList& GetPossibleMoves(&List) const=0;
}
class TBishop : virtual public  TEntity{
public:
     TMovesList& GetPossibleMoves() const override{
               TMovesList Ret;
               ....
              return Ret;
     }
}
 
class TRock : virtual public  TEntity{
public:
....
     TMovesList& GetPossibleMoves() const override{
               TMovesList Ret;
               ....
              return Ret;
     }
}
 
class TQueen: virual public TBishop,virtual public TRock{
public:
....
      TMovesList&  TQueen::GetPossibleMoves() const override{
            return  TBishop::GetPossibleMoves()+TRock::GetPossibleMoves();
 
      }
}

И даже наследование ромбом которого все говноляпы так боятся здесь только в помощь.

Добавлено через 6 минут

Сообщение от CoderHuligan

Эти части представляют из себя отдельные, более мелкие типы данных: стиральный бак, мотор, подача воды и т.д.

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

Добавлено через 3 минуты
Таже самая логика что и с контролами. Отличие только в том что сборка контролов сама является потомком контрола - панелью/формой и т.п. групповым котролом .

Добавлено через 5 минут

Сообщение от CoderHuligan

При этом, все эти типы ничего у друг друга не наследуют, поэтому имеют в своем тельце чистые гены.

Наоборот очень граязные. Без наследдования придется переписывать один и тот же механизм для каждого потомка что есть копи-паст говнокодинг. Мало того его не признают настоящим арийцем функции принимающие предка и расстреляют еррорами как еврея.

Добавлено через 8 минут

Сообщение от CoderHuligan

А так разработчик будет знать какую функцию вызвать, ибо её имя ясно говорит о том к какому типу она относится.

А идея как раз в том и состоит чтобы какую именно реализацию функции вызывать программмиста перестало заботить. Т.е. на этапе вызова методов интерфейса программист командует объекту что ему с собой сотворить. А как именно это сделать (какую именно реализацию метода вызывать) объект помнит сам.

Добавлено через 2 часа 39 минут

Сообщение от CoderHuligan

Они по смыслу обьединяются не общим классом, как в ООП, а общим модулем.

Вообще модулем по большому счету является каждая процедура. А класс по большому счету уже составной модуль. При этом если возьмем общетехническое определение модуля - то это черный ящик наделенный определенным функционалом и имеющий определенный интерфейс стыковки с более другими черными ящиками. Класс под это определение очень даже подходит. При этом модуль является сборочной еденицей - т.е. имеет инстансы в отличии от паскалевских юнитов являющихся релятивистскими конями в сферическом ваккууме.

Результаты опроса: используете ли вы ооп
да	238	86.55%
нет	37	13.45%
Голосовавшие: 275. Вы ещё не голосовали в этом опросе

Новые блоги и статьи Все статьи Все блоги /
сукцессия 44. Решил подать на припринт в межународные сервисы препринтов. Но нужно одобрение от ученых anaschu 25.07.2026 Английский вариант. Пока кто то не одобрит мою личность, мне не получиться это опубликовать на препринте. Но заявку на публикацию статьи я сегодня подам.	сукцессия 43. Вторая научная статья за месяц- прайминг и гатгил anaschu 25.07.2026 две стороны одной монеты	Более приземисто - Эстафету хвоста в .cdl (деревья эстафеты в сад). Hrethgir 24.07.2026 В будущем, после написания блока инверсии обхода дерева (эстафеты хвоста), я планирую вернуться к нашему прошлому разговору о том, обладают ли знания целеполаганием. Тогда я пришел к выводу, что. . .	Вот представьте что вам дали бессмертие. kumehtar 24.07.2026 Вот представьте что вам дали бессмертие, ничего более не меняя. Вообще ничего, только бессмертие в нынешнем виде. Рады были бы? Что бы вы тут делали всё это время? Никакой пенсии. Никакого нового. . .
сукцессия 41 anaschu 24.07.2026 Численная верификация бифуркации в агентной модели лесной сукцессии: от одного параметра к ансамблю Автор: пользователь @Shumilov_AS \| Раздел: Прикладная математика / Численные методы Кратко. . .	сукцессия 40. Ансамблевая кластерная параметризаци, часть 1. anaschu 24.07.2026 Пр# Сопровождение научной статьи ИИ-ассистентом: подготовка публикации и калибровка агентно-ориентированной модели сукцессии микоризных систем Полевые заметки о двухнедельной совместной работе. . .	Теория всего 12. ВГК на планете в стратегической игре "терра" anaschu 21.07.2026 ### Главные семантические изменения и дешифровка новой физики 1. `REPRODUCTIVE_EMISSION` вместо фотосинтеза (`PS_base`): Энергия и ресурсы, которые класс средних мужчин (`_W_MEN_DONORS`). . .	Публикация отклонённая на хабре. Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование задачи и целеполагание Hrethgir 21.07.2026 https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11948&stc=1&d=1784657928 Привет Хабр. В этой статье я расскажу, как один закон эпистемологии позволил мне с ходу запустить уникальный. . .

@@KOT@ 81 / 39 / 3 Регистрация: 29.01.2010 Сообщений: 386

	Стоит ли использовать ООП? 09.02.2010, 13:44. Показов 103118. Ответов 793 Метки нет (Все метки) Здравствуйте. Возник такой вопрос: стоит ли использовать ооп. Даже не так, когда использовать ооп? Иногда (даже чаще всего) легче написать простые функции, а не мутить с классами обектами и методами. Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени. 5

@TRam_ зомбяк 1585 / 1219 / 345 Регистрация: 14.05.2017 Сообщений: 3,940
	06.09.2017, 16:42
	CoderHuligan, а у вас всегда получится из этих нескольких файлов сделать комбинацию таких функций? Чтобы не произошло конфликтов между ними, например из-за того, что функции имеют одно и то же название? 0