О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 14.03.06 09:49
Оценка: 79 (10) +1
Существует мнение, будто программирование — это искусство написания хитроумных алгоритмов. Чем более навороченный (хитроумный) алгоритм человек может написать, следовательно тем ближе он к представлению об "идеальном программисте". В некоторых конторах даже проверяют в лучшем случае — умение составить хитроумный алгоритм, в худшем — знание некоторых алгоритмов, которые почему-то называют "базовыми". Например, "пузырьковую" сортировку.

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

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

Собственно, об этом рассказывается в этой статье:
http://www.triz-ri.ru/themes/method/creative/creative57.asp
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re: О правильных и неправильных классификациях...
От: Mikhail Polykovsky Россия http://glader.ru
Дата: 14.03.06 12:42
Оценка: +1
КЛ>Собственно, об этом рассказывается в этой статье:
КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

Логический вывод паттернов
Re: О правильных и неправильных классификациях...
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.03.06 14:39
Оценка: :)
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Собственно, об этом рассказывается в этой статье:

КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

Александр Сергеевич Усов, говорит примерно о том же, но другими словами, и Гради Буча тоже высмеивает (делает ему "взБучку" от "vs.Booch-car").
Re: О правильных и неправильных классификациях...
От: ie Россия http://ziez.blogspot.com/
Дата: 15.03.06 04:48
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Собственно, об этом рассказывается в этой статье:

КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

Ряд идей предлагаемых в статье, мне видятся хорошими. Непонравилось одно. Хотя и все примеры с вашей точки зрения "однородны" относительно пресловутого IF, но сравнение разработчика столов и Буча с датчиками (как впрочем и с окнами) просто неадекватное. Если бы столы составляли иерархию и в следствии этого присутсвовал матчинг по типам, то безусловно такое сравнение должно было быть, а в данном случае оно неуклюже пытается связать ни как не связанные примеры.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re: О правильных и неправильных классификациях...
От: Краснокутский Василий Россия  
Дата: 15.03.06 08:02
Оценка:
Честно говоря не понял что такого нового можно извлечь из данной стать. Такое ощушение, что авторы статьи пытаются вывести базовые принципы ООП заново. Все изложенное в статьях уже давно классифицировано и разложено по полочкам.

Почитайте статьи Robert C. Martin на www.objectmentor.com
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: О правильных и неправильных классификациях...
От: GlebZ Россия  
Дата: 15.03.06 08:59
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

В данном случае можно говорить о направленности проектирования на наследование, и на сервис-ориентированность. В случае сервис ориентированости таких проблем нет. Это проблема хренового наследования.
Re[2]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 09:13
Оценка: +1
Здравствуйте, ie, Вы писали:

ie> но сравнение разработчика столов и Буча с датчиками (как впрочем и с окнами) просто неадекватное. Если бы столы составляли иерархию и в следствии этого присутсвовал матчинг по типам, то безусловно такое сравнение должно было быть, а в данном случае оно неуклюже пытается связать ни как не связанные примеры.


Эти примеры одинаковы с той точки зрения, что разработчик мыслит подсистемно, т.е. проектирует от части, а не от целого. В случае со столами — это ножки, в случае с Гради Бучем — это датчики (или даже отдельно взятый датчик температуры).
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[2]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 09:19
Оценка:
Здравствуйте, Краснокутский Василий, Вы писали:

КВ>Честно говоря не понял что такого нового можно извлечь из данной стать.

На случай такой реакции у нас написана статья "Как вспомнить и "так известное" — http://www.triz-ri.ru/themes/method/creative/creative50.asp. Рекомендую!
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re: О правильных и неправильных классификациях...
От: Prometey_ Казахстан vingrad.ru
Дата: 15.03.06 10:11
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

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


КЛ>Собственно, об этом рассказывается в этой статье:

КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

Собственно, этот же смысл можно найти и в книгах "вликолепной четверки", только у них об этом сказано гораздо эллегантней, и без лишнего кода. Краткость — сестра таланта.
Re[2]: О правильных и неправильных классификациях...
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 15.03.06 10:24
Оценка: 11 (2) +2
Здравствуйте, Prometey_, Вы писали:

P_>Собственно, этот же смысл можно найти и в книгах "вликолепной четверки", только у них об этом сказано гораздо эллегантней, и без лишнего кода. Краткость — сестра таланта.


