Re[2]: Что будет следовать за ООП? - Архитектура программного обеспечения

Здравствуйте, Voblin, Вы писали:

V>Здравствуйте, Joker6413, Вы писали:

J>>Всем привет
J>>Давно озадачился вопросом:
J>>что может прийти на смену ООП (в смысле обьектов обменивающихся сообщениями)?

J>>ООП на мой вгляд себя исчерпало, т.к. предел "понятной сложности" в ООП, слишком мал для текущих задач... Я имею в виду, что при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро. Человеку сложно удержать "образ системы". Конечно есть специальные технологии(например UML) которые позволяют отодвинуть границу понимания, но общей проблемы-то они не решают...

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

J>>Какие будут мнения? Обсуждаемая проблема — "предел понятной сложности в ООП"...

V>Сильно перекликается с этой моей темой, лежащей рядом. Или нет?

Есть немного. Я думаю мы копаем в одном направлении...

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

V>Можно ещё нафантазировать что-то вроде такого:
V>1. Нечёткая типизация
V>2. Контекстно-зависимая типизация
V>3. Недискретные объекты
V>4. Реинкарнация Пролога
V>5. ... уффф...

Можно конечно, но лично мне пока не ясно зачем... Как только четко обозначится проблема, сразу будет видно что необходимо, а что лишнее...

Игорь

Здравствуйте, Joker6413, Вы писали:

J>Но я обозначил проблему "при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро, делая систему сложной для понимания". Мне интересно ЧТО потенциально поможет с этой проблемой справиться...

Кстати, именно для этого я и измышлял множественную классификацию.

V>>Можно ещё нафантазировать что-то вроде такого:
V>>1. Нечёткая типизация
V>>2. Контекстно-зависимая типизация
V>>3. Недискретные объекты
V>>4. Реинкарнация Пролога
V>>5. ... уффф...

J>Можно конечно, но лично мне пока не ясно зачем... Как только четко обозначится проблема, сразу будет видно что необходимо, а что лишнее...

Да всё для того же. Для более адекватного отражения логики предметной области.

Думаю, что ООП в том или ином виде останется, но появится большое количество тулзов, генерящих исходный код программ по заданной разработчиком информации. Что-то типа 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++, только погибче и помощнее.

Здравствуйте, 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>Только в данном случае полиформизм, скорее всего, будет реализовываться не средствами языка программирования, а какими-либо иными средствами.
Абсолютно правильно Вы поняли! Пожалуй, если судить с этой точки зрения, то ничего нового по сравнению с ООП тут и нет. Возможно, правильнее было бы это назвать "одним из методов борьбы с все возрастающей сложностью".

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

Здравствуйте, Sinclair, Вы писали:

S>Основная проблема существующего ООП — это статичность объектной модели.
Очень правильно!

S>Динамический подход (ака рефакторинг) расширяет эту технику, предоставляя нам удобную возможность изменить модель на произвольно взятом уровне. Например, разделить монолитный класс на два — предка и наследника, чтобы дать возможность отнаследоваться "повыше" в дереве. Или объявить часть класса интерфейсом, вынести его наружу... Все это с сохранением корректности уже написанного кода, т.е. если уж мы вынесли что-то в интерфейс, то тот код, который раньше пользовался ссылкой на наш класс, должен (если подмножество использованных методов соответствует) теперь брать ссылку на интерфейс. И т.п.
А можно поподробнее? Как можно "изменить модель на произвольно взятом уровне" с "с сохранением корректности уже написанного кода"? IMHO в общем случае это невозможно, так как обычно отсутствует возможность оперативно и с минимальными затратами сил корректировать уже написанный код. Речь идет о незначительных изменениях модели или о продвинутых технологиях создания кода? Поясните, что имелось ввиду, плиз. Интересует чисто техническая сторона дела.

Здравствуйте, scaramush, Вы писали:

S>[...] чем выше уровень абстракции, тем уже область применения.
Либо я Вас не понял, либо это не так. Поясните, пожалуйста.
На мой взгляд, чем выше уровень абстракции, тем область потенциального применения шире. Просто для конкретного применения абстрактные сущности должны быть конкретизированы.

Здравствуйте, heathcliff, Вы писали:

