Здравствуйте, Sinclair, Вы писали:
S>Основная проблема существующего ООП — это статичность объектной модели.
Очень правильно!
S>Динамический подход (ака рефакторинг) расширяет эту технику, предоставляя нам удобную возможность изменить модель на произвольно взятом уровне. Например, разделить монолитный класс на два — предка и наследника, чтобы дать возможность отнаследоваться "повыше" в дереве. Или объявить часть класса интерфейсом, вынести его наружу... Все это с сохранением корректности уже написанного кода, т.е. если уж мы вынесли что-то в интерфейс, то тот код, который раньше пользовался ссылкой на наш класс, должен (если подмножество использованных методов соответствует) теперь брать ссылку на интерфейс. И т.п.
А можно поподробнее? Как можно "изменить модель на произвольно взятом уровне" с "с сохранением корректности уже написанного кода"? IMHO в общем случае это невозможно, так как обычно отсутствует возможность оперативно и с минимальными затратами сил корректировать уже написанный код. Речь идет о незначительных изменениях модели или о продвинутых технологиях создания кода? Поясните, что имелось ввиду, плиз. Интересует чисто техническая сторона дела.
Здравствуйте, scaramush, Вы писали:
S>[...] чем выше уровень абстракции, тем уже область применения.
Либо я Вас не понял, либо это не так. Поясните, пожалуйста.
На мой взгляд, чем выше уровень абстракции, тем область потенциального применения шире. Просто для конкретного применения абстрактные сущности должны быть конкретизированы.
Здравствуйте, heathcliff, Вы писали:
H>А можно поподробнее? Как можно "изменить модель на произвольно взятом уровне" с "с сохранением корректности уже написанного кода"? IMHO в общем случае это невозможно, так как обычно отсутствует возможность оперативно и с минимальными затратами сил корректировать уже написанный код. Речь идет о незначительных изменениях модели или о продвинутых технологиях создания кода? Поясните, что имелось ввиду, плиз. Интересует чисто техническая сторона дела.
Имеются в виду "продвинутые технологии создания кода". Некоторые из них уже реализованы; о некоторых надо мечтать. Основные существующие инструменты не предоставляют достаточного сервиса. Например, большинство кодогенераторов из UML ограничиваются генерацией деклараций. Это означает, что такое действие, как разделение класса на пару наследник/потомок приведет к необходимости править собственно код руками. Интеллектуальный инструмент нашел бы все вхождения используемого класса и изменил бы код соответствующим образом. У меня не хватает эрудиции обсуждать конкретные свойства конкретных инструментов для рефакторинга, но необходимость в определенной функциональности я вижу.
Ключевая идея в том, что мы имеем в момент 1 некоторую модель, которая является корректной. Т.е. она адекватно отражает наши представления о предметной области. При этом модель уже обросда "мясом", вплоть до наличия корректно функционирующего приложения. В момент 2 мы обнаруживаем несовершенство наших представлений и корректируем их. В рамках существующей модели внесение изменений ведет к значительному усложнению (т.е. увеличению числа взаимодействий между элементами модели). Поэтому перед расширением модели возникает желание изменить модель так, чтобы в момент 2 мы имели не менее корректную модель, отражающую наши предыдущие представления. (очевидно, что таких корректных моделей — бесконечное количество). При этом никаких потерь не должно происходить — если мы имели работающее приложение в момент 1, то мы должны все еще его иметь.
Эта новая модель должна отличаться от предыдущей ровно одним свойством — расширение ее для соответствия новым представлениям не должно увеличивать локальную сложность так значительно.
... << RSDN@Home 1.0 beta 7a >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
...
Интересная тема. То-же не выдержал решил подключиться. Хотя мое мнение возможно и парадоксально. Как-то пришлось программировать в двоичных кодах (скажем так — заставили). Испытал настоящий шок. Во первых было открытием, что ASM команда, ну никак не транслируется в один машинный код, во вторых оказалось, для того, чтобы вчесть РОН из РОНа совсем не обязательно переводить число в доп.код а затем складывать, в третьих ... список можно продолжать и продолжать.
К чему это я, а к тому, что с возростанием уровня абстракции избыточность, неоптимальность, объем и т.д. кода растет в геометрической прогрессии.
Когда появились персоналки, стоял крик, что это истина в последней инстанции, народ быстро повыбрасывал EC (IBM360). Сейчас вовсю используются терминальные версии, сервера приложений, в Нью Йорке, Мэр пробивает идею супер фрейма для города (а по домам и офисам, типа вообще системные блоки не нужны). Как Вам это, ничего не напоминает.
Идем дальше, использавание интеллектуальных датчиков, контроллеров и т.д. IMHO с такой периферией остается только интерфейс.
Идем дальше, компы Be (ветка от MAC), единственная разработка, которой в штатах, за всю историю, при презентации рукоплескали стоя. Да, они как-то втихаря загнулись (денег не хватило или задавили). Но ведь писюк в сегодняшнем виде себя исчерпал.
........
IMHO, должен быть качественный скачок (Be — было попыткой). Для этого правда надо пристрелить дядю Билли (жадный был наш дядя Билли, дети дядю не любили). Вполне возможно, этот скачок уже происходит. Что мы например знаем о технологиях и ПО той-же IBM. Те-же СУБД IBM держат 39% амер.рынка и никакого отношения к InterBase или Oracle (17%) не имеют.
........
А если предположить, что качественный скачок будет (IMHO все предидущее развитие, со времени первых PC — все-таки колличественное), то вполне возможно ООП и идеями ООП там пахнуть и не будет . В конце концов — переход линейное-структурное-ООП это на глобальном уровне, всего-лишь возможность создавать ПО все большими и большими толпами разработчиков, говорить о том, что это оптимальное или если хотите красивое (ну не технический термин — знаю) не приходится.
........
Кто такой ЩАС программер, ну кто угодно, но не творец, чуть, что — иди читай MSDN, НУ ЧТО ЗА БРЕД, ГОСПОДИ. Это, ЧТО истина в последней инстанции, изучать тупые куски написанные левой ногой, чтоб подтвердить, что винда бозя всех бозь в последней инстанции.
Здравствуйте, 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) которые позволяют отодвинуть границу понимания, но общей проблемы-то они не решают...
И не решат никогда. Кстати, UML не помощник в борьбе о сложностью, вернее — не более помощник, чем несколько классов, набросанных на листе бумаги. Вот в каком качестве UML относительно хорош — так это как распространённый способ документирования системы, уже сложившейся в голове разработчика.
J>Есть теория что люди не могут выйти за границы понимания мира как "собрание взаимодействующих обьектов". Это похоже на то как двухмерные создания, не могут постичь создания трехмерные...
Проблема не в мнимых границах понимания людей, а в стереотипах, которые довлеют над ними при выделении сущностей предметной области.
С моей стороны это, конечно, предположение, но я думаю, что, например, неправомерное применение агрегации понятий будет при любой базовой парадигме усложнять систему (систему! — т.е., набор взаимосвязанных сущностей) и как следствие — утяжелять взаимодействие с ней. Но эта проблема вызвана неадекватной организацией мышления конкретного проектировщика, а не применённой им парадигмы.
J>Какие будут мнения? Обсуждаемая проблема — "предел понятной сложности в ООП"...
Я поёрничаю немного. Мне не приходилось пока встречать "непостижимых" и при этом грамотно спроектированных объектных систем (на самом деле это оксюморон, поскольку грамотность объектного проектирования как раз и определяется понятностью созданной системы), а вот непостижимую человеческую глупость в применении ООП встречал неоднократно. И здесь соглашусь, может показаться, что ООП даёт сбой. Но дело-то в том, что само по себе применение ООП в этом случае неадекватно!
PS. Камень в твой огород, но не наезда ради, а чтобы указать на ошибку в твоей посылке. Попытка "удержать всю систему в голове", говорит, для меня, по крайней мере, о том, что ты столкнулся с очень бестолково спроектированной системой. Но я не думаю, что ты пытаешься сделать её сам.
PPS. Нет никакой ложки, всё дело — в тебе. (c) "Матрица"
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Joker6413, Вы писали:
ГВ>А может быть, не стоит обобщать без достаточных на то оснований? А их пока не приведено. Обоснуй, плиз. Кстати учти, что даже сотня проектов, отмеченных твоим личным участием не могут быть основанием для обвинения парадигмы самой по себе.
Конечно личный опыт...
ГВ>И не решат никогда. Кстати, UML не помощник в борьбе о сложностью, вернее — не более помощник, чем несколько классов, набросанных на листе бумаги. Вот в каком качестве UML относительно хорош — так это как распространённый способ документирования системы, уже сложившейся в голове разработчика.
Ну почему же... взгляд на систему с разных перспектив очень здорово помогает понять что в системе происходит...
ГВ>Проблема не в мнимых границах понимания людей, а в стереотипах, которые довлеют над ними при выделении сущностей предметной области.
Очень хорошо, вы можете одновременно представлять разных 10 обьектов, которые обмениваются хотябы 10 типами сообщений, конечно с последствиями...
ГВ>С моей стороны это, конечно, предположение, но я думаю, что, например, неправомерное применение агрегации понятий будет при любой базовой парадигме усложнять систему (систему! — т.е., набор взаимосвязанных сущностей) и как следствие — утяжелять взаимодействие с ней. Но эта проблема вызвана неадекватной организацией мышления конкретного проектировщика, а не применённой им парадигмы.
Пример агрегации: вот у меня от 5 до 10 различных источников данных... Естейственно я храню их в массиве объекта класса (в принципе вариант агрегации), что же тут неправомерного с точки зрения "правильного дизайна"?
ГВ>Я поёрничаю немного. Мне не приходилось пока встречать "непостижимых" и при этом грамотно спроектированных объектных систем (на самом деле это оксюморон, поскольку грамотность объектного проектирования как раз и определяется понятностью созданной системы), а вот непостижимую человеческую глупость в применении ООП встречал неоднократно. И здесь соглашусь, может показаться, что ООП даёт сбой. Но дело-то в том, что само по себе применение ООП в этом случае неадекватно!
O.K. дайте критерий "грамотно спроектированной" системы... Не спорю глупо спроектированные системы как правило не понятны...
ГВ>PS. Камень в твой огород, но не наезда ради, а чтобы указать на ошибку в твоей посылке. Попытка "удержать всю систему в голове", говорит, для меня, по крайней мере, о том, что ты столкнулся с очень бестолково спроектированной системой. Но я не думаю, что ты пытаешься сделать её сам.
Конечно удержать в голове всю систему — не реально, но все же хочется выяснить где та граница, за которой ситема становится непонятной...
Системы разработанные с помощью структурного подхода были сложными для понимания... ООП реально подвинуло границу понимания сложных систем... но достаточно ли для сегодняшнего дня? а для завтрашнего?
Здравствуйте, scaramush, Вы писали:
S>не имеет смысл рисовать блок схему (или использовать UML) для программы Hello, World.
Вот так и говори. А то микроконтроллеры зачем-то приплел...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Vlad232ua, Вы писали:
V>> К чему это я, а к тому, что с возростанием уровня абстракции избыточность, неоптимальность, объем и т.д. кода растет в геометрической прогрессии. S>Хм. Очень интересное мнение. А вот академик Ершов, например, считал путем к оптимальности т.н. смешанные вычисления. Все пересказывать не буду, ...
...
Как говориться "я сам брат из этих, но в песне ты не понял, увы ничего"
Здравствуйте, Joker6413, Вы писали:
J>Системы разработанные с помощью структурного подхода были сложными для понимания... ООП реально подвинуло границу понимания сложных систем... но достаточно ли для сегодняшнего дня? а для завтрашнего?
Все таки по моему ты путаешь ООП с чем то другим. На внятность и управляемость влияет не столько используемая технология, сколько дизайн. Существует масса примеров огромных проектов, написанных с использованием структурного программирования и вполне внятных при этом. Существует же такая же масса крошечных ОО-проектов, которые абсолютно невразумительны. ООП всего лишь помогает создавать грамотный дизайн больших систем без дополнительных телодвижений. Как правильно сказал Синклер — ООП это по сути несколько паттернов, встроенных в язык.
Что же касается конкретно твоей проблемы — слишком большого количества сущностей, то она решается стандартными и давно известными подходами — введением иерархии сущностей, введением дополнительных абстрактных слоев. Ограничение подобным приемам только одно — перфоманс.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Joker6413, Вы писали:
J>>Системы разработанные с помощью структурного подхода были сложными для понимания... ООП реально подвинуло границу понимания сложных систем... но достаточно ли для сегодняшнего дня? а для завтрашнего?
AVK>Все таки по моему ты путаешь ООП с чем то другим. На внятность и управляемость влияет не столько используемая технология, сколько дизайн. Существует масса примеров огромных проектов, написанных с использованием структурного программирования и вполне внятных при этом. Существует же такая же масса крошечных ОО-проектов, которые абсолютно невразумительны. ООП всего лишь помогает создавать грамотный дизайн больших систем без дополнительных телодвижений. Как правильно сказал Синклер — ООП это по сути несколько паттернов, встроенных в язык.
Да я конечно не спорю что существуют понятные ОО-проекты, так же как и не понятные ОО-проекты, так же как и огромные системы созданные с помощью структурных методов...
Но от "структурных методов" отошли, почему? Их прокляли магией вууду? Нет, ОО-методы позволяют реализовывать системы "с такой же сложностью" гораздо меньшими усилиями + доп. бонусы ООП... Вот в чем суть, назови меня лентяем, но я все время хочу получать уменьшение усилий на выполнение проекта, а в ООП переодически подхожу к барьеру у которого "увеличение полезности системы" на копейку стоит рубль (налицо необходимость рефакторинга, т.е. практически создания новой системы... значит я у границы ООП пускай даже своей собственной).
Здравствуйте, Joker6413, Вы писали:
J>Да я конечно не спорю что существуют понятные ОО-проекты, так же как и не понятные ОО-проекты, так же как и огромные системы созданные с помощью структурных методов...
Опять ты меня не понял. Я пытался сказать что используемая парадигма программирования прямого отношения к управляемости проекта не имеет.
J>Но от "структурных методов" отошли, почему?
Кто тебе сказал? Внутренняя реализация класса вполне себе структурной парадигме соответствует, никто от нее не отходил, просто конструкции языка стали более высокоуровневыми и абстрактными.
J> Их прокляли магией вууду? Нет, ОО-методы позволяют реализовывать системы "с такой же сложностью" гораздо меньшими усилиями
Вот именно — меньшими усилиями. Однако понятность конечного результата от этого зависит слабо.
J> + доп. бонусы ООП... Вот в чем суть, назови меня лентяем, но я все время хочу получать уменьшение усилий на выполнение проекта, а в ООП переодически подхожу к барьеру у которого "увеличение полезности системы" на копейку стоит рубль (налицо необходимость рефакторинга, т.е. практически создания новой системы... значит я у границы ООП пускай даже своей собственной).
Ты опять подменяешь понятия. ООП тут не при чем. В том что ты подходишь к барьеру виновата не парадигма, а неверные решения при проектировании.
Здравствуйте, 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>Ну и что?
А то что структурную парадигму никто не отменял. ООП это средства более высокоуровневые, они не заменяют структурное программирование, они его дополняют.
J> AVK>>Вот именно — меньшими усилиями. Однако понятность конечного результата от этого зависит слабо. J>
J>Почему? В чем тогда заключаются меньшие усилия?
В том что в ОО-языках к примеру уже реализован паттерн "наследование" и "инкапсуляция".
J>И потом я никогда не встречал формулировки: результат разработки мало понятен, мы что-то сделали, а что будем дальше разбираться...
J>Наоборот — реализовали систему, она делает то-то и то-то. Понятными способами, сюрпризов — минимум...
Не могу уловить мысль. К чему это рассуждение?
AVK>>Ты опять подменяешь понятия. ООП тут не при чем. В том что ты подходишь к барьеру виновата не парадигма, а неверные решения при проектировании.
J>Ну вот опять... ты можешь разделить проектные решения на верные и неверные? Расскажи мне о критерии...
Их много. Один из них тот самый о котором ты так беспокоишься — понятность и управляемость кода.
А их пока не приведено. Обоснуй, плиз. Кстати учти, что даже сотня проектов, отмеченных твоим личным участием не могут быть основанием для обвинения парадигмы самой по себе.
