Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2003.11.13;
Скачать: [xml.tar.bz2];

Вниз

---|Ветка была без названия|---   Найти похожие ветки 

 
euru   (2003-09-22 12:50) [40]

>Игорь Шевченко © (22.09.03 12:23) [39]

Это реплика или действительно интересно?

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

Так как непосредственно с Бучем я вести диалог не могу, то и обратился в этот форум.


 
Игорь Шевченко   (2003-09-22 12:54) [41]

Я тоже не Буч, разумеется, но послушать было бы интересно, так как книжку Буча считаю очень неплохой и достаточно ясно написанной :)


 
Vuk   (2003-09-22 12:59) [42]

to euru:
>Это реплика или действительно интересно?
Хоть и не ко мне обращение, но мне тоже было бы интересно. Серьёзно.

P.S. У меня, помнится, было странное ощущение после прочтения первой главы книги "ООА: моделирование мира в состояниях" (авторы Шлеер и Меллор). Это была первая книга по ООА, которую я прочитал. Там на читателя вываливалась куча терминогогии и концепций, и становилось несколько страшновато от этого потока. Потом до меня дошло, что первую главу лучше пропустить. :o) Во воторой главе начали потихоньку вводить термины и объяснять концепции и т.д. А после прочтения всей книги оказалось, что можно и первую главу нормально прочитать. :o)


 
euru   (2003-09-22 13:23) [43]

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

Можно, в принципе, последовательно, начиная с 1-й главы, высказывать свои возражения, но для начала о заголовке книги:
"Объектно-ориентированный анализ и проектирование с примерами приложений на С++"

А теперь цитата из раздела 2.2:
Дженкинс и Глазго считают, что "в большинстве своем программисты используют в работе один язык программирования и следуют одному стилю. Они программируют в парадигме, навязанной используемым ими языком. Часто они оставляют в стороне альтернативные подходы к цели, а следовательно, им трудно увидеть преимущества стиля, более соответствующего решаемой задаче"

Те есть ограничившись языком С++ (от себя: и его аналогами - напр. Delphi), он строит свой вариант объектно-ориентированного дизайна (ООД) (ООД - чтобы не путать с ООП - объектно-ориентированным программированием).

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


 
euru   (2003-09-22 13:26) [44]

>Vuk © (22.09.03 12:59) [42] и всем-всем-всем
Обращение ко всем, кто хочет разобраться в этом самом ООД


 
Игорь Шевченко   (2003-09-22 13:59) [45]

euru © (22.09.03 13:23)

Дженкинс и Глазго довольно правильно считают :)

А программист строит свой вариант не в зависимости от средств, предоставляемых языком, чаще всего, так как и C++ и Object pascal довольно развитые языки, чтобы предоставить массу средств, а в силу своей собственной ограниченности в понимании ООП и ООД :))


 
Vuk   (2003-09-22 14:00) [46]

to euru:
Главное - это не язык реализации, а реализованная концепция. Кстати, не помню, чтобы в книге были какие-то примеры, реализация которых на сзыке, отличном от C++ была бы невозможна. Вообще говоря, в первом издании книги Буча концепции рассматривались отдельно, а примеры были даны отдельно и для разных языков программирования...


 
euru   (2003-09-22 14:41) [47]

>Игорь Шевченко © (22.09.03 13:59) [45]
Так ведь в общем случае программист и проектировщик (дизайнер) - это разные люди. Программист создает по модели, разработанной дизайнером, программный код, и его "собственная ограниченность" ограничивается пониманием возможностей этого языка. На модель это никак не сказывается.
А вот если дизайнер при разработке архитектуры модели будет учитывать ЯП, на котором это будет реализовано, может существенно ограничить возможности самой модели. Пример: если дизайнер выберет Delphi, то ему нужно учитывать простое наследование, если C++, то можно и множественное наследование.

Vuk © (22.09.03 14:00) [46]
1. Допустим, в ней не рассматривались модели, которые невозможно реализовать на С++ :)
2. Хоть концепции и рассматриваются отдельно, но их примеры (не путать с примерами, реализованными по этим концепциям) делаются с учетом возможностей С++.


 
Игорь Шевченко   (2003-09-22 14:50) [48]

euru © (22.09.03 14:41)


> Так ведь в общем случае программист и проектировщик (дизайнер)
> - это разные люди. Программист создает по модели, разработанной
> дизайнером, программный код


Нда ? Значит, мы о разном...


 
Некрофил-затейник__   (2003-09-22 14:57) [49]

euru
А вы не пробывали резко перейти с Delphi на VC и обратно?
Путешествие хоббита туда обратно отдыхает.
Вас не смущает фраза мыслить на русском языке или мыслить на английском языке?
Язык точнее его возможности навязывают свой стиль это точно просто у Буча пример про искимосов не много не в тему в другой книге(не помню название) про тоже самое говорится менее образно в том смысле что если язык предлагает простые средства организации множественного наследия то множественным насдедованием пользуются.
Пример в VC можно просто организовать наследование хоть от 20 класссов в Delphi наследование через Interface и Dispinterface усложнено много вы делали программ с множественным наследованием на Delphi?


 
euru   (2003-09-22 18:08) [50]

>Игорь Шевченко © (22.09.03 14:50) [48]
>Некрофил-затейник__ © (22.09.03 14:57) [49]

Так ведь я сразу говорил о проектировании (см. subj)
Буч тоже говорит о проектировании (если верить названию книги).

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


 
euru   (2003-09-22 20:29) [51]

up


 
Vuk   (2003-09-22 20:30) [52]

А в чем тогда проблема - то? ;o)


 
euru   (2003-09-22 22:43) [53]

>Vuk © (22.09.03 20:30) [52]
А я разве говорил о проблемах? Мне просто хотелось обсудить, кто и как проектирует. Неужели все сразу программы пишут? Совсем не проектируют? Прямо как казахские акыны: что вижу, о том и пою.


 
Vuk   (2003-09-23 01:42) [54]

to euru:
>Неужели все сразу программы пишут?
Ну... Не то, чтобы совсем сразу, но в текущем проекте этапа проетирования практически не было (см. [14]). Просто периодически определяются направления дальнейшего развития, некоторые детали реализации, анализируются требования данного этапа. Иногда требования довольно-таки расплывчатые... Так что иной раз приходится акынствовать помаленьку, хотя и очень не хочется. :o(


 
[NIKEL]   (2003-09-23 06:26) [55]

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

Как кто пишет(почему так?), поделимся опытом.


 
Viktor Kushnir   (2003-09-23 07:50) [56]

По моему большая часть проектирования происходит в уме. У меня, например, когда еду в транспорте и делать нечего. Программа в это время продумываюется, ищутся слабые места. Конечно так нельзя продумать все максимально детализованно, но этого и не требуется.


 
euru   (2003-09-23 18:22) [57]

>[NIKEL] © (23.09.03 06:26) [55]
А чем интереснее проектирование определенной информационной системы от проектирования вообще? Не зная проектирование, как таковое, невозможно успешно спроектировать какю-либо систему. Это как чтение. Не умея читать вообще, невозможно будет прочесть конкретную книгу.

Viktor Kushnir © (23.09.03 07:50) [56]
Это не проектирование. Это составление и оптимизация кода уже спроектированной задачи. Причем если спроектировано хреново, то как ни оптимизируй, алгоритм тоже будет хреновый.


 
[NIKEL]   (2003-09-24 08:36) [58]

>[NIKEL] © (23.09.03 06:26) [55]
А чем интереснее проектирование определенной информационной системы от проектирования вообще? Не зная проектирование, как таковое, невозможно успешно спроектировать какю-либо систему. Это как чтение. Не умея читать вообще, невозможно будет прочесть конкретную книгу.


А чем интереснее летать на самолете от чтения книг, о том как летать на самолете...

Чем ближе к практике\реалиям жизни, тем интереснее, поверь.


 
euru   (2003-09-24 09:15) [59]

>[NIKEL] © (24.09.03 08:36) [58]
Это смотря как летать. Если в качестве пассажира, то можно и не читать. Тогда, действительно, гораздо интереснее летать. А вот если в качестве пилота, то все-таки, наверно, желательно изучить теорию полетов и принципы управления самолетом. И если есть чувство самосохранения, лучше все-таки это делать не в реальных условиях.


 
Некрофил-затейник__   (2003-09-24 10:38) [60]

[NIKEL]

почитай Гради Буча


 
euru   (2003-09-24 14:18) [61]

>Некрофил-затейник__ © (24.09.03 10:38) [60]
Ну, осознает он свою ошибку, прочтет Буча. А дальше что? Молиться что ли на это произведение? И по каждому поводу ссылаться на него, как на святое писание?
Уже ведь 10 лет прошло с момента написания этой книги.


 
euru   (2003-09-24 15:47) [62]

up


 
euru   (2003-09-25 09:47) [63]

А есть какой-нибудь форум, где обсуждается сабж?


 
Некрофил-затейник__   (2003-09-25 09:51) [64]

euru
Это только начало.
"А дорога идет дальше и дальше"
Толкиен.


 
Некрофил-затейник__   (2003-09-25 10:49) [65]

up

ЗЫ
чтоб ветку достовать потом с 15 позиции не пришлось да может еще кто решит высказать свои сооброжения по поводу subj.


 
euru   (2003-09-25 11:06) [66]

>Некрофил-затейник__ © (25.09.03 10:49) [65]

:)
спасибо за помощь
:)


 
Mike B.   (2003-09-25 11:08) [67]

euru ©
На RSDN есть форум проектирование. Вот, например, интересные обсуждения:
http://www.rsdn.ru/Forum/Message.aspx?mid=304302
http://www.rsdn.ru/Forum/Message.aspx?mid=262074


 
[NIKEL]   (2003-09-25 12:43) [68]


euru © (24.09.03 09:15) [59]
>[NIKEL] © (24.09.03 08:36) [58]
Это смотря как летать. Если в качестве пассажира, то можно и не читать. Тогда, действительно, гораздо интереснее летать. А вот если в качестве пилота, то все-таки, наверно, желательно изучить теорию полетов и принципы управления самолетом. И если есть чувство самосохранения, лучше все-таки это делать не в реальных условиях.
Некрофил-затейник__ © (24.09.03 10:38) [60]
[NIKEL]