H>А можно поподробнее? Как можно "изменить модель на произвольно взятом уровне" с "с сохранением корректности уже написанного кода"? IMHO в общем случае это невозможно, так как обычно отсутствует возможность оперативно и с минимальными затратами сил корректировать уже написанный код. Речь идет о незначительных изменениях модели или о продвинутых технологиях создания кода? Поясните, что имелось ввиду, плиз. Интересует чисто техническая сторона дела.
Имеются в виду "продвинутые технологии создания кода". Некоторые из них уже реализованы; о некоторых надо мечтать. Основные существующие инструменты не предоставляют достаточного сервиса. Например, большинство кодогенераторов из UML ограничиваются генерацией деклараций. Это означает, что такое действие, как разделение класса на пару наследник/потомок приведет к необходимости править собственно код руками. Интеллектуальный инструмент нашел бы все вхождения используемого класса и изменил бы код соответствующим образом. У меня не хватает эрудиции обсуждать конкретные свойства конкретных инструментов для рефакторинга, но необходимость в определенной функциональности я вижу.
Ключевая идея в том, что мы имеем в момент 1 некоторую модель, которая является корректной. Т.е. она адекватно отражает наши представления о предметной области. При этом модель уже обросда "мясом", вплоть до наличия корректно функционирующего приложения. В момент 2 мы обнаруживаем несовершенство наших представлений и корректируем их. В рамках существующей модели внесение изменений ведет к значительному усложнению (т.е. увеличению числа взаимодействий между элементами модели). Поэтому перед расширением модели возникает желание изменить модель так, чтобы в момент 2 мы имели не менее корректную модель, отражающую наши предыдущие представления. (очевидно, что таких корректных моделей — бесконечное количество). При этом никаких потерь не должно происходить — если мы имели работающее приложение в момент 1, то мы должны все еще его иметь.
Эта новая модель должна отличаться от предыдущей ровно одним свойством — расширение ее для соответствия новым представлениям не должно увеличивать локальную сложность так значительно.

... << RSDN@Home 1.0 beta 7a >>

Здравствуйте, Sinclair, Вы писали:

...
Интересная тема. То-же не выдержал решил подключиться. Хотя мое мнение возможно и парадоксально. Как-то пришлось программировать в двоичных кодах (скажем так — заставили). Испытал настоящий шок. Во первых было открытием, что ASM команда, ну никак не транслируется в один машинный код, во вторых оказалось, для того, чтобы вчесть РОН из РОНа совсем не обязательно переводить число в доп.код а затем складывать, в третьих ... список можно продолжать и продолжать.
К чему это я, а к тому, что с возростанием уровня абстракции избыточность, неоптимальность, объем и т.д. кода растет в геометрической прогрессии.
Когда появились персоналки, стоял крик, что это истина в последней инстанции, народ быстро повыбрасывал EC (IBM360). Сейчас вовсю используются терминальные версии, сервера приложений, в Нью Йорке, Мэр пробивает идею супер фрейма для города (а по домам и офисам, типа вообще системные блоки не нужны). Как Вам это, ничего не напоминает.
Идем дальше, использавание интеллектуальных датчиков, контроллеров и т.д. IMHO с такой периферией остается только интерфейс.
Идем дальше, компы Be (ветка от MAC), единственная разработка, которой в штатах, за всю историю, при презентации рукоплескали стоя. Да, они как-то втихаря загнулись (денег не хватило или задавили). Но ведь писюк в сегодняшнем виде себя исчерпал.
........
IMHO, должен быть качественный скачок (Be — было попыткой). Для этого правда надо пристрелить дядю Билли (жадный был наш дядя Билли, дети дядю не любили). Вполне возможно, этот скачок уже происходит. Что мы например знаем о технологиях и ПО той-же IBM. Те-же СУБД IBM держат 39% амер.рынка и никакого отношения к InterBase или Oracle (17%) не имеют.
........
А если предположить, что качественный скачок будет (IMHO все предидущее развитие, со времени первых PC — все-таки колличественное), то вполне возможно ООП и идеями ООП там пахнуть и не будет . В конце концов — переход линейное-структурное-ООП это на глобальном уровне, всего-лишь возможность создавать ПО все большими и большими толпами разработчиков, говорить о том, что это оптимальное или если хотите красивое (ну не технический термин — знаю) не приходится.
........
Кто такой ЩАС программер, ну кто угодно, но не творец, чуть, что — иди читай MSDN, НУ ЧТО ЗА БРЕД, ГОСПОДИ. Это, ЧТО истина в последней инстанции, изучать тупые куски написанные левой ногой, чтоб подтвердить, что винда бозя всех бозь в последней инстанции.

Здравствуйте, Sinclair, Вы писали:

S>Имеются в виду "продвинутые технологии создания кода".
Значит мы мыслим в одном направлении.

Здравствуйте, heathcliff, Вы писали:

H>Здравствуйте, scaramush, Вы писали:

S>>[...] чем выше уровень абстракции, тем уже область применения.
H>Либо я Вас не понял, либо это не так. Поясните, пожалуйста.
H>На мой взгляд, чем выше уровень абстракции, тем область потенциального применения шире. Просто для конкретного применения абстрактные сущности должны быть конкретизированы.

Имеется в виду уровень абстракции, а не абстрактные сущности.
Пример:

