Re[2]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 22:43
Оценка: 1 (1) +3
Здравствуйте, Геннадий Васильев,

Оставляю Ваши насмешки и оскорбления в стороне. Отвечаю по существу.

КЛ>>К сожалению, очень много программистов знают только один способ борьбы со сложностью — полиморфизм. И применяют его как к месту, так и не к месту. Но есть и другие способы группировки, есть критерии для объединения сущностей в группу, есть и типичные ошибки группирования.


ГВ>500 лет назад был обнародован принцип подстановки Лисковой. Фундаментальная вещь, надо сказать. Им обоснуются чуть ли не все паттерны.


Да, вещь. Да, фундаментальная. И что? К чему Вы привели это название? Какую связь оно имеет с приведенной цитатой?

ГВ>вообще нужно отлучать от кнопок и посылать в библиотеку. Однородность — суть принадлежность к одному роду (некоему множеству, определяемому сходностью характеристик), а не контексту. У меня на столе валяются курительная трубка и мобила. Однородные сущности? Да, но по критерию владельца. Это ещё не тип, поскольку трубка на столе моего соседа по лестничной клетке это тоже объект типа "трубка", но принадлежит

ГВ>она другому.

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


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

ГВ>Значит, сначала мы характеризуем "однородность" как "принадлежность одному контексту", а потом характеризуем примеры как однородные по наличию у них существенной черты. Все поняли, в чём прикол? Кто не понял — курить мобилы до полного просветдения.


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

P.S.: Мне кажется, что избранный Вами тон уместно использовать в предвыборных роликах кандидатов, но никак не на профессиональном форуме. Даже если коллеги допустили ошибку, на профессиональном форуме уместно вежливо поправлять их. Желательно, с указанием точных ссылок и источников, если вопрос касается терминов или приоритетов.

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

Соответственно, дальнейшее обсуждение мне интересно, если оно будет носить профессиональный характер.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[3]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 16.03.06 02:13
Оценка: 4 (1) +1
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>>>К сожалению, очень много программистов знают только один способ борьбы со сложностью — полиморфизм. И применяют его как к месту, так и не к месту. Но есть и другие способы группировки, есть критерии для объединения сущностей в группу, есть и типичные ошибки группирования.

ГВ>>500 лет назад был обнародован принцип подстановки Лисковой. Фундаментальная вещь, надо сказать. Им обоснуются чуть ли не все паттерны.
КЛ>Да, вещь. Да, фундаментальная. И что? К чему Вы привели это название? Какую связь оно имеет с приведенной цитатой?

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

Всё очень просто: если у нас есть какой-нибудь if (тип=тег_типа), то считай, что уже приехали, можно идти и выкусывать ошибки проектирования.

ГВ>>вообще нужно отлучать от кнопок и посылать в библиотеку. Однородность — суть принадлежность к одному роду (некоему множеству, определяемому сходностью характеристик), а не контексту. У меня на столе валяются курительная трубка и мобила. Однородные сущности? Да, но по критерию владельца. Это ещё не тип, поскольку трубка на столе моего соседа по лестничной клетке это тоже объект типа "трубка", но принадлежит

ГВ>>она другому.

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


КЛ>[...] Похожесть или непохожесть вещей задает контекст.


Можно, я не буду додумывать, кто кого тут задаёт? Переформулируйте тезис.

КЛ>По умолчанию Вы используете в качестве контекста функциональное назначение вещей. Поэтому и курительная трубка, и мобильный телефон суть разнородные вещи, т.к. выполняют разные функции.


Э... сначала переформулируйте тезис.

КЛ>Однако в завещании или в описи имущества конкретного человека эти вещи однородны, т.к. их функциональное различие в данном контексте не важно, а важно то, что они принадлежат одному владельцу.


Так... настала пора задать ещё один вопрос: что же такое "контекст"? Догадываться сам не буду. Вы — автор, вот сами и рассказывайте. Чем короче определение, тем лучше. И не надо определять его через иллюстрации.

ГВ>>Значит, сначала мы характеризуем "однородность" как "принадлежность одному контексту", а потом характеризуем примеры как однородные по наличию у них существенной черты. Все поняли, в чём прикол? Кто не понял — курить мобилы до полного просветдения.


КЛ>Про черту — это Ваше замечание, не наше. Мы классифицируем примеры, как порожденные одной и той же ошибкой — подсистемным мышлением.


Именно по наличию существенной черты (следа влияния ПМП) вы их и классифицируете.

КЛ>И в данном случае причина ошибки и выступает в роли контекста для примеров. Именно поэтому далеко не все примеры про иерархии.


Повторюсь: дайте определение понятия "контекст". Дальше поглядим, что получится.

КЛ>P.S.: Мне кажется, что избранный Вами тон уместно использовать в предвыборных роликах кандидатов, но никак не на профессиональном форуме. Даже если коллеги допустили ошибку, на профессиональном форуме уместно вежливо поправлять их. Желательно, с указанием точных ссылок и источников, если вопрос касается терминов или приоритетов.


Вежливо поправлять ошибки, построенные на слабо определённых терминах весьма утомительно — нужно написать статью объёмом поболе исходной. И состоять она будет в основном из домыслов. Другого не получится, поскольку недоопределяя терминологию вы требуете от читателя именно домысливать сказанное. Поверьте, уж намного проще было бы просто объявить показанное вами банальной демагогией и словоблудием. Посему, если уж рискнули разрекламировать статью с весьма неоднозначным содержанием — будьте готовы к заслуженному остракизму.

КЛ>На мой взгляд, существует четкий критерий профессионализма. Это манера поведения человека во время обсуждения сложных проблем, задач, вопросов...


Нечёткий это критерий и проблема простая — отсутствие точного определения термина "контекст". Дайте его, дальше будет проще.

КЛ>Если человек беседует уважительно, тщательно аргументирует свои выводы, приводит корректные ссылки, то человек является профессионалом. Если человек занимается "шапкозакидательством", насмехается над собеседником, унижает его, обвиняет, не аргументируя свои обвинения, то такой человек вряд ли профессионал.


А что нужно аргументировать? Что автор должен следить за употребляемыми терминами? Это, в общем-то, не нуждается в дополнительной аргументации.

P.S.: А вот чего нельзя делать, так это пытаться переходить на личности собеседников. Насколько я помню, я никак не пытался определять "уровень профессионализма" автора статьи.

P.P.S.: Полезный источник: Гатэг, Лисков
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: О правильных и неправильных классификациях...
От: Краснокутский Василий Россия  
Дата: 16.03.06 08:21
Оценка:
Здравствуйте, Кирилл Лебедев,
На ваше сообщение уже ответил Cyberax и сделал это хорошо. От себя добавить могу следующее:
1. Не вижу критериев по которым код оценивает как хороший или плохой. Введите четкие критерии которые можно оценить количественно и продолжим разговор. Если опираетесь на общепринятые критерии, то опишите на какие именно и как Вы их оцениваете. Со своей стороны могу порекомендовать следующие критерии с точки зрения программиста: хрупкость, монолитность, переиспользуемость, расширяемость. С точки зрения пользователя: удобство интерфейса (да да, оно оценивается и достаточно много методик это сделать количественно), скорость работы, функциональное наполнение. Без критериев оценки все ваши утверждения пустой звук. Это как про задачу построить дом. Вы старательно строите дом по всей правде технологий, а вам говорят что он предназначен для семейства жирафов которые любят купаться в болоте...
2. Разбиение на системы зависит во первых от задачи, а во вторых от направления дальнейшего развития выявленного эвристическим путем основываясь на опыте и знании предметной области. Очень интересно ваше утверждение, что Вы мыслите основываясь на общем, а не на частном и при этом действуете в отрыве от тех самых требований которые будут предъявляться к решению Вашей задачи. Кстати, не видел общих диаграмм системы, а только кодинг. Кодинг вещь интересная, все же в процессе разработки она занимает около 20% всего времени. Где разбор прецендентов, анализ требований, модель системы ? Ничего этого я не видел. Статья по сложному вопросу спускает все на уровень кодинга... Если как Вы утверждаете правильно поставленная задача есть половина решения, то при чем здесь кодинг ? У нас что, решением задачи является код или все же продукт ?? Это разные вещи, Вам не кажется ?
3. Статья очень тяжело читается, потому что, во первых много ошибок в коде, а во вторых непонятно где выводы. Т.е. я то понимаю что Вы этим хотите сказать, но все же изложение в таком ключе это плохое изложение. Читайте классиков, вот там изложение такое, что можно вообще не знать языка примеров, но при этом все понять. У Вас же, извините, дебри кода.
4. Утверждение о предсказуемости систем это сильно... Даже спорить не буду с этим утверждением — оно оторвано от реальности.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.03.06 08:26
Оценка: +2 :)
Здравствуйте, Cyberax, Вы писали:

