Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, 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 — типичная ситуация.
Правда, на данном поле начинают играть другие факторы "расширяемости"... Например, экономические. Если заказчик хочет от вас и платит только за конкретную функциональность, то на расширяемость кода можно махнуть рукой. А если возникает ситуация, при которой может возникнуть необходимость расширяемости кода (причём, оплачиваемая ), то бизнес шаблоны ИМХО разумно их использовать, так сказать, предугадывая дальнейшее развитие требований.
Здравствуйте, VladD2, Вы писали:
ЕК>>Читаем М.М. Горбунова-Посадова "расширяемые программы", материалы про аспектно-ориентированное программирование VD>Где?
Здравствуйте, Евгений Коробко, Вы писали:
ЕК>Читаем М.М. Горбунова-Посадова "расширяемые программы", материалы про аспектно-ориентированное программирование
Почитали... немного... Горбунова-Посадова
Особенно понравилась трактовка понятия "копи-паста", романтично названная "размножение окрестности" и определённые участки, описывающие глубокую проблематику приминения специализированных идеологий разработки для решения проблем, насколько я понимаю, совместной работы нескольких разработчиков за одним монитором...
...Изучать и модифицировать протяженный оператор выбора довольно неудобно, в частности, из-за того, что он не помещается целиком на экране.
Иногда пытаются выйти из положения, оставив в операторе выбора только условия, а все действия оформляя в виде самостоятельных подпрограмм. Возможно, тем самым и удается втиснуть оператор в пространство экрана, но одновременно неоправданно усложняется структура программы.
...
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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Spidola, Вы писали:
S>>Мне понравилось собственно название...
VD>Дык автора тоже можно понять. Не писат же ему копи-пэст. Видимо орел борец за чистоту русского языка до победного конца. Вот и получаются такие веселые перегибы.
Издание осуществлено при поддержке Российского фонда фундаментальных исследований по проекту № 98-01-14087
Здравствуйте, Spidola, Вы писали: S>Почитали... немного... Горбунова-Посадова S>Особенно понравилась трактовка понятия "копи-паста", романтично названная "размножение окрестности"
Да, copy&paste там стоит на первом месте. Целая глава рассуждений на тему, что лучше: копировать или выделять в подпрограмму?
Есть одно интересное решение: неявные параметры (реализованы, например, в GHC: Implicit parameters, и в Lisp должны быть). Кусок кода (в функциональном языке это выражение) просто вырезается и вставляется как тело функции. Ну и все свободные переменные следует заменить на неявные параметры.
Конечно, этого в книге не написано. Совсем нет техничных решений. Основная мысль сводится к тому, что с исходным кодом надо работать не как с однородной текстухой, а как со структурой. Опять же, явного указания, что это должна быть за структура, я не встретил.
Здравствуйте, Курилка, Вы писали:
К>Начал тут вчера читать книгу Саттера и набрёл на рекоммендацию, где он говорит о том, что лучше всего писать код, чтобы он предусматривал его простую расширяемость. Т.е. решение не должно ограничиваться конкретной сиюминутной задачей, а быть несколько более общим. Решение может получиться чуть более длинным, но вполне вероятно, что более логичным и простым для понимания.
А вот адепты экстремального программирования рекомендуют прямо противоположное. А сам я склонен принимать решение в каждой конкретной ситуации.
При использовании шаблонов кода становиться все же