первый уровень абстракции: COM на голом С/С++
второй уровень абстракции: библиотека ATL.

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

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

Здравствуйте, Vlad232ua, Вы писали:

V> К чему это я, а к тому, что с возростанием уровня абстракции избыточность, неоптимальность, объем и т.д. кода растет в геометрической прогрессии.
Хм. Очень интересное мнение. А вот академик Ершов, например, считал путем к оптимальности т.н. смешанные вычисления. Все пересказывать не буду, но принцип — в том, что из более общего и абстрактного алгоритма можно получить более оптимальный для частного случая вполне детерминированным путем. А вот получить из алгоритма, оптимального в одном частном случае, алгоритм, оптимальный в другом частном случае почему-то в общем случае нельзя.
Это я к тому, что даже не учитывая оптимальность в разработке мы вынужденно приходим к необходимости введения абстракций как раз для уменьшения избыточности, неоптимальности, объема и т.д. кода.
Более того, это вовсе не теория. Как ни странно, редкий программист сейчас сможет существенно улучшить производительность, объем и.т.д. кода, который генерят современные компиляторы С++. А они, в общем-то, как раз и пользуются теми самыми теоретическими положениями, разработанными Ершовым и его последователями.

V> Когда появились персоналки, стоял крик, что это истина в последней инстанции, народ быстро повыбрасывал EC (IBM360). Сейчас вовсю используются терминальные версии, сервера приложений, в Нью Йорке, Мэр пробивает идею супер фрейма для города (а по домам и офисам, типа вообще системные блоки не нужны). Как Вам это, ничего не напоминает.
Да. Мне это напоминает маятник. Неизбежное свойство систем с ограниченной скоростью распространения взаимодействий. Никакого отношения к ООП это, увы, не имеет — ни за ни против.
V> Идем дальше, использавание интеллектуальных датчиков, контроллеров и т.д. IMHO с такой периферией остается только интерфейс.
Хм. То есть эти интеллектуальные датчики сами по себе соединятся в систему, которая будет делать что-то полезное? Очень интересно.
V> Идем дальше, компы Be (ветка от MAC), единственная разработка, которой в штатах, за всю историю, при презентации рукоплескали стоя. Да, они как-то втихаря загнулись (денег не хватило или задавили). Но ведь писюк в сегодняшнем виде себя исчерпал.
Это тоже интересное мнение. Я пока не вижу симптомов исчерпания писюка.
V> IMHO, должен быть качественный скачок (Be — было попыткой). Для этого правда надо пристрелить дядю Билли (жадный был наш дядя Билли, дети дядю не любили).
Это — тема отдельного рассуждения. Вкратце: ребята, Билли никому пистолет к виску не приставляет со словами "пользуйте ООП", или "... Windows" или еще что-то. Он также никак не виноват в том, что отечественная информатика находится в глубоком отверстии, по MTV гоняют попсу, а от программера Евпилдора ушла девушка.
V> Вполне возможно, этот скачок уже происходит. Что мы например знаем о технологиях и ПО той-же IBM. Те-же СУБД IBM держат 39% амер.рынка и никакого отношения к InterBase или Oracle (17%) не имеют.
Мы? Много знаем. Пока IBM не повернется к пользователям лицом, и не наймет хотя бы десяток спецов по юзабилити, потребительский рынок будет занят кем-то другим. Да, у них обалденные разработки в РСУБД. Почти все технологические особенности MS SQL 2000 присутствовали у них еще 10-20 лет назад. Но взгляните на MS SQL Query Analyzer, Profiler, и Enterprize Manager, а также на www.tpc.org, и вы получите адекватное представление о том, кто будет рулить enterprize сектором в 2010.
V>........
V> А если предположить, что качественный скачок будет (IMHO все предидущее развитие, со времени первых PC — все-таки колличественное), то вполне возможно ООП и идеями ООП там пахнуть и не будет .
Я думаю, что "закрыть" ООП уже не удастся. Да, программирование неизбежно изменится, но запах ООП все еще будет. Что, в ООП не пахнет модульным программированием?
V> В конце концов — переход линейное-структурное-ООП это на глобальном уровне, всего-лишь возможность создавать ПО все большими и большими толпами разработчиков, говорить о том, что это оптимальное или если хотите красивое (ну не технический термин — знаю) не приходится.
V>........
Ну, для начала, возможность создавать ПО большими толпами разработчиков — это принципиальное требование к современным технологиям программирования. Допустим у нас есть проект Хы. И оценка его трудоемкости — десять в четвертой человеко-лет. Если выбранная технология ограничивает количество одновременно работающих участников десятью, то про нее можно забыть сразу и навсегда. Даже если код будет оптимальнее, красивее, и.т.д. Хорошо было древним египтянам — строили себе Карнакских храм две тысячи лет, и не боялись, что конкуренты применят более совершенную технологию, или что заказчик перестанет испытывать в нем необходимость. А сейчас рулят не ассемблерные вставки, а TTM (time to market).
Красота кода — это понятие субъективное, потому я воздержусь от ее обсуждения до последнего