C>В морг ТРИЗ. Для программирования он неприменим — слишком велика

C>гибкость програмных систем.

не понял связи. Или ты тоже сторонник мнения, что в программировании главное автокомплит, чтобы кода побольше наколотить?
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 16.03.06 09:26
Оценка: 1 (1)
Andrei N.Sobchuck wrote:
> C>В морг ТРИЗ. Для программирования он неприменим — слишком велика
> C>гибкость програмных систем.
> не понял связи. Или ты тоже сторонник мнения, что в программировании
> главное автокомплит, чтобы кода побольше наколотить?
Нет, просто я не выношу упоминания ТРИЗа применительно к
программированию. Не видел ни одного реального примера, когда бы он
помог сделать правильное архитектурное решение.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[8]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.03.06 09:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет, просто я не выношу упоминания ТРИЗа применительно к

C>программированию. Не видел ни одного реального примера, когда бы он
C>помог сделать правильное архитектурное решение.

А что мешает то? Может просто никто не пытался приложить его к программированию? Если я всё правильно понимаю, то "справочники патернов" aka аналоги решений широко применяются в ТРИЗ, прочтение GoF не отменяет необходимость думать, программирование — инженерная специальность, знанение техник ТРИЗ-а не отменяет необходимость знания технологий программирования. То биш противопоказаний пока не вижу.

ЗЫ. А организация виртуальности ручками — это конечно глупость
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[6]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.03.06 09:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ну и я уж не говорю, что для поиска утечек есть Rational Purify и Valgrind (или ElectricFence для бедных), которые с этой задачей справляются наааааааааааамного лучше.


Кстати, afair это ты рассказывал о том как для поиска утучек в Жабе, в конструкторе объекта запоминался стек-трейс, а в финализаторе он печатался в лог.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: О правильных и неправильных классификациях...
От: FR  
Дата: 16.03.06 09:48
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

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


C>>В морг ТРИЗ. Для программирования он неприменим — слишком велика

C>>гибкость програмных систем.

ANS>не понял связи. Или ты тоже сторонник мнения, что в программировании главное автокомплит, чтобы кода побольше наколотить?


А какое отношение ТРИЗ имеет к автокомплиту?

Вообще конечно интересно посмотреть на прикрутку ТРИЗ к программированию и проектированию, но мне кажется не будет он в нашей области эффективно работать.
Re[9]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 16.03.06 10:02
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>А что мешает то? Может просто никто не пытался приложить его к программированию?

Пытались, на моей памяти в FIDO были ссылки на несколько таких попыток.

ANS>Если я всё правильно понимаю, то "справочники патернов" aka аналоги решений широко применяются в ТРИЗ, прочтение GoF не отменяет необходимость думать, программирование — инженерная специальность, знанение техник ТРИЗ-а не отменяет необходимость знания технологий программирования. То биш противопоказаний пока не вижу.

Вам сильно поможет знание приемов изобразительного искусства или архитектуры (оттуда паттерны и пришли, кстати)? Вот так и методики ТРИЗа плохо приспособлены к проектированию.

ANS>ЗЫ. А организация виртуальности ручками — это конечно глупость

Sapienti sat!
Re[7]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 16.03.06 10:05
Оценка:
Здравствуйте, Andrei N.Sobchuck, Вы писали:

C>>Ну и я уж не говорю, что для поиска утечек есть Rational Purify и Valgrind (или ElectricFence для бедных), которые с этой задачей справляются наааааааааааамного лучше.

ANS>Кстати, afair это ты рассказывал о том как для поиска утучек в Жабе, в конструкторе объекта запоминался стек-трейс, а в финализаторе он печатался в лог.
Ага. Только дело в том, что я это использовал для сравнительно небольшого количества нативных ресурсов. И цель была не найти утечки, а найти неправильное использование. Valgrind тут бы мало чем помог.
Sapienti sat!
Re[5]: О правильных и неправильных классификациях...
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.06 10:09
Оценка: +2
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Кроме того, утверждается, что в программировании на текущий момент известны лишь всего 9 (девять!) видов креативных задач — девять видов противоречий. Конечно, самих задач гораздо больше. А вот их видов — всего девять.


Считается, что сюжетов книг тоже очень мало. Однако вряд ли это знание сильно поможет написать хорошую книгу. Сильно вы все примитивизируете. В реальности основная сложность не в разрешении явно видимых противоречий, а борьба со сложностью и постоянным изменением как требований, так и самой системы. Поэтому всякие ТРИЗовские методики если и будут работать, то на очень примитивном уровне в вырожденных случаях.

КЛ>Вообще в книжках по ООП и ООД, которые я читал, мало уделяется место методикам правильной постановки задач. Можно сказать, что вообще не уделяется. Та же книга "банды четырех" содержит перечень паттернов (приемов) проектирования. И совершенно не содержит описания ситуаций (задач). Конечно, в описаниях самих паттернов приводятся описания и ситуаций, когда паттерн может быть использован. Но в этих описаниях нет системы. Нет сводной таблицы таких описаний, нет общего языка.


КЛ>Не уделяет книга "банды четырех" внимания и процессу формулирования (постановки) таких задач. А зря! Классики говаривали, что поставленная задача — это наполовину решенная задача.


Прочти предисловие к GoF от авторов. Думаю это многое прояснит. Нельзя объять необъятное.

КЛ>Собственно, об этом мы и говорили во второй статье (http://www.triz-ri.ru/themes/method/creative/creative57.asp). И похоже, этого Вы как раз и не поняли.


Это, кстати, в большей части проблема статьи, а не читателя.
... << RSDN@Home 1.2.0 alpha rev. 642>>
AVK Blog
Re: О правильных и неправильных классификациях...
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.03.06 10:37
Оценка: 24 (2) :))) :)
Здравствуйте, Кирилл Лебедев, Вы писали:

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


Не в тему, но данное обсуждение напомнило:

<zenspider> singletons are almost always a sign of bad design.
<suryam> but i need it in my design... [...]
<zenspider> "need" is almost always a sign of bad thought.



SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 16.03.06 11:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

ANS>>А что мешает то? Может просто никто не пытался приложить его к программированию?

C>Пытались, на моей памяти в FIDO были ссылки на несколько таких попыток.

Не нашол. Если есть ссылки — буду рад.

ANS>>Если я всё правильно понимаю, то "справочники патернов" aka аналоги решений широко применяются в ТРИЗ, прочтение GoF не отменяет необходимость думать, программирование — инженерная специальность, знанение техник ТРИЗ-а не отменяет необходимость знания технологий программирования. То биш противопоказаний пока не вижу.

C>Вам сильно поможет знание приемов изобразительного искусства или архитектуры (оттуда паттерны и пришли, кстати)?

Изобразительное искусство тут не причем. А архитектура — причем (напр. создание красивой и лёгкой напряжённой конструкции из монолитного бетона).

C>Вот так и методики ТРИЗа плохо приспособлены к проектированию.


Не понимаю почему. Тем более, что "оттуда паттерны и пришли". Архитектуру не святой же дух приносит. Её придумать нужно. И тут часто нет однозначных вариантов.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: О правильных и неправильных классификациях...
От: EvilChild Ниоткуда  
Дата: 16.03.06 20:04
Оценка: +1 :)
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>P.S.: Мне кажется, что избранный Вами тон уместно использовать в предвыборных роликах кандидатов, но никак не на профессиональном форуме. Даже если коллеги допустили ошибку, на профессиональном форуме уместно вежливо поправлять их. Желательно, с указанием точных ссылок и источников, если вопрос касается терминов или приоритетов.


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


Золотые слова.
Если бы ими руководствовались при написании сообщений в форум, то не приходилось бы скипать такое количества мусора среди них.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 16.03.06 21:11
Оценка: :)
Здравствуйте, Краснокутский Василий, Вы писали:

