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

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

5

Сообщение от Fulcrum_013 Вообще модулем по большому счету является каждая процедура.

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

Сообщение от Fulcrum_013 При этом модуль является сборочной еденицей - т.е. имеет инстансы в отличии от паскалевских юнитов являющихся релятивистскими конями в сферическом ваккууме.

Это реализовано только в Обероне.

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

Зачем переписывать? Берём старый тип если он подходит. Добавляем в модуль другой тип, который расширяет функционал первого и пишем его функции-обработчики. И имеете любой вариант, хоть ракету на угле.

0

Сообщение от CoderHuligan Это реализовано только в Обероне.

Это реализовано еще в симуле и называется класс.

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

Сообщение от CoderHuligan Зачем переписывать? Берём старый тип если он подходит. Добавляем в модуль другой тип, который расширяет функционал первого и пишем его функции-обработчики. И имеете любой вариант, хоть ракету на угле.

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

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

Сообщение от CoderHuligan Процедура это одна из составных частей модуля. Для самого модуля это компонент.

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

Добавлено через 14 минут
Вообще модуль по англицки будет module но ни как не unit.

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

Сообщение от CoderHuligan И имеете любой вариант, хоть ракету на угле

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

0

Сообщение от Fulcrum_013 Пухлый код генерит тухлятина типа АТД с использованием статического полиморфизма вместо динамического.

Алгебраические Типы Данных обеспечивают динамический полиморфизм.

0

Сообщение от Shamil1 Алгебраические Типы Данных обеспечивают динамический полиморфизм.

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

0

Сообщение от Fulcrum_013 Вообще то не алгебраические а абстрактные.

В ООП используются абстрактные типы данных.

0

Сообщение от Fulcrum_013 А теперь представьте что ракета оная может в первой ступени кроме ускорителей на угле иметь еще ускорители на кока-коле с ментосом. Причем в каком сочитании заранее не известно. Определяется при навеске оных на стартовом столе (т.е. в рантайме) а в перспективе в полете на станции дозаправки по маршруту Земля-Тау Кита-Туманность Анромеды), при этом на каком топливе будет работать навешиваемые на заправочной станции ТауКита ступени на момент старта с Земли неизвестно,

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

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

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

0

Сообщение от CoderHuligan в каком состоянии находится программа

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

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

0

Сообщение от TRam_ Ведь проще на ускорители "метку типа" нанести, по ней и выбирать алгоритм.

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

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

Сообщение от CoderHuligan Полиморфизм, тем более динамический, должен быть у нас в голове.

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

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

0

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

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

Сообщение от TRam_ а программа-то тут при чём?

Программа как целое имеет своё глобальное состояние, поэтому обязательно имеется тот, кто контролирует его. Это можно назвать неким "контекстным программированием"..

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

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

0

Сообщение от CoderHuligan Немудрено, что ракеты стали так часто падать:-)..

За всю историю комонавтики по софту упала одна непилотируемая ракета.

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

Сообщение от CoderHuligan Программа ракеты это глобальная функция, которая контролирует свой контекст,

Если что либо имеет контекст то это уже не функция.

Сообщение от CoderHuligan Обьекты управления в каждый момент времени имеют свои собственные контексты, которые определяют их собственное поведение.

Т.е. без объектов таки никуда.

Сообщение от CoderHuligan Но обязательно должен быть начальный, глобальный Контекст, некое Начало и Конец в одном лице глобальной функции-управленца.

Системы управления конца не имеют, только кылдык в результате сбоя.

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

Сообщение от CoderHuligan Так поступают все сишники, когда, к примеру, пишут библиотеку. В этом случае конфликт имён исключён.

А когда сишникам нужен динамический полиморфизм они имеют свойство изобретать С++.
Когда их стошнит от помеси венегрета с оливье залитого манкой и линейного роста количества изменений при добавлении новой сущности в номенклатуру объектов предметной области которое требуется при полиморфизме 8-го класса они тоже изобретают С++.
Теперя про хацкеля и прочую ФП баламуть.
Итак берем хацкель. Берем абстрактный объект предметной области имеющий 200 функция. Теперя делаем 50 уточнейний абстракции. Теперя добавьте в эти крабочки перемешанные с ливьешкой и залитые манкой 51-ый объект предметной области. Закохаетесь искать куда и где что вписать. Сложность добавления нового уточнения абстракции будет O(n). В отличии от const у ООП. ВЫвод напрашивается сам собой - хацкель и вообще ФП непригодны для современной промышленной разработки так же как и процедурщина. Потому как маразматический полиморфизм 8-го класса пользуемый в хацкеле так и полиморфизм 8-го класа пользуемый в процедурщине труе динамическим полиморфизмом не являются. алгебраические типы данных это нечто из богомерзкой противоестественной динамической типизации но никак не из области полиморфизма.

0

Сообщение от Fulcrum_013 Если что либо имеет контекст то это уже не функция.

Ага, это монада.

0

Сообщение от korvin_ Ага, это монада.

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

0

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

Потрясает умение ООП-шников думать, что они придумали всё и вся и наделять чужие слова выдуманым смыслом.

1

Сообщение от Fulcrum_013 За всю историю комонавтики по софту упала одна непилотируемая ракета.

Французская? А у нас сколько упало? Но ведь у нас правду всё равно не скажут..

Сообщение от Fulcrum_013 Если что либо имеет контекст то это уже не функция.

Начали лупить лозунгами? Может у вас в голове "смешались кони, люди..." и вы уже не можете отличить функциональное от процедурного, в котором, кстати, процедура может быть функцией и наоборот. Это разные вещи, как кстати и языки. Функциональщики всегда стремились избавиться от контекста, чтобы было чистая функциональность, но у них не слишком стало получаться взаимодействие с реальным миром, поэтому им приходится изобретать разные прибамбасы типа монад, функторов и пр., чтобы создать видимость их изначальной парадигмы. Так что они движутся в правильном направлении, только другим путём.. Возможно когда-нибудь и выйдут из леса..
ИМПЕРАТивщикам проще, ибо они по определению имеют ИМПЕРАТивный склад ума изначально, то бишь царь или ИМПЕРАТор у них в голове и на деле в коде всё же остаётся. Так что у ИМПЕРАТивщиков контекст остаётся в неприкосновенности, а в недалёком будущем займёт свой достойный пьедестал, став одним из краеугольных камней программирования вообще, со своими специализированными языками и пр.

Сообщение от Fulcrum_013 Т.е. без объектов таки никуда.

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

Сообщение от Fulcrum_013 А когда сишникам нужен динамический полиморфизм они имеют свойство изобретать С++.

Он просто ненужен им, вот почему многие от си++ бегут обратно в си, или к функциональным языкам.

Сообщение от Fulcrum_013 Когда их стошнит от помеси венегрета с оливье залитого манкой и линейного роста количества изменений при добавлении новой сущности в номенклатуру объектов предметной области которое требуется при полиморфизме 8-го класса они тоже изобретают С++.

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

1

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

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

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

Сообщение от CoderHuligan А всё различие достигается лексикологически

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

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

Сообщение от CoderHuligan Он просто ненужен им, вот почему многие от си++ бегут обратно в си, или к функциональным языкам.

Такой большой а в сказки верите. Ни ФП ни процедурщина не пригодны для современной разработки софта.

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

Сообщение от CoderHuligan Может у вас в голове "смешались кони, люди..."

Функция это зависимость входного аргумента от выходного. Каким боком тут контекст коий является не чем иным как набором переменных описывающих состояние какого либо объекта?

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

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

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

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

Сообщение от CoderHuligan Просто это не является чистой прерогативой ООП, как такового.

Является по определению парадигмы.

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

Сообщение от CoderHuligan Просто там не смешали всё в одну кучу. Наверно проспали ООП-революцию..

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

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

Сообщение от CoderHuligan А у нас сколько упало? Но ведь у нас правду всё равно не скажут..

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

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

Сообщение от CoderHuligan А у нас сколько упало? Но ведь у нас правду всё равно не скажут..

А у вас батентька СУО ракет вообще времен каменного века.Там вычислений нема. Только включение/выключение/форсаж/дросселирование двигателей по таймеру. 2КБ ОЗУ на ферритовых кольцах и цикломатическая схема управления - т.е. фактически электронная имитация шагового искателя. Ну естественно что при вводе операций в цикломатическую таблицу ошибки и просчеты неизбежны, сколько его на стендах не гоняй.

0

Сообщение от Fulcrum_013 Системы управления конца не имеют, только кылдык в результате сбоя.

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

Сообщение от Fulcrum_013 Добавьте туда квантового программиста не изменяя уже написанного кота.

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

Сообщение от Fulcrum_013 Вообще то путем конкретизации абстракции. Соответсвенно лексика должна оставаться неизменной. Кстати именно так и достигается истинная декларативность - путем труе полиморфизма.

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

Сообщение от Fulcrum_013 Функция это зависимость входного аргумента от выходного. Каким боком тут контекст коий является не чем иным как набором переменных описывающих состояние какого либо объекта?

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

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

Сообщение от Fulcrum_013 Добавьте туда квантового программиста не изменяя уже написанного кота.

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

0

Сообщение от CoderHuligan Затем я добавляю, не трогая ни строчки кода в описании других обьектов, дополнительные структуры данных и функции

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

Сообщение от CoderHuligan Некоторые измененения потребуются в описании поведения контролирующих модулей, но это неизбежность.

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

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

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

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

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

Сообщение от CoderHuligan Вот видите: мы собираем состояние обьекта в одном месте, как и его описания.

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

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

Сообщение от CoderHuligan мы собираем состояние обьекта в одном месте, как и его описания

Теперь представьте у вас есть библиотека контролов оборачивающая (ну или реализующая) оконное АПИ оси. Представьте что номенклатура конкретных контролов 1000+. Теперя в API добавилась какая то новая фича . Ну к примеру флаг полупрозрачности форточки. С наследованием достаточно добавить этот флаг и его обработку в абстактный класс оборачивающий (или реализующий) окно API. В скольких местах те же самые изменения придется внести с тем что вы пытаетесь донести? Так где все в одном месте а где каша размазанная по куче модулей?

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

Сообщение от CoderHuligan Ну, вот, язык гипертекстовой разметки - HTML является чисто декларативным языком, однако его считают примитивным языком, который создаёт больше ограничений, чем возможностей.

HTML языком программирования не является. Это формат представления данных т.е. - язык с точки зрения семиотики (теории знаковых систем), но не язык программирования.

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

Сообщение от CoderHuligan В отличие от декларативных языков, императивные оперируют понятием команды.

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

0

Сообщение от Fulcrum_013 А без наследования никак? Вы собираетесь костылить наследование вручную наступая при этом на тройные грабли.

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

Сообщение от Fulcrum_013 При динамическом полиморфизме даже не перекомпилировать. Т.е полиморфизмой при вашем подходе и не пахнет.

Почему? Всё то же самое, только без эфемерных коней в компиляторе.

Сообщение от Fulcrum_013 Да что вы такое говорите. Возьмем банально контрол. У него есть

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

Сообщение от Fulcrum_013 - Указатель на владельца. - Номер в списке рабов. - Динамический список рабов. - Указатель на предка. - Номер в списке детев. - Динамический список детев. - Приоритет отрисовки. - Приоритет получения фокуса ввод - динамический список наблюдателей. - динамический список делегатов для оповещения об удалении. - курсор - цвет - шрифт - указатель на контекстное меню.

это просто входные переменные. Сами по себе они не определяют поведение контрола.
Что касается флагов:

Сообщение от Fulcrum_013 - флаг видимости. - Флаг только для чтения. - флаг вклчен/выключен. - флаг включен в очередь получения фокуса ввода. - - флаг "уничтожаюсь"

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

Сообщение от Fulcrum_013 Каким образом мистер Дейкстра собирается запихуть все это в одну переменную?

Мистеру Дейкстре(всё-таки гениальный был человек!) достаточно опредилить те состояния, в которых может находится тот или иной обьект, в данном случае кнопка(нажата, отжата, поменяла цвет и т.п.), короче говоря - все её допустимые состояния. И в зависимости от текущего значения определять что предпринимать в дальнейшем, то бишь, в какое новое состояние перейти изменив значение этой переменной.

Сообщение от Fulcrum_013 И получаем кучу копипаста и граблей. В результате теряем абстрактные сущности. Т.е. в конечном итоге каждому объекту нужно много механизмов.

Так все механизмы остаются в нашем распоряжении.

Сообщение от Fulcrum_013 Т.е. то что вы хочете донести давно вынесено на свалку.

Нет. То, что я хочу донести, ещё широко не использовалось, - только в некоторых проектах.

Сообщение от Fulcrum_013 В скольких местах те же самые изменения придется внести с тем что вы пытаетесь донести? Так где все в одном месте а где каша размазанная по куче модулей?

А у вас не каша, не? У вас гораздо больше зависимостей, чем в модульном подходе. Я могу пользоваться определениями типов и функциями из других модулей, но мой модуль не является наследником других, как и другие не есть наследники этого. Здесь есть взаимное доверие и уважение. У вас есть взаимные цепи..

Сообщение от Fulcrum_013 HTML языком программирования не является.

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

Сообщение от Fulcrum_013 - Надпрограмма всегда декларативна относительно вызываемых ей подпрограмм.

Нет. Она императивно приказывает другой подпрограмме выполниться.

Сообщение от Fulcrum_013 - Любой набор любых инструкций (коими являются и декларации) явно или не совсем явно является набором команд исполнителю - т.е. императивными командами.

Можно сказать и так. Только вопрос как это будет в реале исполнено ложиться на исполнителя. Оно глубоко скрыто от нас..

0

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

А декларация это и есть приказ что либо делать без разьяснения как. Но для того чтобы так можно было исполнитель уже должен знать как это сделать.
К примеру html-тег означает ни что иное как команда "установить шрифту свойство вес равным значению хранимому в переменной bold". В чем разница с SetWeight(Bold);?

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

Сообщение от CoderHuligan А любой язык описывает проблему и даёт инструкции,

НЕ путайте языки программирования и языки (форматы) описания данных. Это две огромные разницы.

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

Сообщение от CoderHuligan Нет. То, что я хочу донести, ещё широко не использовалось, - только в некоторых проектах.

Оно вынесено на свалку истории в 60-х

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

Сообщение от CoderHuligan Вот от этих флагов можно вполне избавиться. Вводим состояния обьекта:

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

0

Сообщение от CoderHuligan Я могу пользоваться определениями типов и функциями из других модулей, но мой модуль не является наследником других, как и другие не есть наследники этого

это значит у вас отсутствует повторное использование кода функций у схожих типов.

Сообщение от CoderHuligan это просто входные переменные. Сами по себе они не определяют поведение контрола.

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

0