почитай Гради Буча

понятно что надо знать теорию... ты меня просто не понял.
я то думал что теорию Вы уже узнали\читали...

на данный момент, для меня интереснее практические навыки и конкретные примеры


 
[NIKEL]   (2003-09-25 12:44) [69]

кстати на SQL.ru есть хорошие форумы, проектирование и т.д.


 
Некрофил-затейник__   (2003-09-25 13:05) [70]

[NIKEL]
Тогда есть книжка в том числе и в инете в свободном скачивании
"Смертельный марш" есть смысл почитать там как раз про практику и теорию и как они согласуются между собой


 
Некрофил-затейник__   (2003-09-25 13:20) [71]

Mike B.
там про развитие причем одной отдельно парадигмы ООП
хотя тоже интересно...


 
euru   (2003-09-25 13:59) [72]

>[NIKEL] © (25.09.03 12:43) [68]
Ну так это не по сабжу. Можно завести отдельную ветку.

>Mike B. © (25.09.03 11:08) [67]
С отрывом на работу и перерывом на обед прочел. Довольно-таки интересные обсуждения. Правда, по большей части они посвящены методам программирования, и до уровня пректирования они так и не поднялись (опустились).


 
euru   (2003-09-25 16:18) [73]

А знаете, почему Буч выбрал объектно-ориентированный метод проектирования? Потому что:
Во-первых, объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.
Дальше идут еще три небесспорных причины.
Наконец, объектная модель ориентирована на человеческое восприятие мира...

Т.е. основная причина - потом проще будет писать на ООП (в частности, на С++).


 
euru   (2003-09-25 16:20) [74]

А знаете, почему Буч выбрал объектно-ориентированный метод проектирования? Потому что:
Во-первых, объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.
Дальше идут еще три небесспорных причины.
Наконец, объектная модель ориентирована на человеческое восприятие мира...

Т.е. основная причина - потом проще будет писать на ОО-языке (в частности, на С++).


 
Некрофил-затейник__   (2003-09-26 06:25) [75]

euru

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


 
Некрофил-затейник__   (2003-09-26 06:34) [76]

2 All

Программистский камень

\/

http://progstone.narod.ru/

что вы думаете об этом?


 
Некрофил-затейник__   (2003-09-26 11:46) [77]

2 All

Программистский камень

\/

http://progstone.narod.ru/

что вы думаете об этом?


 
Игорь Шевченко   (2003-09-26 14:06) [78]

Некрофил-затейник__ © (26.09.03 11:46)

Хорошая книга :))
Пример с Рихтером понравился, еще полтора года назад


 
euru   (2003-09-26 23:25) [79]

>Некрофил-затейник__ © (26.09.03 11:46) [77]
Вот что Буч пишет про структурный анализ:
Если же по каким-либо уважительным причинам приходится взять за основу структурный анализ, прекратите строить диаграммы, как только они начинают смахивать на проект программы, а не на модель предметной области. Помните, что материалы проектирования, такие, как диаграммы потоков данных, это не конечный продукт, а инструмент разработчиков. Обычно строятся диаграммы, а затем разрабатываются механизмы, обеспечивающие необходимое поведение системы, то есть сам акт проектирования видоизменяет начальную модель.
Т.е. сначала он говорит: 1) Используйте ОО-анализ и ОО-проектирование, потому что потом будет легче писать на ОО-языке. Тем самым делается ограничение на возможные варианты анализа и проектирования. Однако если считать, что структурный анализ - это одна из разновидностей анализа, то к ОО-анализу тоже можно применить вышеприведенное правило. Т.е. 2) не стоит строить иерархию классов и взаимодействие между ними, если "они начинают смахивать на проект программы, а не на модель предметной области". Но согласно 1) мы уже выбрали, как мы будем анализировать предметную область, и поэтому, как бы мы ни старались, она будет "смахивать на проект программы".

Бегло просмотрел ссылку. Довольно-таки интересно. Только мне кажется, там больше об эффективной организации труда программиста (может, я что-то упустил?).

>Игорь Шевченко © (26.09.03 14:06) [78]
Да, пример хорош. Я бы, правда, остановился на предпоследнем варианте - тогда бы не понадобилось объяснять, почему Index проверяется дважды.


 
euru   (2003-09-29 09:04) [80]

up



Страницы: 1 2 3 4 вся ветка

Форум: "Потрепаться";
Текущий архив: 2003.11.13;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.63 MB
Время: 0.04 c
1-41575
kaif
2003-10-26 02:18
2003.11.13
ToolBar и смена шрифта экрана.


1-41478
konstantinov
2003-10-28 18:36
2003.11.13
Тормоза при Runtime создание компонентов


4-42256
Немного не по теме
2003-09-17 23:49
2003.11.13
Немного не по теме


1-41564
Adoon
2003-10-27 16:39
2003.11.13
написание своего Help а


7-42152
G-ray
2003-09-02 15:13
2003.11.13
Блокировка запеска *.exe файлов..





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский