Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где он говорит о том, что лучше всего писать код, чтобы он предусматривал его простую расширяемость. Т.е. решение не должно ограничиваться конкретной сиюминутной задачей, а быть несколько более общим. Решение может получиться чуть более длинным, но вполне вероятно, что более логичным и простым для понимания.
Конкретно там он описывает шаблонные функции.
Вспомнилось, что рядом недавно С.Губанов "опускал" шаблоны (с чем я естественно не согласен), которые есть один из лучших методов расширения алгоритмов, но возник вопрос:
какие ещё методы "расширяемости" программ можно привести?
Возможно использование интерфейсов/наследования? Что ещё?
Курилка -> "Пути расширяемости кода"
К> Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где К> он говорит о том, что лучше всего писать код, чтобы он предусматривал К> его простую расширяемость. Т.е. решение не должно ограничиваться К> конкретной сиюминутной задачей, а быть несколько более общим. Решение К> может получиться чуть более длинным, но вполне вероятно, что более К> логичным и простым для понимания.
Решение может получиться оооочень длинным. Решение должно соотвествовать
поставленной задаче.
К> Конкретно там он описывает шаблонные функции. К> Вспомнилось, что рядом К> недавно С.Губанов "опускал" шаблоны (с чем я К> естественно не согласен), К> которые есть один из лучших методов К> расширения алгоритмов, но возник К> вопрос: К> какие ещё методы "расширяемости" программ можно привести? К> К> Возможно использование интерфейсов/наследования? Что ещё?
ещё?
Здравствуйте, 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, Вы писали:
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
К>Ну не знаю я такого устаявшегося термина
да, пока оно особо не устоялось, согласен
К>Ну и ссылку про дельфу тоже бы хотелось
в обзорездесь
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, mister-AK, Вы писали:
К>....
К>Спасибо, посмотрим, только вот очень уж дельфоориентированно, я вообще про общие подходы говорил
на самом деле подхлд я бы сказал донельзя общий
просто как обычно все экспериментальное сначала опробируют на Delphi перед продажей MSу
Здравствуйте, mister-AK, Вы писали:
MA>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, mister-AK, Вы писали:
К>>....
К>>Спасибо, посмотрим, только вот очень уж дельфоориентированно, я вообще про общие подходы говорил
MA>на самом деле подхлд я бы сказал донельзя общий MA>просто как обычно все экспериментальное сначала опробируют на Delphi перед продажей MSу
Ну коли так, то должны же быть какие-нибудь "теоретические" статьи, описывающие подходы и т.п.
Нет под рукой подобных линков?
Здравствуйте, Курилка, Вы писали:
К>Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где он говорит о том, что лучше всего писать код, чтобы он предусматривал его простую расширяемость. Т.е. решение не должно ограничиваться конкретной сиюминутной задачей, а быть несколько более общим. Решение может получиться чуть более длинным, но вполне вероятно, что более логичным и простым для понимания. К>Конкретно там он описывает шаблонные функции. К>Вспомнилось, что рядом недавно С.Губанов "опускал" шаблоны (с чем я естественно не согласен), которые есть один из лучших методов расширения алгоритмов, но возник вопрос: К>какие ещё методы "расширяемости" программ можно привести? К>Возможно использование интерфейсов/наследования? Что ещё?
В сумме все методы хорошей расширяемости сводятся к уменьшение зацепления(вредных зависимостей) и возможности дописывать фунцию в программу не меняя ее код а дописывая новый(что тоже достигается перенключением зависимостей на интерефейсы вмето реализаций).
Шаблоны для дизайна уровня программы плохо годятся, но хорошо подходят для создания расширяемых библиотек с модификацией поведения классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый — позволяющий меньше кода писать просто.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, Курилка, Вы писали:
К>Ну коли так, то должны же быть какие-нибудь "теоретические" статьи, описывающие подходы и т.п. К>Нет под рукой подобных линков?
я так и не нашел года два назад чего-то подобное теории по этому делу только какую-то очень отдаленную и сумбурную статейку здесь, когда до это всё своим мозгом придумал и обозвал их expanse-type
я бы таки даже отметил, что хэлперы (расширения одного класса вширь от нескольких сторонних разработчиков) — это некоторый аналог версионного построения СУБД (InterBase и т.п.), которое ща популярно и даже появилось у MS, а так же аналог многозвенки
Расширения должны способствать асинхронной разработке в компонентной среде. Вполне возможно они со временем могут служить заменой не совсем, как мне кажется, правильной идеи вынесить версионнность разработки на уровень сборок как в Net, а не на уровень самоверсионофицируемости типов
Здравствуйте, 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>Шаблоны для дизайна уровня программы плохо годятся, но хорошо подходят для создания расширяемых библиотек с модификацией поведения классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый — позволяющий меньше кода писать просто.
А что вы подразумеваете под высокоуровневым дизайном? И какие инструменты для него подходят...
Здравствуйте, beroal, Вы писали:
B>Здравствуйте, Anatolix, Вы писали: A>>Шаблоны для дизайна уровня программы плохо годятся, но хорошо подходят для создания расширяемых библиотек с модификацией поведения классов. Ну т.е. это не высокоуровнеый дизайн а низкоуровневый — позволяющий меньше кода писать просто. B>А что вы подразумеваете под высокоуровневым дизайном? И какие инструменты для него подходят...
старая сайтовая шутка "..best viewed by eyes"
Голова для этого неплохо подходит.
Ориентация должна быть на то чтобы придумать что-то умное, а не использовать крутой инструмент.
имхо.
И что шаблоны то как раз выражают ту же идею что и Саттер? 
только какую-то очень отдаленную и сумбурную статейку здесь, когда до это всё своим мозгом придумал и обозвал их expanse-type
и реализовать более хитрым способами подцеплять конструктор уже существующего класса в сторонней сборке, причем только тогда, когда понадобиться в коде использовать переменные заведенные в хэлперен или вызывать его перегруженные методы. 