.
А вот оптимальность — вполне измеримое. Я в свое время был изрядно потрясен тем фактом, что БПФ (быстрое преобразование фурье) имеет достаточно строгое математическое обоснование, неизвестное большинству программистов. И что есть способ построения таких алгоритмов. И что для него вовсе не требуется, чтобы количество элементов в массиве было равно степени двойки. Что оптимальность алгоритма зависит только от количества множителей в разложении этого числа (потому-то двойку так любят). Но эти факты невыразимы на ассемблере в принципе. Для того, чтобы воспользоваться ими, необходимо работать на значительно более высоком уровне абстракции.
V> Кто такой ЩАС программер, ну кто угодно, но не творец, чуть, что — иди читай MSDN, НУ ЧТО ЗА БРЕД, ГОСПОДИ. Это, ЧТО истина в последней инстанции, изучать тупые куски написанные левой ногой, чтоб подтвердить, что винда бозя всех бозь в последней инстанции.
Нда. Опять. Где ООП — и где МСДН? Хороший программист и сейчас — творец. Только для этого надо очень много чего прочитать. И, в частности, МСДН — потому, что матчасть надо знать. Не работаете под винду — читайте маны. В любом случае надо читать всяких Кнутов, Бучей, Александреску и иже с ними. Потому как одного знания алгоритма неполной разборки БТР-70 недостаточно для того, чтобы командовать даже взводом.

... << RSDN@Home 1.0 beta 7a >>

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Joker6413, Вы писали:

S>Основная проблема существующего ООП — это статичность объектной модели.

Мне не ясна суть проблемы... в чем преимущество ООП с динамической объектной моделью?

S>Сила концепций инкапсуляции и наследования в том, что можно "поделить" предметную область на некоторые подобласти (ну, скажем, неймспейсы), которые взаимодействуют между собой не "каждый с каждым". Внутри каждой области можно выделить еще более мелкие сущности и т.д.

S>Это и есть единственный известный на данный момент способ контроля сложности.

S>Собственно, забегая немного назад, сложность и выражается в том, что в произвольно взятом наборе из N сущностей возникает ~N^2 двуместных связей.

S>Потому задача современного программирования — сделать так, чтобы каждая сущность взаимодействовала не более чем с десятком других. Неважно, что это будет — класс, объект, модуль, домен или еще что-то. Каждая "окрестность" должна быть невелика.

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

S>Так вот проблемы-то возникают в основном из-за того, что

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

S>б) сама предметная область меняется в процессе проектирования/разработки/эксплуатации приложения.

S>Таким образом, модель должна успевать за изменением условий. Иначе она теряет свою адекватность, и появляются заплатки и исключения. Вначале удается поддерживать корректность, но сложность начинает неконтролируемо расти, а это затрудняет поддержку корректности.

Поддежка адекватности — проблема субъективная, система же не может выяснить, что она неверно отображает реальность... Хотя кое-что здесь сделать все таки можно.

S>Динамический подход (ака рефакторинг) расширяет эту технику, предоставляя нам удобную возможность изменить модель на произвольно взятом уровне. Например, разделить монолитный класс на два — предка и наследника, чтобы дать возможность отнаследоваться "повыше" в дереве. Или объявить часть класса интерфейсом, вынести его наружу... Все это с сохранением корректности уже написанного кода, т.е. если уж мы вынесли что-то в интерфейс, то тот код, который раньше пользовался ссылкой на наш класс, должен (если подмножество использованных методов соответствует) теперь брать ссылку на интерфейс. И т.п.

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

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

Игорь

Здравствуйте, scaramush, Вы писали:

S>приведем пример с UML.
S>UML слабо применим для написания программ для микроконтроллеров.
Кто тебе сказал?
Не знаю, что ты имеешь в виду под UML, но, к примеру, и Use Cases и Sequences Diagram
вполне можно использовать при программировании микроконтроллеров.
(Только кому это надо? Там другие инструменты.)
В любом случае: описывай систему, а как она будет реализована это уже другой вопрос.

S>Они в некоторых случаях программируются даже не на ассемблере, а непосредственно в машинных кодах.
Ты уверен, что точно знаешь разницу между ассемблером и машинными кодами?
Или просто по случаю употребил?
В кратце: ассемблер — некая оболочка над машинными кодами.
Избавляет от утомительного ручного рассчета опкодов, смещений и проч. + читабельность
Может объяснишь, зачем использовать машкод вместо ассемблера?

