Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где он говорит о том, что лучше всего писать код, чтобы он предусматривал его простую расширяемость. Т.е. решение не должно ограничиваться конкретной сиюминутной задачей, а быть несколько более общим. Решение может получиться чуть более длинным, но вполне вероятно, что более логичным и простым для понимания.
Конкретно там он описывает шаблонные функции.
Вспомнилось, что рядом недавно С.Губанов "опускал" шаблоны (с чем я естественно не согласен), которые есть один из лучших методов расширения алгоритмов, но возник вопрос:
какие ещё методы "расширяемости" программ можно привести?
Возможно использование интерфейсов/наследования? Что ещё?
Здравствуйте, VladD2, Вы писали:
ЕК>>Читаем М.М. Горбунова-Посадова "расширяемые программы", материалы про аспектно-ориентированное программирование VD>Где?
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, mister-AK, Вы писали:
MA>>Здравствуйте, Курилка, Вы писали:
К>>>какие ещё методы "расширяемости" программ можно привести?
MA>>хэлперы MA>>но как они пока реализованы в Delphi8 мне не очень нравиться
К>Можно конкретней?
Isolating Windows Dependencies
In order to maintain relative platform independence in RTL units, some methods functions that rely on Windows have been moved into the WinUtils unit. In addition, some classes have been changed to rely more on CLR than Windows.
TObject, Exception, TPersistent, and TComponent, all map directly to classes implemented in the .NET Framework. In this way they integrate more smoothly with other .NET applications. Because the corresponding CLR classes (System. Object , System. Exception , System. Marshal , and System. Component ) do not include all the methods that the VCL requires, the missing methods are supplied by Delphi class helper declarations. In most cases, this mechanism is transparent. However, there are a few cases where it requires you to make minor tweaks to your code. For example, with TComponent, FComponentState is now a property of TComponentHelper rather than a true field of TComponent. This means that you can’t use the Include and Exclude methods on FComponentState, because when passed a property, they operate on a copy of the property value, which does not alter FComponentState. Thus code such as
Exclude(FComponentState, csUpdating);
Must be rewritten as
FComponentState := FComponentState – [csUpdating];
TThread has also been changed to map to the CLR thread object. This means that the Thread handle is no longer an ordinal type, but is rather a reference to the underlying CLR thread object. It also means that TThread no longer supports a ThreadID, which is not supported by the CLR thread object. If your thread class requires a ThreadID, you should change it to derive from TWin32Thread instead.
выджержка из help Borland Delphi8 for .Net
К>Ну не знаю я такого устаявшегося термина
да, пока оно особо не устоялось, согласен
К>Ну и ссылку про дельфу тоже бы хотелось
в обзорездесь
Здравствуйте, Курилка, Вы писали:
К>Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где он говорит о том, что лучше всего писать код, чтобы он предусматривал его простую расширяемость. Т.е. решение не должно ограничиваться конкретной сиюминутной задачей, а быть несколько более общим. Решение может получиться чуть более длинным, но вполне вероятно, что более логичным и простым для понимания. К>Конкретно там он описывает шаблонные функции. К>Вспомнилось, что рядом недавно С.Губанов "опускал" шаблоны (с чем я естественно не согласен), которые есть один из лучших методов расширения алгоритмов, но возник вопрос: К>какие ещё методы "расширяемости" программ можно привести? К>Возможно использование интерфейсов/наследования? Что ещё?
В сумме все методы хорошей расширяемости сводятся к уменьшение зацепления(вредных зависимостей) и возможности дописывать фунцию в программу не меняя ее код а дописывая новый(что тоже достигается перенключением зависимостей на интерефейсы вмето реализаций).
Шаблоны для дизайна уровня программы плохо годятся, но хорошо подходят для создания расширяемых библиотек с модификацией поведения классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый — позволяющий меньше кода писать просто.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Курилка, Вы писали:
К>Ну коли так, то должны же быть какие-нибудь "теоретические" статьи, описывающие подходы и т.п. К>Нет под рукой подобных линков?
я так и не нашел года два назад чего-то подобное теории по этому делу только какую-то очень отдаленную и сумбурную статейку здесь, когда до это всё своим мозгом придумал и обозвал их expanse-type
я бы таки даже отметил, что хэлперы (расширения одного класса вширь от нескольких сторонних разработчиков) — это некоторый аналог версионного построения СУБД (InterBase и т.п.), которое ща популярно и даже появилось у MS, а так же аналог многозвенки
Расширения должны способствать асинхронной разработке в компонентной среде. Вполне возможно они со временем могут служить заменой не совсем, как мне кажется, правильной идеи вынесить версионнность разработки на уровень сборок как в Net, а не на уровень самоверсионофицируемости типов
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, Anatolix, Вы писали: A>>Шаблоны для дизайна уровня программы плохо годятся, но хорошо подходят для создания расширяемых библиотек с модификацией поведения классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый — позволяющий меньше кода писать просто. B>А что вы подразумеваете под высокоуровневым дизайном? И какие инструменты для него подходят...
старая сайтовая шутка "..best viewed by eyes"
Голова для этого неплохо подходит.
Ориентация должна быть на то чтобы придумать что-то умное, а не использовать крутой инструмент.
имхо.
Здравствуйте, Евгений Коробко, Вы писали:
ЕК>Читаем М.М. Горбунова-Посадова "расширяемые программы", материалы про аспектно-ориентированное программирование
Почитали... немного... Горбунова-Посадова
Особенно понравилась трактовка понятия "копи-паста", романтично названная "размножение окрестности" и определённые участки, описывающие глубокую проблематику приминения специализированных идеологий разработки для решения проблем, насколько я понимаю, совместной работы нескольких разработчиков за одним монитором...
...Изучать и модифицировать протяженный оператор выбора довольно неудобно, в частности, из-за того, что он не помещается целиком на экране.
Иногда пытаются выйти из положения, оставив в операторе выбора только условия, а все действия оформляя в виде самостоятельных подпрограмм. Возможно, тем самым и удается втиснуть оператор в пространство экрана, но одновременно неоправданно усложняется структура программы.
...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Spidola, Вы писали:
S>>Мне понравилось собственно название...
VD>Дык автора тоже можно понять. Не писат же ему копи-пэст. Видимо орел борец за чистоту русского языка до победного конца. Вот и получаются такие веселые перегибы.
Издание осуществлено при поддержке Российского фонда фундаментальных исследований по проекту № 98-01-14087
Здравствуйте, Курилка, Вы писали:
К>Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где он говорит о том, что лучше всего писать код, чтобы он предусматривал его простую расширяемость. Т.е. решение не должно ограничиваться конкретной сиюминутной задачей, а быть несколько более общим. Решение может получиться чуть более длинным, но вполне вероятно, что более логичным и простым для понимания.
А вот адепты экстремального программирования рекомендуют прямо противоположное. А сам я склонен принимать решение в каждой конкретной ситуации.
Курилка -> "Пути расширяемости кода"
К> Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где К> он говорит о том, что лучше всего писать код, чтобы он предусматривал К> его простую расширяемость. Т.е. решение не должно ограничиваться К> конкретной сиюминутной задачей, а быть несколько более общим. Решение К> может получиться чуть более длинным, но вполне вероятно, что более К> логичным и простым для понимания.
Решение может получиться оооочень длинным. Решение должно соотвествовать
поставленной задаче.
К> Конкретно там он описывает шаблонные функции. К> Вспомнилось, что рядом К> недавно С.Губанов "опускал" шаблоны (с чем я К> естественно не согласен), К> которые есть один из лучших методов К> расширения алгоритмов, но возник К> вопрос: К> какие ещё методы "расширяемости" программ можно привести? К> К> Возможно использование интерфейсов/наследования? Что ещё?
ещё?
Здравствуйте, hrg, Вы писали:
hrg>Курилка -> "Пути расширяемости кода"
К>> Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где К>> он говорит о том, что лучше всего писать код, чтобы он предусматривал К>> его простую расширяемость. Т.е. решение не должно ограничиваться К>> конкретной сиюминутной задачей, а быть несколько более общим. Решение К>> может получиться чуть более длинным, но вполне вероятно, что более К>> логичным и простым для понимания.
hrg>Решение может получиться оооочень длинным. Решение должно соотвествовать hrg>поставленной задаче.
Как всегда необходимо придерживаться "золотой середины", т.е. решение не должно быть решением всех проблем вообще, но подразумевать более общий подход чем, скажем, "1+1=2"
К>> Конкретно там он описывает шаблонные функции. К>> Вспомнилось, что рядом К>> недавно С.Губанов "опускал" шаблоны (с чем я К>> естественно не согласен), К>> которые есть один из лучших методов К>> расширения алгоритмов, но возник К>> вопрос: К>> какие ещё методы "расширяемости" программ можно привести? К>> К>> Возможно использование интерфейсов/наследования? Что ещё? hrg> ещё?
hrg>Читать про паттерны. Банду 4-х, Фаулера.
Я нормально тебя спросил, читать-то я итак много что читал и ещё прочитаю.
Я спросил конкретно: какие ещё способы?
Курилка -> "Re[2]: Пути расширяемости кода"
К>>> Конкретно там он описывает шаблонные функции. К>>> Вспомнилось, что рядом К>>> недавно С.Губанов "опускал" шаблоны (с чем я К>>> естественно не согласен), К>>> которые есть один из лучших методов К>>> расширения алгоритмов, но возник К>>> вопрос: К>>> какие ещё методы "расширяемости" программ можно привести?
К>>> Возможно использование интерфейсов/наследования? Что ещё? hrg>> ещё?
hrg>>Читать про паттерны. Банду 4-х, Фаулера.
К> Я нормально тебя спросил, читать-то я итак много что читал и ещё К> прочитаю. К> Я спросил конкретно: какие ещё способы?
Атвечаю чиста канкретна — АОП
Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист
Здравствуйте, hrg, Вы писали:
hrg>Решение может получиться оооочень длинным. Решение должно соотвествовать hrg>поставленной задаче.
hrg>Читать про паттерны. Банду 4-х, Фаулера.
А не кажется ли, что тут некое противоречие. Шаблоны в основе своей описывают решения, особенно полезные и расчитанные на будущее изменение и расширение системы, а не на минимум кода ради конкретной задачи? И что шаблоны то как раз выражают ту же идею что и Саттер?
AndreyFedotov -> "Re[2]: Пути расширяемости кода"
A> Здравствуйте, hrg, Вы писали:
hrg>>Решение может получиться оооочень длинным. Решение должно hrg>>соотвествовать hrg>>поставленной задаче.
hrg>>Читать про паттерны. Банду 4-х, Фаулера.
A> А не кажется ли, что тут некое противоречие. Шаблоны в основе своей A> описывают решения, особенно полезные и расчитанные на будущее A> изменение и расширение системы, а не на минимум кода ради конкретной A> задачи? И что шаблоны то как раз выражают ту же идею что и Саттер? A>
Противоречия нет. Так же даны советы а не готовые рецепты. Лучше
знать больше и выбирать из множества решений, чем довольствоваться одним
заученным рецептом. Голова — он не только для того чтобы в нее есть
Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист
Здравствуйте, mister-AK, Вы писали:
MA>Здравствуйте, Курилка, Вы писали:
К>>какие ещё методы "расширяемости" программ можно привести?
MA>хэлперы MA>но как они пока реализованы в Delphi8 мне не очень нравиться
Можно конкретней?
Ну не знаю я такого устаявшегося термина
Ну и ссылку про дельфу тоже бы хотелось
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, mister-AK, Вы писали:
К>....
К>Спасибо, посмотрим, только вот очень уж дельфоориентированно, я вообще про общие подходы говорил
на самом деле подхлд я бы сказал донельзя общий
просто как обычно все экспериментальное сначала опробируют на Delphi перед продажей MSу
Здравствуйте, mister-AK, Вы писали:
MA>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, mister-AK, Вы писали:
К>>....
К>>Спасибо, посмотрим, только вот очень уж дельфоориентированно, я вообще про общие подходы говорил
MA>на самом деле подхлд я бы сказал донельзя общий MA>просто как обычно все экспериментальное сначала опробируют на Delphi перед продажей MSу
Ну коли так, то должны же быть какие-нибудь "теоретические" статьи, описывающие подходы и т.п.
Нет под рукой подобных линков?
Здравствуйте, Anatolix, Вы писали:
A>В сумме все методы хорошей расширяемости сводятся к уменьшение зацепления(вредных зависимостей) и возможности дописывать фунцию в программу не меняя ее код а дописывая новый(что тоже достигается перенключением зависимостей на интерефейсы вмето реализаций).
A>Шаблоны для дизайна уровня программы плохо годятся, но хорошо подходят для создания расширяемых библиотек с модификацией поведения классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый — позволяющий меньше кода писать просто.
Ну хорошо, а что ты бы предложил как противопоставление шаблонам? Т.е. чтобы на уровне дизайна?
Ну или вообще какие другие методы "расширяемости" мог бы ты привести?
Anatolix -> "Re: Пути расширяемости кода"
A> Шаблоны для дизайна уровня программы плохо годятся, но хорошо A> подходят для создания расширяемых библиотек с модификацией поведения A> классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый - A> позволяющий меньше кода писать просто.
imho однозначно нет При использовании шаблонов кода становиться все же
больше. По крайней мере поначалу.
Yury Kopyl aka hrg | Только взял боец гитару, сразу — видно гармонист
но стиль идеи им развиваемой впрочем не меняется — мне он кажется не очень внятным и отточенным
В Delphi8 — там хоть что-то можно формализовать по-панятиям...
мне например до сих пор непонятно, почему надо выносить переменные вне хэлпера в отдельный класс (типа TComponentSite для TComponentHelper)
можно же ведь было предусмотреть правильный механизм обертки классов другой сборки и реализовать более хитрым способами подцеплять конструктор уже существующего класса в сторонней сборке, причем только тогда, когда понадобиться в коде использовать переменные заведенные в хэлперен или вызывать его перегруженные методы.
Здравствуйте, Anatolix, Вы писали: A>В сумме все методы хорошей расширяемости сводятся к уменьшение зацепления(вредных зависимостей) и возможности дописывать фунцию в программу не меняя ее код а дописывая новый(что тоже достигается перенключением зависимостей на интерефейсы вмето реализаций).
Другими словами: разбивать программу на минимальные осмысленные самостоятельные части. Расширение сводится к комбинированию таких "кубиков" (при необходимости дописыванию новых). Классический пример из функционального программирования — функция, которая оперирует со структурой списка, не меняя содержания отдельных элементов, например, reverse. Такая "перетасовка" является самостоятельной операцией, не зависящей от типа элементов. Функция требует от объекта, с которым оперирует, только то, что ей нужно, т.е., чтобы он имел последовательную структуру. А, например, у функции map ещё более слабые требования, поэтому она может применяться к спискам, множествам, bag и другим вещам.
Я думаю, это общее правило. Шаблоны, полиморфные функции, интерфейсы, классы — это техника реализации. К>>...решение не должно ограничиваться конкретной сиюминутной задачей, а быть несколько более общим.
Это как посмотреть. Я думаю, в принципе невозможно предсказать, что потребуется завтра. IMHO если человек говорит, что завтра понадобиться то-то, это значит, что это уже когда-то было нужно, но не реализовали по каким-либо причинам.
При разбиении программы на части и сведении зависимостей между ними к минимуму мы и сводим грандиозный проект к набору сиюминутных задач. Isn't it?
Здравствуйте, Anatolix, Вы писали: A>Шаблоны для дизайна уровня программы плохо годятся, но хорошо подходят для создания расширяемых библиотек с модификацией поведения классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый — позволяющий меньше кода писать просто.
А что вы подразумеваете под высокоуровневым дизайном? И какие инструменты для него подходят...
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Anatolix, Вы писали:
A>>В сумме все методы хорошей расширяемости сводятся к уменьшение зацепления(вредных зависимостей) и возможности дописывать фунцию в программу не меняя ее код а дописывая новый(что тоже достигается перенключением зависимостей на интерефейсы вмето реализаций).
A>>Шаблоны для дизайна уровня программы плохо годятся, но хорошо подходят для создания расширяемых библиотек с модификацией поведения классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый — позволяющий меньше кода писать просто.
К>Ну хорошо, а что ты бы предложил как противопоставление шаблонам? Т.е. чтобы на уровне дизайна? К>Ну или вообще какие другие методы "расширяемости" мог бы ты привести?
Интерфейсы(в смысле pure abstract классы) это клачссический пример. Зацепление перемещается с конкретной реализации на абстрактный класс, который по определению меняется реже
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, hrg, Вы писали:
hrg>Anatolix -> "Re: Пути расширяемости кода"
A>> Шаблоны для дизайна уровня программы плохо годятся, но хорошо A>> подходят для создания расширяемых библиотек с модификацией поведения A>> классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый - A>> позволяющий меньше кода писать просто.
hrg>imho однозначно нет При использовании шаблонов кода становиться все же hrg>больше. По крайней мере поначалу.
Если ты делаешь шаблон "просто так чтобы был" то конечно больше. Но обычно их люди делают чтобы из 2 похожих классов сделать один шаблонный.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, beroal, Вы писали:
К>>>...решение не должно ограничиваться конкретной сиюминутной задачей, а быть несколько более общим. B>Это как посмотреть. Я думаю, в принципе невозможно предсказать, что потребуется завтра. IMHO если человек говорит, что завтра понадобиться то-то, это значит, что это уже когда-то было нужно, но не реализовали по каким-либо причинам. B>При разбиении программы на части и сведении зависимостей между ними к минимуму мы и сводим грандиозный проект к набору сиюминутных задач. Isn't it?
Угу. У Роберта Мартина по-моему есть доказательство полуформальное что нельзя закрыть интерфейс от всех изменений сразу. Ну т.е. все равно можно придумать такое изменение, что придется переписывать а не расширять.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, Anatolix, Вы писали: A>>Шаблоны для дизайна уровня программы плохо годятся, но хорошо подходят для создания расширяемых библиотек с модификацией поведения классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый — позволяющий меньше кода писать просто. B>А что вы подразумеваете под высокоуровневым дизайном? И какие инструменты для него подходят...
Классическое ООП то же самое для этого и придумано. Хотя это отнюдь не единственный способ.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Евгений Коробко, Вы писали:
ЕК>Читаем М.М. Горбунова-Посадова "расширяемые программы", материалы про аспектно-ориентированное программирование
Где?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Евгений Коробко, Вы писали:
ЕК>Читаем М.М. Горбунова-Посадова "расширяемые программы", материалы про аспектно-ориентированное программирование
Начал недавно рассматривать АОП, однако пока больше вопросов, нежели ответов. Выделение типовых операций в отдельные блоки используется уже давно. Это правильно. Предлагаемый механизм "аспектов" ИМХО реализует один из способов привязки типовых операций к операциям, реализующим бизнес-логику. Это напоминает триггеры в БД. Однако, в отличии от БД, где есть несколько жёстко определённых операций, на которые данные триггеры навешиваются, в АОП приходится исскуственно задавать такие операции, что накладывает ограничения на гибкость реализации (т.е. классы, реализующие бизнес-операции должны находиться на одинаковом уровне абстракции), что не всегда удобно. Да и "совместимость" подхода АОП с другими идеологиями выглядит для меня сомнительной.
Сама идея АОП несомненно интересна, но как то не выглядит пока такой же универсальной, как ООП.
Здравствуйте, beroal, Вы писали:
B>Это как посмотреть. Я думаю, в принципе невозможно предсказать, что потребуется завтра. IMHO если человек говорит, что завтра понадобиться то-то, это значит, что это уже когда-то было нужно, но не реализовали по каким-либо причинам.
Вот здесь хотелось бы немного прокомментировать. Помимо типовых шаблонов, показывающих, как должна быть построено техническое решение, могут существовать (и существуют), шаблоны бизнес-решений. Вот тут где-то проскакивал шаблон Money — типичная ситуация.
Правда, на данном поле начинают играть другие факторы "расширяемости"... Например, экономические. Если заказчик хочет от вас и платит только за конкретную функциональность, то на расширяемость кода можно махнуть рукой. А если возникает ситуация, при которой может возникнуть необходимость расширяемости кода (причём, оплачиваемая ), то бизнес шаблоны ИМХО разумно их использовать, так сказать, предугадывая дальнейшее развитие требований.
S>...Изучать и модифицировать протяженный оператор выбора довольно неудобно, в частности, из-за того, что он не помещается целиком на экране.
S>Иногда пытаются выйти из положения, оставив в операторе выбора только условия, а все действия оформляя в виде самостоятельных подпрограмм. Возможно, тем самым и удается втиснуть оператор в пространство экрана, но одновременно неоправданно усложняется структура программы.
S>...
Очевидный способ решения — представлять программу в виде дерева и протяжённые узлы сворачивать в [+]. Я даже видел такое в одном специфическом языке программирования. Не думал, что это философская проблема.
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, Spidola, Вы писали: S>>
S>>...Изучать и модифицировать протяженный оператор выбора довольно неудобно, в частности, из-за того, что он не помещается целиком на экране.
S>>Иногда пытаются выйти из положения, оставив в операторе выбора только условия, а все действия оформляя в виде самостоятельных подпрограмм. Возможно, тем самым и удается втиснуть оператор в пространство экрана, но одновременно неоправданно усложняется структура программы.
S>>...
B>Очевидный способ решения — представлять программу в виде дерева и протяжённые узлы сворачивать в [+]. Я даже видел такое в одном специфическом языке программирования. Не думал, что это философская проблема.
Нее... тут идея веселее...
Здесь поднимается вопрос построения архитектуры в зависимости от ширина монитора программиста...
Вообще книга ничего, любопытная... Только уж больно сложными выражениями написаны простые вещи...
Здравствуйте, Курилка, Вы писали:
К>Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где он говорит о том, что лучше всего писать код, чтобы он предусматривал его простую расширяемость. Т.е. решение не должно ограничиваться конкретной сиюминутной задачей, а быть несколько более общим. Решение может получиться чуть более длинным, но вполне вероятно, что более логичным и простым для понимания.
Рекомендация не есть догма. Проведем параллели из шахмат: "Одна фигура стоит плохо --- вся партия стоит плохо" (с) Тарраш. Однако в современной шахматной практике можно найти немало опровержений этому тезису. Точно так же и в программировании. Необходимо четко понимать, на какой уровень рассчитана та или иная рекомендация, в каких случаях она применима, и т. д. Не так давно я видел пример: был текстовый файл, в котором через табуляцию были записаны три поля. Необходимо было эти данные занести в базу данных. Эту задачу реализовал программист А. После того, как в коде была выявлена некоторая ошибка (две табуляции подряд рассматривались как одна), я полез его исправлять. Первоначально я не считал задачу слишком сложной, поскольку ожидал увидеть около двадцати строчек кода. Вместо этого я набрел на текст реализации, содержащией класы TAbstractParser, TParser, TAbstractDocument, TDocument, TRow, TColumn, TAbstractImporter, TImporter, TImportMapper. Я честно угробив на поиски ошибки обеденный перерыв, а потом не выдержали нервы. Делать было нечего, и я написал ожидаемые мною двадцать строчек кода.
Любую идею можно довести до абсурда. Более того, если 99% времени я решаю задачи импорта данных в базу, имеющих самые разнообразные форматы, то приведенный выше набросок не только имеет право на существование, но и является привлекательным. Вопрос о том, что является "расширением", а что "загромождением" является иногда нетривиальным, ввиду того, что порой трудно указать, в какую сторону будет повернут вектор развития системы. И если бы я всегда знал на него ответ... то жил бы в Сочи
В книгах по экстремальному программированию можно встретить прямо обратную рекомендацию --- пишите только то, что вам нужно в этот момент. Тоже имеет право на жизнь. И тоже не всегда.
К>Конкретно там он описывает шаблонные функции. К>Вспомнилось, что рядом недавно С.Губанов "опускал" шаблоны (с чем я естественно не согласен), которые есть один из лучших методов расширения алгоритмов, но возник вопрос: К>какие ещё методы "расширяемости" программ можно привести? К>Возможно использование интерфейсов/наследования? Что ещё?
Когда мы пишем более-менее сложную программу, мы решаем множество вопросов. Некоторые из них: "Как реализовать требуемую функциональность? Что общего у этой функциональности, с уже реализованой (или которую предстоить реализовать)? Какие логические составляющие можно выделисть?" Эти вопросы, как мне кажеться, можно обозначить как представление программы в виде совокупности кода и библиотек (в том числе и автономных). Расширяемость кода прямо зависит от того, насколько грамотно было выполнено это разбиение. Все, что может входить в состав библиотеки (процедуры и функции, интерфейсы и классы, шаблоны, ...) все может служить делу "расширяемости", а двумя словами --- грамотной архитектуры.
Однако, как это ни странно, но процесс проектирование библиотеки это большей частью "сужение" возможностей. Пользуясь "чисто" средствами библиотеки, мы имеем меньше возможностей, зато упрощаем разработку наиболее часто встречающихся задач
Здравствуйте, Spidola, Вы писали:
S>Сама идея АОП несомненно интересна, но как то не выглядит пока такой же универсальной, как ООП.
Не только выглядит, но и уже используется десятки лет. Правда, АОП-ом эти идеи начали называть только в последнее время.
Основная иде АОП заключается в устранении необходимости замусоривать код ненужными деталями, а так же в том чтобы снять с человека заботу о создании этого "мусорного" кода.
Например, я скронен относить генераторы парсеров вроде Yacc/Lex и им подобным к АОП-продуктам. Эти утилиты позволяют выражать свои мысли о синтаксисе разрабатываемого языка максимально чисто и берут на себя заботу по создании обвязочного кода.
Собственно именно так и нужно смотреть на АОП. АОП — это попытка запечатлеть чистую мысль, а мелочевку (которой всегда много) вынести в аспекты.
Одним из мест где идеи АОП, по-моему, должены быть очень эффективны — это реализация патернов проектирования (ПП). ПП — это "стандартные" решения проблем не решенных штатно в системе разработки ПО (языке, среде, фрэйворке...). ПП очень эффектно решают многие проблемы, но к сожалению зачастую на их реализацию стратится слишком много услилий, а их поддержание вообще является самой их слабой стороной. Мне кажется, что все эти проблемы именно из-за остуствия средств АОП. Например, чтобы реализовать паттерн посетитель (Visitor) нужно в выделить некую иерархию классов (это легко решается наследованием от некоторого базового типа), реализовать в каждом из метод AcceptVisitor и наконец добавить по методу для каждого из класса иерерхии. Все это при ручной реализации выливается в кучу работы и постоянно выливается в кучу ошибок. А ведь имея АОП-инструмент можно раз и на всегда автоматизировать процесс создания и поддержки этого патерна. Собственно, вот реализация данного патерна на R# Мета-правило реализующиее паттерн Visitor
S>...Изучать и модифицировать протяженный оператор выбора довольно неудобно, в частности, из-за того, что он не помещается целиком на экране.
S>Иногда пытаются выйти из положения, оставив в операторе выбора только условия, а все действия оформляя в виде самостоятельных подпрограмм. Возможно, тем самым и удается втиснуть оператор в пространство экрана, но одновременно неоправданно усложняется структура программы.
S>...
S>
Что-то в этом фрагменте я не наблюдаю намека на копи-пэст.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Spidola, Вы писали:
S>>
S>>...Изучать и модифицировать протяженный оператор выбора довольно неудобно, в частности, из-за того, что он не помещается целиком на экране.
S>>Иногда пытаются выйти из положения, оставив в операторе выбора только условия, а все действия оформляя в виде самостоятельных подпрограмм. Возможно, тем самым и удается втиснуть оператор в пространство экрана, но одновременно неоправданно усложняется структура программы.
S>>...
S>>
VD>Что-то в этом фрагменте я не наблюдаю намека на копи-пэст.
В книге есть глава, которая называется "Размножение окрестности"... Там это описывается как один из методов создания "вариантных алгоритмических фрагментов". Само по себе использование копипаста там представлено как один из существующих вариантов, в котором больше минусов, чем плюсов.
Мне понравилось собственно название...
1.3. Размножение окрестности
Один из наиболее простых способов решения задачи оформления варианта заключается в следующем. Сначала создается дубль исходного текста программы, содержащей вариантный фрагмент. Порожденный дубль подвергается редактированию, в результате которого старый вариантный фрагмент заменяется новым. Таким образом появляются два текстовых файла-близнеца, отличающиеся друг от друга только вариантными фрагментами (рис. 1.1). ...
Здравствуйте, Spidola, Вы писали:
S>Мне понравилось собственно название...
Дык автора тоже можно понять. Не писат же ему копи-пэст. Видимо орел борец за чистоту русского языка до победного конца. Вот и получаются такие веселые перегибы.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Spidola, Вы писали: S>Почитали... немного... Горбунова-Посадова S>Особенно понравилась трактовка понятия "копи-паста", романтично названная "размножение окрестности"
Да, copy&paste там стоит на первом месте. Целая глава рассуждений на тему, что лучше: копировать или выделять в подпрограмму?
Есть одно интересное решение: неявные параметры (реализованы, например, в GHC: Implicit parameters, и в Lisp должны быть). Кусок кода (в функциональном языке это выражение) просто вырезается и вставляется как тело функции. Ну и все свободные переменные следует заменить на неявные параметры.
Конечно, этого в книге не написано. Совсем нет техничных решений. Основная мысль сводится к тому, что с исходным кодом надо работать не как с однородной текстухой, а как со структурой. Опять же, явного указания, что это должна быть за структура, я не встретил.
только какую-то очень отдаленную и сумбурную статейку здесь, когда до это всё своим мозгом придумал и обозвал их expanse-type
и реализовать более хитрым способами подцеплять конструктор уже существующего класса в сторонней сборке, причем только тогда, когда понадобиться в коде использовать переменные заведенные в хэлперен или вызывать его перегруженные методы. 