КВ>На ваше сообщение уже ответил Cyberax и сделал это хорошо.

Похоже, необходимо вернуться к причине дискуссии. В предыдущем сообщении Вы заявили, что статья не содержит ничего нового. В качестве примера нового я Вам привел модели постановки задач (через противоречия). Но Вы это обошли молчанием. Так что будем считать, что новое все-таки было.

Теперь относительно всего остального. Чем дальше я общаюсь с Вами, тем больше склоняюсь к варианту 2. Почему? Сейчас поясню.

КВ>1. Не вижу критериев по которым код оценивает как хороший или плохой.


Критерии все-таки были. Хороший код — это компактный код. В пределе хороша ситуация, когда кода нет, а функция его выполняется. Поэтому идеальный код — это отсутствующий код. Такой код легче всего сопровождать (т.е. вообще сопровождать не надо).

Но это идеал, к которому надо стремиться. Во всех приведенных примерах в первой статье суть задач как раз и состоит, что надо делать много (писать много кода, выводить много классов, просматривать много операторов new), а хотелось бы делать это мало. Лучше, вообще не делать.

С этой точки зрения все приведенные в статье задачи одинаковы. И решения их тоже одинаковы. Вернее, не решения, а принципы (приемы), с помощью которых они получены.

КВ>2. Кстати, не видел общих диаграмм системы, а только кодинг.


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

КВ>3. Статья очень тяжело читается, потому что, во первых много ошибок в коде,

Это утверждение ложно. Привидите примеры ошибок.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[6]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 16.03.06 21:38
Оценка:
Здравствуйте, Cyberax,

Оставляю Ваши оценочные высказывания в стороне. Отвечаю только по сути.

C>Первый пример вообще никуда не годится. Имеем стандартный случай с

C>необходимостью создания функции (тем более, что в реальной жизни у нас
C>не будет хороших статических массивов из трех строк).

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

Тестировал ряд кандидатов при приеме на работу на этой задаче. Если функциям передаются одинаковые данные (т.е. нужно сделать одноходовку), то практически все получают решение. Если же нужно выполнить двухходовку (т.е. действия свернуть в цикл, а данные — в массив), то народ стопорится...

C>И я не понимаю зачем нужно делать механизм виртуальных функций вручную с

C>помощью таблицы функций. Осталось добавить в функции
C>"void DrawBezierX(CDeviceContext & rDC, const POINT * pPoints)" параметр
C>"void *pThis" и мы будем иметь хрестоматийный пример "виртуальность
C>своими руками".

Там же четко написано зачем. Представьте, что у Вас имеется ряд классов, которые отличаются друг от друга только количеством однотипных элементов, например, точек:
— в первом классе 3 точки;
— во втором — 4;
— в 3-ем — 5;
— и т.д.

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

C>В примере с аллокатором вообще куча ошибок. Например, он НЕ будет

C>работать с распределением double'ов на Sparc'ах (будет сразу валится по
C>SIGBUS) из-за проблем с выравниванием. Ну и я уж не говорю, что для
C>поиска утечек есть Rational Purify и Valgrind (или ElectricFence для
C>бедных), которые с этой задачей справляются наааааааааааамного лучше.

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

C>В начале паттерна описывается ситуация когда он нужен, а в тексте

C>описывается чем этот паттерн грозит.

Да, но:

1) отсутствуют способы (модели) постановки задач;
2) отсутствует сводная таблица с описанием типовых проблем и ссылками на паттерны, которые эти проблемы решают (разработчику приходится перелистывать каталог паттернов, когда проще пользоваться сводной таблицей).
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[7]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 16.03.06 22:52
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КВ>>2. Кстати, не видел общих диаграмм системы, а только кодинг.


КЛ>Диаграмма, код, противоречие, описание на естественном языке — суть разные модели представления одной и той же задачи. В приведенных задачах диаграммы НЕ нужны, потому что противоречия описывают задачи наиболее компактно.


Какие конкретно противоречия? Любые? Или только те, которые возникают в требованиях, предъявляемых к решению? Если последнее, то они по определению не могут возникнуть вне контекста исходной постановки задачи.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: О правильных и неправильных классификациях...
От: vdimas Россия  
Дата: 17.03.06 01:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А за тезис:

"Сущности, принадлежащие типу "Разнородные"

автору вообще нужно памятник при жизни ставить. И на памятнике изобразить деление на нуль.



плакаль


ГВ>

ГВ>Мысль 5: В идеале созданный мной контекст должен быть таким, чтобы инкапсулированные в нем функции (методы) ничего не знали о том, кого они обслуживают. "Кого надо, того и обслужат". Обслужат любую ("any") сущность.


ГВ>Ага, всеь огромный поток словоблудия, чтобы перефразировать LSP. Не... Точно — Дзен.


+1
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 17.03.06 07:50
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


КЛ>Тестировал ряд кандидатов при приеме на работу на этой задаче. Если функциям передаются одинаковые данные (т.е. нужно сделать одноходовку), то практически все получают решение. Если же нужно выполнить двухходовку (т.е. действия свернуть в цикл, а данные — в массив), то народ стопорится...


Не нужен цикл. Нужна отдельная функция/метод. И дальше, что угодно. А вот куда это метод вынести, это уже вопрос...
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[7]: О правильных и неправильных классификациях...
От: Краснокутский Василий Россия  
Дата: 17.03.06 08:12
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, Краснокутский Василий, Вы писали:


КВ>>На ваше сообщение уже ответил Cyberax и сделал это хорошо.

КЛ>Похоже, необходимо вернуться к причине дискуссии. В предыдущем сообщении Вы заявили, что статья не содержит ничего нового. В качестве примера нового я Вам привел модели постановки задач (через противоречия). Но Вы это обошли молчанием. Так что будем считать, что новое все-таки было.
Угу, все хорошо кроме того, что противоречия есть в разрешении противоречий и это в посте Cyberax продемонстрировано — не буду дублировать. Давайте определимся что Вы в статье пытаетесь продемонстрировать ?? Подход к решению задачи, подход к постановке задачи или решение задачи ??

КЛ>Теперь относительно всего остального. Чем дальше я общаюсь с Вами, тем больше склоняюсь к варианту 2. Почему? Сейчас поясню.


Мне все равно к какому варианту Вы склоняетесь Я боюсь критериев для оценки моего профессионализма Вы не знаете...

КВ>>1. Не вижу критериев по которым код оценивает как хороший или плохой.


КЛ>Критерии все-таки были. Хороший код — это компактный код. В пределе хороша ситуация, когда кода нет, а функция его выполняется. Поэтому идеальный код — это отсутствующий код. Такой код легче всего сопровождать (т.е. вообще сопровождать не надо).

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

КЛ>Но это идеал, к которому надо стремиться. Во всех приведенных примерах в первой статье суть задач как раз и состоит, что надо делать много (писать много кода, выводить много классов, просматривать много операторов new), а хотелось бы делать это мало. Лучше, вообще не делать.

Вопрос не в том, что бы делать много или мало. При чем здесь вообще оценки кода с точки зрения много/мало ??? Код написанный на разных языках будет отличаться не правда ли ? Вы будете оценивать его как хороший, если он будет содержать меньше сущностей ? Так это, извините, тупик... Я приводил общепринятые критерии в предыдущем посте — прочитайте их еще раз и ответьте на вопрос. Какие из этих критериев Вы улучшаете в своем подходе ?

КЛ>С этой точки зрения все приведенные в статье задачи одинаковы. И решения их тоже одинаковы. Вернее, не решения, а принципы (приемы), с помощью которых они получены.

Повторюсь еще раз — принципы описанные в вашей статье уже сформулированы. Это Open Closed Principle, Liskov Substitution Principle и Dependency Inversion Principle. Поясните мне что нового есть в вашей статье не укладывающегося в Ваши принципы ?

КВ>>2. Кстати, не видел общих диаграмм системы, а только кодинг.


КЛ>Диаграмма, код, противоречие, описание на естественном языке — суть разные модели представления одной и той же задачи. В приведенных задачах диаграммы НЕ нужны, потому что противоречия описывают задачи наиболее компактно.

Ничего себе утверждение — код и диаграммы суть разные вещи, т.к. диаграмма поясняет подход, а код есть реализация подхода. Противоречие = постановка задачи я так понимаю ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.