Кстати, под микроконтроллеры есть компиляторы C, Pascal, Basic...
(Сам писал и на асме и на С (IAR))

S>Просто весь код для такого микроконтроллера уместится в одной UML сущности.
Неверно. Все зависит от степени "детализации" твоего описания.
А код бывает достаточно объемным и "насыщенным".

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

S>Причем одной такой сущности соответсвует на самом деле не одна, а множество программ.
Совсем ерунда.

Ты зря думаешь, что если микроконтроллеры "маленькие", то и программы у них маленькие...
Люди на них даже web сервер делали... Один чип — один web сервер.

(К сожалению не помню адреса)

Здравствуйте, Joker6413, Вы писали:

J>Давно озадачился вопросом:
J>что может прийти на смену ООП (в смысле обьектов обменивающихся сообщениями)?
J>ООП на мой вгляд себя исчерпало, т.к. предел "понятной сложности" в ООП, слишком мал для текущих задач...

А может быть, не стоит обобщать без достаточных на то оснований?

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

J>Я имею в виду, что при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро. Человеку сложно удержать "образ системы". Конечно есть специальные технологии(например UML) которые позволяют отодвинуть границу понимания, но общей проблемы-то они не решают...

И не решат никогда.

Но эта проблема вызвана неадекватной организацией мышления конкретного проектировщика, а не применённой им парадигмы.

J>Какие будут мнения? Обсуждаемая проблема — "предел понятной сложности в ООП"...

Я поёрничаю немного.

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

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

PPS. Нет никакой ложки, всё дело — в тебе. (c) "Матрица"

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, Joker6413, Вы писали:

ГВ>А может быть, не стоит обобщать без достаточных на то оснований?

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

Конечно личный опыт...

ГВ>И не решат никогда.

Но эта проблема вызвана неадекватной организацией мышления конкретного проектировщика, а не применённой им парадигмы.

Пример агрегации: вот у меня от 5 до 10 различных источников данных... Естейственно я храню их в массиве объекта класса (в принципе вариант агрегации), что же тут неправомерного с точки зрения "правильного дизайна"?

ГВ>Я поёрничаю немного.

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

O.K. дайте критерий "грамотно спроектированной" системы... Не спорю глупо спроектированные системы как правило не понятны...

ГВ>PS. Камень в твой огород, но не наезда ради, а чтобы указать на ошибку в твоей посылке. Попытка "удержать всю систему в голове", говорит, для меня, по крайней мере, о том, что ты столкнулся с очень бестолково спроектированной системой. Но я не думаю, что ты пытаешься сделать её сам.

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

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

Игорь

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

Общий смысл моего замечания, если оно кому-то непонятно:
не имеет смысл рисовать блок схему (или использовать UML) для программы Hello, World.

Здравствуйте, scaramush, Вы писали:

S>не имеет смысл рисовать блок схему (или использовать UML) для программы Hello, World.
Вот так и говори. А то микроконтроллеры зачем-то приплел...

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Vlad232ua, Вы писали:

V>> К чему это я, а к тому, что с возростанием уровня абстракции избыточность, неоптимальность, объем и т.д. кода растет в геометрической прогрессии.
S>Хм. Очень интересное мнение. А вот академик Ершов, например, считал путем к оптимальности т.н. смешанные вычисления. Все пересказывать не буду, ...
...
Как говориться "я сам брат из этих, но в песне ты не понял, увы ничего"

Здравствуйте, Joker6413, Вы писали:

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

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

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

... << RSDN@Home 1.1 alpha 1 >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Joker6413, Вы писали:

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

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

Да я конечно не спорю что существуют понятные ОО-проекты, так же как и не понятные ОО-проекты, так же как и огромные системы созданные с помощью структурных методов...

Но от "структурных методов" отошли, почему? Их прокляли магией вууду? Нет, ОО-методы позволяют реализовывать системы "с такой же сложностью" гораздо меньшими усилиями + доп. бонусы ООП... Вот в чем суть, назови меня лентяем, но я все время хочу получать уменьшение усилий на выполнение проекта, а в ООП переодически подхожу к барьеру у которого "увеличение полезности системы" на копейку стоит рубль (налицо необходимость рефакторинга, т.е. практически создания новой системы... значит я у границы ООП пускай даже своей собственной).

Игорь

Здравствуйте, Joker6413, Вы писали:

J>Да я конечно не спорю что существуют понятные ОО-проекты, так же как и не понятные ОО-проекты, так же как и огромные системы созданные с помощью структурных методов...

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

J>Но от "структурных методов" отошли, почему?

Кто тебе сказал? Внутренняя реализация класса вполне себе структурной парадигме соответствует, никто от нее не отходил, просто конструкции языка стали более высокоуровневыми и абстрактными.

J> Их прокляли магией вууду? Нет, ОО-методы позволяют реализовывать системы "с такой же сложностью" гораздо меньшими усилиями

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

J> + доп. бонусы ООП... Вот в чем суть, назови меня лентяем, но я все время хочу получать уменьшение усилий на выполнение проекта, а в ООП переодически подхожу к барьеру у которого "увеличение полезности системы" на копейку стоит рубль (налицо необходимость рефакторинга, т.е. практически создания новой системы... значит я у границы ООП пускай даже своей собственной).

Ты опять подменяешь понятия. ООП тут не при чем. В том что ты подходишь к барьеру виновата не парадигма, а неверные решения при проектировании.

... << RSDN@Home 1.1 alpha 1 >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Опять ты меня не понял. Я пытался сказать что используемая парадигма программирования прямого отношения к управляемости проекта не имеет.

Конечно имеет...
сравни создание окна в Mfc и создание окна в сишном проекте (я напомню RegisterClassEx строчек 20, CreateWindow строчек 10 плюс цикл выборки сообщений строчек 15...

J>>Но от "структурных методов" отошли, почему?

AVK>Кто тебе сказал?

Я тебе говорю, я давно не встречал "структурных" библиотек (математич. не в счет). Да и ты сам поди давно "структурных" программ не писал..

Внутренняя реализация класса вполне себе структурной парадигме соответствует, никто от нее не отходил, просто конструкции языка стали более высокоуровневыми и абстрактными.
Ну и что? И структурные и обьектные программы в результате преобразуются в машинные коды и что с того? Я вообще не видел чтобы программировали в машинных кода (embedded системы не в счет).

AVK>Вот именно — меньшими усилиями. Однако понятность конечного результата от этого зависит слабо.

Почему? В чем тогда заключаются меньшие усилия? И потом я никогда не встречал формулировки: результат разработки мало понятен, мы что-то сделали, а что будем дальше разбираться...

Наоборот — реализовали систему, она делает то-то и то-то. Понятными способами, сюрпризов — минимум...

J>> + доп. бонусы ООП... Вот в чем суть, назови меня лентяем, но я все время хочу получать уменьшение усилий на выполнение проекта, а в ООП переодически подхожу к барьеру у которого "увеличение полезности системы" на копейку стоит рубль (налицо необходимость рефакторинга, т.е. практически создания новой системы... значит я у границы ООП пускай даже своей собственной).

AVK>Ты опять подменяешь понятия. ООП тут не при чем. В том что ты подходишь к барьеру виновата не парадигма, а неверные решения при проектировании.

Ну вот опять... ты можешь разделить проектные решения на верные и неверные? Расскажи мне о критерии...

Игорь

Здравствуйте, Joker6413, Вы писали:

AVK>>Опять ты меня не понял. Я пытался сказать что используемая парадигма программирования прямого отношения к управляемости проекта не имеет.

J>Конечно имеет...

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

J>сравни создание окна в Mfc и создание окна в сишном проекте (я напомню RegisterClassEx строчек 20, CreateWindow строчек 10 плюс цикл выборки сообщений строчек 15...

Ты путаешь проектирование и реализацию. Создание окна в MFC меньше не потому что она использует ООП, а потому что это более высокий уровень абстракции.

J>Я тебе говорю, я давно не встречал "структурных" библиотек (математич. не в счет).
J>Да и ты сам поди давно "структурных" программ не писал..

И что из этого следует?

J>

J>Внутренняя реализация класса вполне себе структурной парадигме соответствует, никто от нее не отходил, просто конструкции языка стали более высокоуровневыми и абстрактными.

J>Ну и что?

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

J>

AVK>>Вот именно — меньшими усилиями. Однако понятность конечного результата от этого зависит слабо.

J>Почему? В чем тогда заключаются меньшие усилия?

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

J>И потом я никогда не встречал формулировки: результат разработки мало понятен, мы что-то сделали, а что будем дальше разбираться...

J>Наоборот — реализовали систему, она делает то-то и то-то. Понятными способами, сюрпризов — минимум...

Не могу уловить мысль. К чему это рассуждение?

AVK>>Ты опять подменяешь понятия. ООП тут не при чем. В том что ты подходишь к барьеру виновата не парадигма, а неверные решения при проектировании.

J>Ну вот опять... ты можешь разделить проектные решения на верные и неверные? Расскажи мне о критерии...

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

... << RSDN@Home 1.1 alpha 1 >>

Здравствуйте, AndrewVK, Вы писали:

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

— А шо таки делать?
— Читай тору...

Игорь

Здравствуйте, Joker6413, Вы писали:

J>Что же, понятно, формулировкой "плохой дизайн" можно обьяснить вообще все проблемы этого мира...

Все нельзя, но ту что ты описал вполне.

... << RSDN@Home 1.1 alpha 1 >>

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Joker6413, Вы писали:

J>>Что же, понятно, формулировкой "плохой дизайн" можно обьяснить вообще все проблемы этого мира...

AVK>Все нельзя, но ту что ты описал вполне.

А шо, ви хотели от мира который сделали меньше чем за неделю?

Игорь

Здравствуйте, Joker6413, Вы писали:

ГВ>>А может быть, не стоит обобщать без достаточных на то оснований?

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

ГВ>>И не решат никогда.

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

Только сначала эти перспективы нужно нарисовать. Т.е. — документировать. Самому.

ГВ>>Проблема не в мнимых границах понимания людей, а в стереотипах, которые довлеют над ними при выделении сущностей предметной области.
J>Очень хорошо, вы можете одновременно представлять разных 10 обьектов, которые обмениваются хотябы 10 типами сообщений, конечно с последствиями...

В таких случаях я задумываюсь — а почему так много нужно держать в голове одновременно? Может, к ним добавить ещё 5 типов объектов и разнести на 50 разных систем, которые наследованием свести, например, к пяти?

ГВ>>С моей стороны это, конечно, предположение, но я думаю, что, например, неправомерное применение агрегации понятий [...]
J>Пример агрегации: вот у меня от 5 до 10 различных источников данных... Естейственно я храню их в массиве объекта класса (в принципе вариант агрегации), что же тут неправомерного с точки зрения "правильного дизайна"?

Интересно. Если можно — поподробнее. Для чего эти источники данных?

ГВ>>Я поёрничаю немного.

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

J>O.K. дайте критерий "грамотно спроектированной" системы... Не спорю глупо спроектированные системы как правило не понятны...

Изволь (более подробно посмотри, например, у Буча):

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

Пример результата паршивого проектирования:

class DatabaseQueries
{
  EmployeeList *GetEmployeeList(Department*){...}
};

Пример результата хорошего проектирования (ИМХО):

typedef SelectionCriteria<Department> DepartmentSelection;
typedef List<Employee, DepartmentSelection> EmployeeList;
typedef Hash<Employee, Employee::Key, DepartmentSelection> EmployeeHash;
typedef Hash<EmployeeList, EmployeeList::Info::MainKey> AnotherEmlpoyeeHash;

ГВ>>[...] Попытка "удержать всю систему в голове", говорит, для меня, по крайней мере, о том, что ты столкнулся с очень бестолково спроектированной системой. [...]
J>Конечно удержать в голове всю систему — не реально, но все же хочется выяснить где та граница, за которой ситема становится непонятной...

Нет никакой ложки... Если система слишком сложна, то, ИМХО, её надо выколпачить и переколпакировать.

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

Мне кажется, здесь дело не в ООП или структурном подходе самом по себе... ООП довольно гармонично воплотило некоторый паттерн (мышления!), которым пользуются разработчики систем для повышения их "понятности" и управляемости. Где-то проскакивало, что хорошие структурные проекты проектируются примерно так же, как и ОО-системы. Кстати, я с этим согласен — если есть структура (данные) и способ увязать с ними исполняемый код, то никто не мешает реализовать объектный дизайн. С теми или иными сложностями это возможно и на Паскале и на C. Так что, дело не в том, как обозначен подход, а как он использован.

UGN>Вот так и говори. А то микроконтроллеры зачем-то приплел...
Хочешь пофлеймить? Есть более достойный объект приложения: тема Windows vs Linux: так что вперед, Макдуф, вас ждут великие дела...

Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>Мне кажется, здесь дело не в ООП или структурном подходе самом по себе... ООП довольно гармонично воплотило некоторый паттерн (мышления!), которым пользуются разработчики систем для повышения их "понятности" и управляемости. Где-то проскакивало, что хорошие структурные проекты проектируются примерно так же, как и ОО-системы. Кстати, я с этим согласен — если есть структура (данные) и способ увязать с ними исполняемый код, то никто не мешает реализовать объектный дизайн. С теми или иными сложностями это возможно и на Паскале и на C. Так что, дело не в том, как обозначен подход, а как он использован.

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

Одним словом мы ходим по кругу...

1. Есть ООП.
2. С помощью ООП "можно делать" "хороший" дизайн системы.
3. Если что-то не так, дизайн кривой — см. п.2.

Игорь

Здравствуйте, Joker6413, Вы писали:

J>что может прийти на смену ООП (в смысле обьектов обменивающихся сообщениями)?

Может ты идешь не туда? Может это давно пришло?

J>ООП на мой вгляд себя исчерпало, т.к. предел "понятной сложности" в ООП, слишком мал для текущих задач... Я имею в виду, что при разработке с использованием ООП кол-во классов, обьектов и связей растет слишком быстро. Человеку сложно удержать "образ системы". Конечно есть специальные технологии(например UML) которые позволяют отодвинуть границу понимания, но общей проблемы-то они не решают...

Откуда берется уверенность, что вот, прийдет что-то на смену ООП и все проблемы решаться? Так не бывает: "Малi дiти --- малi проблеми, великi дiти --- великi проблеми". Может быть проблемы, связанные с разработкой ПО, более принципиальны, чтобы их можно было просто так взять и решить? ООП позволяет разрабатывать ПО иерархично (в отличие, например, от процедурной линейной модели). Но что можно придумать, кроме иерархии, для упорядочения системы из миллиона объектов?

Какие проблемы возникают сегодня перед разработчиками ПО? Вот несколько из них:

1. Исходники OS Windows 2000 составляют 29 мегастрочек. Один человек не в состоянии удержать "образ" такой системы. Таким образом возникает первая из проблем разработки ПО --- обеспечить возможность работы над проектом группы людей.

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

3. Выявление и устранение ошибок.

Эти проблемы давно решаются (паттерны, u-тесты, рефакторинг, RUP, CMM, XP). Собственно говоря, имхо, можно говорить, что это слеующий шаг над ООП (причем сразу в нескольких направлениях)

__________
"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind". (с) Alan Kay

Здравствуйте, Mystic, Вы писали:

M>Эти проблемы давно решаются (паттерны, u-тесты, рефакторинг, RUP, CMM, XP). Собственно говоря, имхо, можно говорить, что это слеующий шаг над ООП (причем сразу в нескольких направлениях)

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

Игорь

Здравствуйте, Joker6413, Вы писали:

S>Основная проблема существующего ООП — это статичность объектной модели.

J>Мне не ясна суть проблемы... в чем преимущество ООП с динамической объектной моделью?

Суть проблемы в том, что современное ООП рассматривает (в большинстве случаев — есть и исключения) некоторую объектную модель как офисное здание. Т.е. вот взяли мы заказчика, допросили с пристрастием, нарисовали чертеж его нового офиса. И длина коридоров, и количество окон, и расположение коммуникаций — все идеально соответствует его требованиям.
Окей, постороили мы это чудесное здание — вьезжай, наслаждайся.
Но когда через какое-то время у заказчика меняется профиль потребностей (даже не количественно. Ну кто мог подумать 150 лет назад, что буквально в каждую комнату надо будет проводить электричество???), мы можем только пристраивать к этому зданию какие-то флигельки. Теперь уже пользоваться им не так удобно; сложность системы возрастает, и когда Петрович меняет лампочку в подвале крыла А, на чердаке крыла Б почему-то срабатывает пожарная сигнализация.
Итак, назрел переезд. Теперь мы должны спроектировать здание заново, и построить другое здание. Предыдущее оказалось недостаточно гибким.

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

J>Поддежка адекватности — проблема субъективная, система же не может выяснить, что она неверно отображает реальность... Хотя кое-что здесь сделать все таки можно.
Речь не идет о том, что эта модель должна куда-то бегать и что-то выяснять. Речь идет об инструментах, которые позволят разработчикам менять модель за
дсотаточно короткое время.
J>В принципе тут есть куда двигаться. Программы вещи формализованные (на определенном уровне), поэтому кажется реальным создания экспертных систем анализа кода, которые могли бы генерировать суждения относительно кода, его использования и т.д. Может быть на уровне этих сужедений обнаружаться "структурные шаблоны", которые позволят судить о развитии системы (на немыслимо высоком уровне абстракции), ее согласованности, возможных изменениях и т.д. (здравствуй матрица!).
Честно говоря, я не планировал заходить так далеко

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

... << RSDN@Home 1.0 beta 7a >>

	От:	Joker6413
	Дата:	23.06.03 10:20
	Оценка:

	От:	Lloyd
	Дата:	23.06.03 10:34
	Оценка:	-2

От:	Voblin	http://maslyaew.narod.ru/
Дата:	23.06.03 11:26
Оценка:

	От:	Joker6413
	Дата:	23.06.03 11:33
	Оценка:

От:	Voblin	http://maslyaew.narod.ru/
Дата:	23.06.03 12:08
Оценка:

	От:	scaramush
	Дата:	23.06.03 14:29
	Оценка:	2 (1) +1

От:	Sinclair	https://github.com/evilguest/
Дата:	23.06.03 15:25
Оценка:	29 (7)

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	24.06.03 23:29
Оценка:	2 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	25.06.03 09:28
Оценка:

От:	Mystic	http://mystic2000.newmail.ru
Дата:	26.06.03 10:44
Оценка: