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

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

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

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

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

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

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

M>И получается рефакторинг чистой воды.
Именно! Наконец-то я выразился более-менее понятно.
M>Единственная проблема — средства рефакторинга только начинают созревать и пока они дорастут до рефакторинга архитектуры приложения пройдет некоторое время.
Ага. Вот и я о том же. Вот они то и придут в дополнение к ООП.