Я так понимаю, цели то разные. Имхо, в данном случае — привить некий стиль мышления, а там справочник патернов.
http://www.smalltalk.ru | << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[3]: О правильных и неправильных классификациях...
От: Краснокутский Василий Россия  
Дата: 15.03.06 11:09
Оценка: 23 (3)
Здравствуйте, Кирилл Лебедев, Вы писали:

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


КВ>>Честно говоря не понял что такого нового можно извлечь из данной стать.

КЛ>На случай такой реакции у нас написана статья "Как вспомнить и "так известное" — http://www.triz-ri.ru/themes/method/creative/creative50.asp. Рекомендую!

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

Поясняю:
Если у нас есть задача, то мы можем решить ее 1000 способов (это я про программирование), но при этом конечный результат развития данной реализации все же зависит от того, насколько хорошо нам известна предметная область и какой общий опыт/знания разработки систем данного класса. Дело в том, что нельзя сделать программу универсальной и все равно будут '+' и '-' у каждого подхода — либо в начале, либо в дальнейшем развитии ПО. Вопрос то в сущности не в сложности проектирования, а в том, что мы хотим от конечного кода. Пользователя не волнует как все это в программе реализовано (ну понятно, что для чего то пишем мы код, а не просто из удовольствия) и вопрос в том, что бы найти такой подход, что бы код был сопровождаем и расширяем с точки зрения программиста, но при этом еще и удобен для конечного пользователя. Авторы статьи рассматривают вопрос только с точки зрения кодирования и при этом теряется другая составляющая — потребности конечного пользователя. Я скажу больше — весь стройный код может сломаться от того, что пользователь придумал такое требование, которое в нашу архитектуру без большой переделки не влезает, а переписывать архитектуру каждый раз когда возникнут такие требования это самоубийство. Вот и появляются "сказки" про фиговых проектировщиков и т.п.

Мой вывод: Идеального кода не бывает — бывает код заточенный под определенный спектр изменений. Если потребовалось изменение не попадающее в эти границы, то у нас возникает проблема — либо ломать архитектуру и тратить время (читайте деньги), либо ставить "заплатку". Понятно, что с большей вероятностью будет поставлена заплатка. А то, что пытаются продемонстрировать авторы есть их понимание некой задачи в отрыве от пользователя, что суть совершенно неверно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: О правильных и неправильных классификациях...
От: GlebZ Россия  
Дата: 15.03.06 11:55
Оценка:
Здравствуйте, Краснокутский Василий, Вы писали:

А я скажу еще больше. В наше итерационное время требований для следующей итерации вообще не может существовать в природе. Поэтому надо закладывать гибкость изначально. Кое-что будет из заложенного использовано, кое-что никогда не будет. Только закладываться надо, иначе будет значительно больнее. И тут уже во многом играет эвристика.
Так что в некотором виде автор прав. Просто там изначально ошибочные подходы, без какой либо закладки на развитие.
Re[4]: О правильных и неправильных классификациях...
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 19:32
Оценка: 13 (4) +1
Здравствуйте, Краснокутский Василий, Вы писали:

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


Работая над первой статьей (http://www.triz-ri.ru/themes/method/creative/creative50.asp), мы столкнулись с подобным отношением со стороны ряда программистов. Наиболее частый упрек: "Все, что вы пишите, и так известно". Собственно, отсюда и пошло название статьи: "Как вспомнить и "так известное"?".

У подобного отношения могут быть такие обоснования:
1) Человек является профи, и ему действительно знакомо все то, о чем написано в статье.
2) Человек понимает статью лишь частично — улавливает знакомые вещи и не улавливает незнакомые. Например, понимает примеры и не понимает выводы.

Судя по опыту общения, на мой взгляд, более вероятен вариант 2, нежели 1. Т.е. во всех случаях, когда программист заявлял, что ему все написанное в статье знакомо, на деле же оказывалось, что он, в своей практике, все равно мыслил и проектировал подсистемно, т.е. с датчика или ножки, а никак не с группы или чего-то большего.

Отсюда вывод: даже если фразы кажутся знакомыми, когда дело доходит до практики, за дело берется привычка.

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

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

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

Думаю, если вопросу постановки и классификации задач уделить должное внимание, то большинство паттернов можно свернуть в более компактную модель и даже открыть другие паттерны. Собственно говоря, к этому мы и стремимся.

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


