Всем привет
Давно озадачился вопросом:
что может прийти на смену ООП (в смысле обьектов обменивающихся сообщениями)?
ООП на мой вгляд себя исчерпало, т.к. предел "понятной сложности" в ООП, слишком мал для текущих задач... Я имею в виду, что при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро. Человеку сложно удержать "образ системы". Конечно есть специальные технологии(например UML) которые позволяют отодвинуть границу понимания, но общей проблемы-то они не решают...
Есть теория что люди не могут выйти за границы понимания мира как "собрание взаимодействующих обьектов". Это похоже на то как двухмерные создания, не могут постичь создания трехмерные...
Какие будут мнения? Обсуждаемая проблема — "предел понятной сложности в ООП"...
Здравствуйте, Joker6413, Вы писали:
J>Всем привет J>Давно озадачился вопросом: J>что может прийти на смену ООП (в смысле обьектов обменивающихся сообщениями)?
J>ООП на мой вгляд себя исчерпало, т.к. предел "понятной сложности" в ООП, слишком мал для текущих задач... Я имею в виду, что при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро. Человеку сложно удержать "образ системы". Конечно есть специальные технологии(например UML) которые позволяют отодвинуть границу понимания, но общей проблемы-то они не решают...
J>Есть теория что люди не могут выйти за границы понимания мира как "собрание взаимодействующих обьектов". Это похоже на то как двухмерные создания, не могут постичь создания трехмерные...
J>Какие будут мнения? Обсуждаемая проблема — "предел понятной сложности в ООП"...
Можно ещё нафантазировать что-то вроде такого:
1. Нечёткая типизация
2. Контекстно-зависимая типизация
3. Недискретные объекты
4. Реинкарнация Пролога
5. ... уффф...
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, Joker6413, Вы писали:
J>>Всем привет J>>Давно озадачился вопросом: J>>что может прийти на смену ООП (в смысле обьектов обменивающихся сообщениями)?
J>>ООП на мой вгляд себя исчерпало, т.к. предел "понятной сложности" в ООП, слишком мал для текущих задач... Я имею в виду, что при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро. Человеку сложно удержать "образ системы". Конечно есть специальные технологии(например UML) которые позволяют отодвинуть границу понимания, но общей проблемы-то они не решают...
J>>Есть теория что люди не могут выйти за границы понимания мира как "собрание взаимодействующих обьектов". Это похоже на то как двухмерные создания, не могут постичь создания трехмерные...
J>>Какие будут мнения? Обсуждаемая проблема — "предел понятной сложности в ООП"...
V>Сильно перекликается с этой моей темой
Есть немного. Я думаю мы копаем в одном направлении...
Но я обозначил проблему "при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро, делая систему сложной для понимания". Мне интересно ЧТО потенциально поможет с этой проблемой справиться...
V>Можно ещё нафантазировать что-то вроде такого: V>1. Нечёткая типизация V>2. Контекстно-зависимая типизация V>3. Недискретные объекты V>4. Реинкарнация Пролога V>5. ... уффф...
Можно конечно, но лично мне пока не ясно зачем... Как только четко обозначится проблема, сразу будет видно что необходимо, а что лишнее...
J>Но я обозначил проблему "при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро, делая систему сложной для понимания". Мне интересно ЧТО потенциально поможет с этой проблемой справиться...
Кстати, именно для этого я и измышлял множественную классификацию.
V>>Можно ещё нафантазировать что-то вроде такого: V>>1. Нечёткая типизация V>>2. Контекстно-зависимая типизация V>>3. Недискретные объекты V>>4. Реинкарнация Пролога V>>5. ... уффф...
J>Можно конечно, но лично мне пока не ясно зачем... Как только четко обозначится проблема, сразу будет видно что необходимо, а что лишнее...
Да всё для того же. Для более адекватного отражения логики предметной области.
Думаю, что ООП в том или ином виде останется, но появится большое количество тулзов, генерящих исходный код программ по заданной разработчиком информации. Что-то типа AppWizard'ов, но очень-очень продвинутых и позволяющих очень тонко затачивать генерируемый код под нужды программера. Собственно, процесс программирования будет во многом сводиться к написанию таких тулзов и управлению ими для отдельно взятого проекта.
Здравствуйте, heathcliff, Вы писали:
H>Думаю, что ООП в том или ином виде останется, но появится большое количество тулзов, генерящих исходный код программ по заданной разработчиком информации. Что-то типа AppWizard'ов, но очень-очень продвинутых и позволяющих очень тонко затачивать генерируемый код под нужды программера. Собственно, процесс программирования будет во многом сводиться к написанию таких тулзов и управлению ими для отдельно взятого проекта.
Замечательно...
А какие методы будут использоваться для создания таких тулзов?
Видимо другие тулзы, генерящие тулзы первого порядка
Ну и над всем этим будет стоять великий гуру
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, Joker6413, Вы писали:
J>>Но я обозначил проблему "при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро, делая систему сложной для понимания". Мне интересно ЧТО потенциально поможет с этой проблемой справиться...
V>Кстати, именно для этого я и измышлял множественную классификацию.
Не понятно, чем множественная классификация может принципиально помочь для понимания сложных систем. Вот например у меня в проекте 20 уникальных взаимодействующих сущностей, как их классифицировать чтобы упростить схему, раз они и так уникльные? Хорошо я нарисую схему и можно будет разобраться... но реального способа СПРАВИТЬСЯ со сложностью я не вижу...
V>>>Можно ещё нафантазировать что-то вроде такого: V>>>1. Нечёткая типизация V>>>2. Контекстно-зависимая типизация V>>>3. Недискретные объекты V>>>4. Реинкарнация Пролога V>>>5. ... уффф...
J>>Можно конечно, но лично мне пока не ясно зачем... Как только четко обозначится проблема, сразу будет видно что необходимо, а что лишнее...
V>Да всё для того же. Для более адекватного отражения логики предметной области.
Хорошо подходит. Но все же у меня проблема в другом, оставим за рамками обсуждения адекватность представления логики предметной области, т.к. она (адекватность) целиком зависит от отображения объектов "реальных" в объекты виртуальные. Т.е. сохраняется изначальный ООП подход, который переносится в систему... Дальше см. выше, от этого хочется по возможности уйти.
Здравствуйте, Joker6413, Вы писали:
J>>>Но я обозначил проблему "при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро, делая систему сложной для понимания". Мне интересно ЧТО потенциально поможет с этой проблемой справиться...
V>>Кстати, именно для этого я и измышлял множественную классификацию.
J>Не понятно, чем множественная классификация может принципиально помочь для понимания сложных систем. Вот например у меня в проекте 20 уникальных взаимодействующих сущностей, как их классифицировать чтобы упростить схему, раз они и так уникльные? Хорошо я нарисую схему и можно будет разобраться... но реального способа СПРАВИТЬСЯ со сложностью я не вижу...
Здесь уж извиняйте, если предметная область и её логика сложны, то и отражение в программе должно быть по крайней мере не менее сложным. Хуже, когда сложную предметную область приходится описывать программой, которую мы вынуждены будем сделать ещё более сложной.
J>Хорошо подходит. Но все же у меня проблема в другом, оставим за рамками обсуждения адекватность представления логики предметной области, т.к. она (адекватность) целиком зависит от отображения объектов "реальных" в объекты виртуальные. Т.е. сохраняется изначальный ООП подход, который переносится в систему... Дальше см. выше, от этого хочется по возможности уйти.
Согласен. В принципе можно найти предметную область в которой вообще не будет объектов, и тогда, естественно, ОО-подход не будет применим ни под каким соусом.
B>Замечательно... B>А какие методы будут использоваться для создания таких тулзов? B>Видимо другие тулзы, генерящие тулзы первого порядка B>Ну и над всем этим будет стоять великий гуру
Очень простые методы. Они уже вовсю используются, правда фрагментарно (те же Rational Rose, BPWin, ASP, PHP...). Описывается бизнес-модель проекта и ряд технических характеристик (как выглядит GUI, какой метод используется для доступа к БД и т.д.). Описание представляется в виде, который способна понять интерпретирующая программа (очень хорошо для этого подходит XML). Задаются правила преобразования объектной модели в исходный код. А дальше все на раз-два. Получается application framework, заточенный под конкретный проект. Естественно, какое-то количество кода потом дописывается руками, без этого пока не обойтись. Но управлять проектом, построенным по такому принципу, гораздо легче, чем написанным полностью вручную.
Здравствуйте, heathcliff, Вы писали:
H>Думаю, что ООП в том или ином виде останется, но появится большое количество тулзов, генерящих исходный код программ по заданной разработчиком информации. Что-то типа AppWizard'ов, но очень-очень продвинутых и позволяющих очень тонко затачивать генерируемый код под нужды программера. Собственно, процесс программирования будет во многом сводиться к написанию таких тулзов и управлению ими для отдельно взятого проекта.
Когда придумали asm, наверняка посчитали, что дальнейшее развитие — это всего лишь будет написание уймы библиотек на все случаи жизни. В реальности, как Вы понимаете, всё получилось совсем по-другому.
"Все случаи жизни" — очень сильное понятие. В принципе, VC++ — это как раз такой тул, который может генерить код на все случаи жизни, и написание сишных исходников — это управление им для отдельно взятого проекта.
А что до интеллектуальных AppWizard'ов, то, как всегда бывает, найдутся задачи, для которых нет подходящего визарда. Ну придёт, допустим, клиент с мешком денег и скажет, что ему ну вот позарез нужно автоматизированная система управления хрюкотанием зелюков, реализующая алгоритм Мазефакера при достижении хливкими шорьками фубаровского распределения частоты пыряния по наве. И что делать несчастному программеру? Можно, конечно сходить на RSDN и убедиться, что волшебного тулза для хрюкотающих зелюков в природе не существует.
Хотите верьте, а хотите — нет, но в подавляющем большинстве случаев бывает легче по-простянке настучать текст программы, чем неделю таскать мышкой по экрану квадратики и стрелочки.
Здравствуйте, heathcliff, Вы писали:
B>>Замечательно... B>>А какие методы будут использоваться для создания таких тулзов? B>>Видимо другие тулзы, генерящие тулзы первого порядка B>>Ну и над всем этим будет стоять великий гуру H>Очень простые методы. Они уже вовсю используются, правда фрагментарно (те же Rational Rose, BPWin, ASP, PHP...). Описывается бизнес-модель проекта и ряд технических характеристик (как выглядит GUI, какой метод используется для доступа к БД и т.д.). Описание представляется в виде, который способна понять интерпретирующая программа (очень хорошо для этого подходит XML). Задаются правила преобразования объектной модели в исходный код. А дальше все на раз-два. Получается application framework, заточенный под конкретный проект. Естественно, какое-то количество кода потом дописывается руками, без этого пока не обойтись. Но управлять проектом, построенным по такому принципу, гораздо легче, чем написанным полностью вручную.
Бывает, когда берётся готовая программа и настраивается параметрически. Но это уже совсем другая сказка, хотя человека, подкручивающего настроечки уважительно называют программистом.
А ещё бывает, что просто инсталлируется Excel, и пользователю говорится, что все его проблемы он теперь в состоянии решить сам. Какие Rational Rose, BPWin, ASP, PHP...? Excel — вот самый универсальный тул!
Здравствуйте, Voblin, Вы писали:
V>А что до интеллектуальных AppWizard'ов, то, как всегда бывает, найдутся задачи, для которых нет подходящего визарда.
Я вполне с этим согласен, но кто сказал, что программер не сможет сам написать нужный AppWizard? Проблема только в том, чтобы сделать процесс написания прозрачным и удобным. Согласитесь, если в проекте 100 похожих друг на друга диалогов и 300 похожих друг на друга классов для доступа к БД, то разумно было бы потратить некоторое время, чтобы автоматизировать процесс их написания? К тому же проекты имеют тенденцию со временем расти и усложняться, а бизнес требования — изменяться. А у кого из нас есть настолько много времени, чтобы вносить однотипные изменения в 100 однотипных исходников? Поэтому очень разумно автоматизировать рутинные процедуры!
V>Хотите верьте, а хотите — нет, но в подавляющем большинстве случаев бывает легче по-простянке настучать текст программы, чем неделю таскать мышкой по экрану квадратики и стрелочки.
Конечно, если программа короткая, или если не планируется использовать ее долго.
Здравствуйте, heathcliff, Вы писали:
H>Здравствуйте, Voblin, Вы писали:
V>>А что до интеллектуальных AppWizard'ов, то, как всегда бывает, найдутся задачи, для которых нет подходящего визарда. H>Я вполне с этим согласен, но кто сказал, что программер не сможет сам написать нужный AppWizard? Проблема только в том, чтобы сделать процесс написания прозрачным и удобным. Согласитесь, если в проекте 100 похожих друг на друга диалогов и 300 похожих друг на друга классов для доступа к БД, то разумно было бы потратить некоторое время, чтобы автоматизировать процесс их написания? К тому же проекты имеют тенденцию со временем расти и усложняться, а бизнес требования — изменяться. А у кого из нас есть настолько много времени, чтобы вносить однотипные изменения в 100 однотипных исходников? Поэтому очень разумно автоматизировать рутинные процедуры!
Конечно, лучше день потренироваться, а потом за пять минут долететь
V>>Хотите верьте, а хотите — нет, но в подавляющем большинстве случаев бывает легче по-простянке настучать текст программы, чем неделю таскать мышкой по экрану квадратики и стрелочки. H>Конечно, если программа короткая, или если не планируется использовать ее долго.
Всяко бывает
А вы не считаете, что вопрос ставится неправомерно?.
Правильнее было бы сказать: «Что последовало за ООП?». С моей точки зрения.
Если посмотреть со стороны, то каждый последующий принцип (назовите как угодно, технология, парадигма программирования, философия и и т.д.) позволяет все больше абстрагироваться от конкретной реализации, и писать на более высоком уровне, при этом, если необходимо, опускаясь настолько на нижние уровни, насколько это необходимо. Вам ничего не говорит ряд:
Машинные коды
Ассемблер
Структурное программирование
ООП
Что было дальше?
Первый новый принцип, который был введен после понятия класса — был интерфейс (в понятии COM, CORBA). До этого в понятие интерфейс вкладывался несколько другое значение. Некоторые варианты сохранились до сих пор. Например, не изменилось значение интерфейса пользователя. А под интерфейсом модуля, обычно понималось API которое модуль предоставлял.
Следующий принцип, который появился почти сразу же — понятие компонента, и сразу вслед за этим понятие компонентной модели. В качестве примера: COM. В неявном виде следом за Микрософт: Java, Delphi и CORBA (CORBA, по моему, еще не доработала свою компонентную модель).
Если посмотреть на предложенный ряд, то можно заметить, что налицо повышение уровня абстракции в коде, который пишет человек. Чем больше автоматически генерит кода компилятор, тем уже область применения технологии. Опять таки, заметьте, что сейчас существуют люди, работающие исключительно на машинных кодах, или ассемблере, или использующие только структурное программирование, etc. Просто в рамках их задач нет необходимости в более высоком уровне.
Возможно это не ряд, а дерево, и от каждого узла отрываются не одна ветка, а больше, ну так это понятно, чем выше уровень абстракции, тем уже область применения.
Здравствуйте, heathcliff, Вы писали:
H>Здравствуйте, Voblin, Вы писали:
V>>А что до интеллектуальных AppWizard'ов, то, как всегда бывает, найдутся задачи, для которых нет подходящего визарда. H>Я вполне с этим согласен, но кто сказал, что программер не сможет сам написать нужный AppWizard? Проблема только в том, чтобы сделать процесс написания прозрачным и удобным.
Гораздо большую проблему представляет собой сопровождение написанного кода.
H>Согласитесь, если в проекте 100 похожих друг на друга диалогов и 300 похожих друг на друга классов для доступа к БД, то разумно было бы потратить некоторое время, чтобы автоматизировать процесс их написания?
Нет, конечно. Куда разумнее потратить это время на продумывание вопросов повторного использования единожды написанного кода.
H>К тому же проекты имеют тенденцию со временем расти и усложняться, а бизнес требования — изменяться. А у кого из нас есть настолько много времени, чтобы вносить однотипные изменения в 100 однотипных исходников? Поэтому очень разумно автоматизировать рутинные процедуры!
Это не визардами должно делаться, а на уровне языка. Что-нибудь вроде шаблонов в C++, только погибче и помощнее.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, heathcliff, Вы писали:
H>Я вполне с этим согласен, но кто сказал, что программер не сможет сам написать нужный AppWizard? Проблема только в том, чтобы сделать процесс написания прозрачным и удобным. Согласитесь, если в проекте 100 похожих друг на друга диалогов и 300 похожих друг на друга классов для доступа к БД, то разумно было бы потратить некоторое время, чтобы автоматизировать процесс их написания? К тому же проекты имеют тенденцию со временем расти и усложняться, а бизнес требования — изменяться. А у кого из нас есть настолько много времени, чтобы вносить однотипные изменения в 100 однотипных исходников? Поэтому очень разумно автоматизировать рутинные процедуры!
В таких ситуациях уже нужно выделять метаобъекты!
И собирать метаинформацию о них. То есть часть системы разрабатывать на метауровне, например, описать поведение диалога по отношению к окну. А потом уже порождать уже конкретные экземпляры метаобъектов — в нашем случае это будут классы диалоговых окон.
Я это к чему. Если для некоторого класса похожих объектов не полениться определить метаобъект, их все характеризующий, а потом описать его поведение, то можно будет существенно снизить сложность конкретных объектов (конкретных классов). А так же повысится понимание системы за счет уменьшения количества связей (оно уменьшится, так как большое количество связей перейдет на метауровень).
В принципе, стандартный подход борьбы с возрастающей сложностью.
И, если внимательно вчитаться, получится что все сводиться к полиморфизму объектов от метаобъектов . ООП !
Только в данном случае полиформизм, скорее всего, будет реализовываться не средствами языка программирования, а какими-либо иными средствами.
В качестве примера можно привести такую систему:
— в виде бинарного кода представлены только метаобъекты и фабрики, умеющие порождать в run-time нужные объекты по их метаописанию из, к примеру, конфигурационного файла. Причем эти фабрики должны уметь связывать порожденные объекты в конфигурации, реализующие некоторую желаемую для пользователя функциональность.
Здравствуйте, Joker6413, Вы писали:
J>ООП на мой вгляд себя исчерпало, т.к. предел "понятной сложности" в ООП, слишком мал для текущих задач... Я имею в виду, что при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро. Человеку сложно удержать "образ системы". Конечно есть специальные технологии(например UML) которые позволяют отодвинуть границу понимания, но общей проблемы-то они не решают...
Основная проблема существующего ООП — это статичность объектной модели.
Сила концепций инкапсуляции и наследования в том, что можно "поделить" предметную область на некоторые подобласти (ну, скажем, неймспейсы), которые взаимодействуют между собой не "каждый с каждым". Внутри каждой области можно выделить еще более мелкие сущности и т.д.
Это и есть единственный известный на данный момент способ контроля сложности.
Собственно, забегая немного назад, сложность и выражается в том, что в произвольно взятом наборе из N сущностей возникает ~N^2 двуместных связей.
Потому задача современного программирования — сделать так, чтобы каждая сущность взаимодействовала не более чем с десятком других. Неважно, что это будет — класс, объект, модуль, домен или еще что-то. Каждая "окрестность" должна быть невелика.
Так вот проблемы-то возникают в основном из-за того, что
а) понимание предметной области меняется в процессе проектирования/разработки (идентифицируются новые сущности, или возникают новые связи). К несчастью, современное коммерческое программирование не позволяет потратить пару тысяч лет на поиск наиболее адекватной модели чего бы то ни было.
б) сама предметная область меняется в процессе проектирования/разработки/эксплуатации приложения.
Таким образом, модель должна успевать за изменением условий. Иначе она теряет свою адекватность, и появляются заплатки и исключения. Вначале удается поддерживать корректность, но сложность начинает неконтролируемо расти, а это затрудняет поддержку корректности.
Два основных подхода, известных мне, это статический и динамический.
При статическом подходе мы пытаемся добавлять новые уровни абстракции в модель. Раньше вся модель сводилась к описанию классов, а всякие рутинные вещи типа VMT и размеров генерил компилятор. Теперь мы придумываем, например, шаблоны, и компилятор начинает генерировать классы, для которых он генерирует VMT и все такое. Дальше мы придумываем UML и тул, который генерирует эти шаблоны...
Динамический подход (ака рефакторинг) расширяет эту технику, предоставляя нам удобную возможность изменить модель на произвольно взятом уровне. Например, разделить монолитный класс на два — предка и наследника, чтобы дать возможность отнаследоваться "повыше" в дереве. Или объявить часть класса интерфейсом, вынести его наружу... Все это с сохранением корректности уже написанного кода, т.е. если уж мы вынесли что-то в интерфейс, то тот код, который раньше пользовался ссылкой на наш класс, должен (если подмножество использованных методов соответствует) теперь брать ссылку на интерфейс. И т.п.
Лично я думаю, что развитие средств поддержки этих подходов и будет генеральной линией партии на ближайшие пару десятков лет.
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sergey, Вы писали:
S>Гораздо большую проблему представляет собой сопровождение написанного кода.
Никто не спорил с этим. К тому же, изложенная выше концепция помогает решать и эту задачу в том числе.
H>>Согласитесь, если в проекте 100 похожих друг на друга диалогов и 300 похожих друг на друга классов для доступа к БД, то разумно было бы потратить некоторое время, чтобы автоматизировать процесс их написания? S>[...] Нет, конечно. Куда разумнее потратить это время на продумывание вопросов повторного использования единожды написанного кода. S>[...] Это не визардами должно делаться, а на уровне языка. Что-нибудь вроде шаблонов в C++, только погибче и помощнее.
Смотря что понимать под визардом. Шаблоны С++ — это тоже своего рода визард. Я под визардом понимаю некое обобщенное facility для эффективного управления исходным кодом. Чтобы бы это ни было по сути.
Здравствуйте, mikkri, Вы писали:
M>[...] В принципе, стандартный подход борьбы с возрастающей сложностью. M>И, если внимательно вчитаться, получится что все сводиться к полиморфизму объектов от метаобъектов . ООП ! M>Только в данном случае полиформизм, скорее всего, будет реализовываться не средствами языка программирования, а какими-либо иными средствами.
Абсолютно правильно Вы поняли! Пожалуй, если судить с этой точки зрения, то ничего нового по сравнению с ООП тут и нет. Возможно, правильнее было бы это назвать "одним из методов борьбы с все возрастающей сложностью". Я и не претендую на открытие новой парадигмы. Меня гораздо больше интересует практическое применение изложенной методики.
. ООП 
Я и не претендую на открытие новой парадигмы. Меня гораздо больше интересует практическое применение изложенной методики.