Судя по Вашему высказыванию, Вы рассматриваете пользователя, как источник хаотичных изменений, которые никак нельзя предусмотреть, и потому они разрушают архитектуру. Между тем уже давно известно, что системы развиваются не хаотично (под воздействием импульсивных желаний), а согласно законам развития (http://www.altshuller.ru/triz/zrts1.asp). Эти законы познаваемы, а, следовательно, их вполне можно использовать для прогнозирования.

Конечно, если мыслить подсистемно, то спрогнозировать дальнейшее развитие программы (и отдельных ее частей) просто невозможно. Нужно рассматривать систему не саму по себе, а систему в контексте! См. 9-экранную систему мышления (http://www.altshuller.ru/triz/zrts6.asp).

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

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


Это утверждение ложно, т.к. все задачи (за исключением задачи про стол) взяты из реальной практики. Да и у "стола" тоже были свои прототипы.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[5]: О правильных и неправильных классификациях...
От: Cyberax Марс  
Дата: 15.03.06 20:32
Оценка: 24 (2) +3
Кирилл Лебедев wrote:
> У подобного отношения могут быть такие обоснования:
> 1) Человек является профи, и ему действительно знакомо все то, о чем
> написано в статье.
> 2) Человек понимает статью лишь частично — улавливает знакомые вещи и не
> улавливает незнакомые. Например, понимает примеры и не понимает выводы.
Нет уж. Пусть лучше читает классиков, в которых процесс декомпозиции
задачи разбирается намного проще.

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

В случае с фигурой стоит отделить данные фигуры от метода ее
отображения. Вообще совсем отделить. Читайте любой пример про мультиметоды.

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

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


> Вообще в книжках по ООП и ООД, которые я читал, мало уделяется место

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

> Конечно, в описаниях самих паттернов приводятся описания и

> ситуаций, когда паттерн может быть использован. Но в этих описаниях *нет
> системы*. Нет сводной таблицы таких описаний, нет общего языка.
:O) Странно, а я вот вижу систему.

> Не уделяет книга "банды четырех" внимания и процессу формулирования

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

> Думаю, если вопросу постановки и классификации задач уделить должное

> внимание, то большинство паттернов можно свернуть в более компактную
> модель и даже открыть другие паттерны. Собственно говоря, к этому мы и
> стремимся.
Я новых паттернов хоть десяток могу левой пяткой накатать. На сайтах
типа theserverside.com их вообще коллекционируют (
http://www.theserverside.com/patterns/index.tss ).

Смылс в том, чтобы выделить какой-то один достаточно репрезентативный
набор паттернов. У GoF это неплохо получилось (хотя паттерн Intepreter я
бы выкинул нафиг).

> Судя по Вашему высказыванию, Вы рассматриваете пользователя, как

> источник хаотичных изменений, которые никак нельзя предусмотреть, и
> потому они разрушают архитектуру. Между тем уже давно известно, что
> системы развиваются не хаотично (под воздействием импульсивных желаний),
> а согласно законам развития (http://www.altshuller.ru/triz/zrts1.asp).
В морг ТРИЗ. Для программирования он неприменим — слишком велика
гибкость програмных систем.

> Эти законы познаваемы, а, следовательно, их вполне можно использовать

> для прогнозирования.
Ага, конечно.

Вот как пример, у меня есть компонент для отображения 3D-профиля плоской
поверхности (полученой с некого измерительного устройства). Угадайте,
что меня попросили добавить в него неделю назад?

> Это утверждение ложно, т.к. все задачи (за исключением задачи про стол)

> взяты из реальной практики. Да и у "стола" тоже были свои прототипы.
Ага, это показывает, что практика у вас плохая.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 21:10
Оценка: 42 (3) :))) :))
Здравствуйте, Кирилл Лебедев, Вы писали:

Не, ну чисто революция в наших сердцах, не иначе. Читал — смеялся.

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


И где это такое мнение? О програмировании ровно столько мнений, сколько людей так или иначе задето этим процессом.

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


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

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


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

КЛ>Собственно, об этом рассказывается в этой статье:

КЛ>http://www.triz-ri.ru/themes/method/creative/creative57.asp

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

Хотя, конечно, без ниспровергания авторитетов ну никак:

Сделаем выводы и сформулируем некоторые отличия от общепринятых трактовок (отличия, впрочем, небольшие):


Ключевой, как я понял, тезис:

Всегда ошибетесь с контекстом, если будете класс "выводить из подсистемы".


Отметим эту глубокую мысль. Например так: (*)

2. Когда Ваш оператор if привязан к объекту, есть вероятность, что данную ошибку Вы совершили.


Мда. "Есть вероятность". Однако, чёткий формальный критерий нарушения LSP, оказывается, "есть вероятность". Сурр-рово. Есть вероятность, что 4 != 5. Давайте, обдумаем это на ближайщем слёте топ-менеджмента?

За вот такие формулировочки:

Но в какой-то момент надо сделать шаг вперед. Есть более удобные, чем "тип", термины: "однородность", "контекстность". Мы будем говорить, что сущности однородны, если они принадлежат одному контексту.


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

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

Буквально, следущий абзац:

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


Это уже Дзен. 4=5 и в этом смысле 6=7.

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

Уж лучше сказать... а вот не скажу, как. Сами догадаетесь.

А если мы заведем группу "Разный неструктурированный мусор", то все помещенное в эту группу будем считать однородным с точки зрения данного контекста.


...и с нами случится просветление. Слушайте, где такая трава растёт?

А за тезис:

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

автору вообще нужно памятник при жизни ставить. И на памятнике изобразить деление на нуль. Не удивительно, что автор поместил сие откровение в примечании. Это ж насколько нужно путаться в собственных идеях, что без примечаний и не высказать?!

4. Значит, можно трактовать класс не столько как тип и не столько как общий случай нашего частного объекта, сколько как один из контекстов для функций, частный случай группировки функций — место, где функции ("методы") лежат "пачкой".

Эта трактовка совсем уж нарушает общепринятую ООП-традицию, но и не отрицает ее – просто сводит к частному случаю


Ага. Дизъюнктивная когерентность рулит, ну хто бы спорил. Конечно, компилятор, он всё стерпит. Можно трактовать класс как угодно, только такой трактовкой мы разносим вообще всю теорию в пух и прах. А чё нам? Ща на ноль поделим и получим, что 4 = 5, а тип = контекст.

Разумеется, без Нильса Бора не обошлось. А как же? Великий авторитет древних — это руль форевер.

Ну и блистательный полёт мысли (надо же, прилетели таки?!)

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


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

За авторской подписью, случайно, не Бодхидхарма скрывается?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 21:14
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Александр Сергеевич Усов, говорит примерно о том же, но другими словами, и Гради Буча тоже высмеивает (делает ему "взБучку" от "vs.Booch-car").


Буча не высмеивает только ленивый. Ниспровергатели, блин.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: О правильных и неправильных классификациях...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 21:18
Оценка: 4 (1) :)
Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Работая над первой статьей (http://www.triz-ri.ru/themes/method/creative/creative50.asp), мы столкнулись с подобным отношением со стороны ряда программистов. Наиболее частый упрек: "Все, что вы пишите, и так известно". Собственно, отсюда и пошло название статьи: "Как вспомнить и "так известное"?".


КЛ>У подобного отношения могут быть такие обоснования:

КЛ>1) Человек является профи, и ему действительно знакомо все то, о чем написано в статье.
КЛ>2) Человек понимает статью лишь частично — улавливает знакомые вещи и не улавливает незнакомые. Например, понимает примеры и не понимает выводы.

3) Не постиг сущность хлопка одной ладони.

КЛ>Судя по опыту общения, на мой взгляд, более вероятен вариант 2,


Ясен перец, как говорил Нильс Бор, дураков всегда больше.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: Дополнение про (*)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 21:27
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

А кто мне объяснит, чем "дизайн от подсистемы" отличается от "дизайна от контекста"? Подсистема уже перестала быть контекстом?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: Дополнение про (*)
От: Кирилл Лебедев Россия http://askofen.blogspot.com/
Дата: 15.03.06 22:13
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А кто мне объяснит, чем "дизайн от подсистемы" отличается от "дизайна от контекста"? Подсистема уже перестала быть контекстом?


Подсистема является контекстом (надсистемой) для систем, образующих ее. Для системы, в которую она входит, она контекстом не является.
С уважением,
Кирилл Лебедев
Software Design blog — http://askofen.blogspot.ru/
Re[3]: Дополнение про (*)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 15.03.06 22:24
Оценка:
Здравствуйте, Кирилл Лебедев, Вы писали:

ГВ>>А кто мне объяснит, чем "дизайн от подсистемы" отличается от "дизайна от контекста"? Подсистема уже перестала быть контекстом?


КЛ>Подсистема является контекстом (надсистемой) для систем, образующих ее. Для системы, в которую она входит, она контекстом не является.


Сиречь, речь идёт о реюзинге?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.