Здравствуйте, stalcer, Вы писали:
S>Имхо, разбивание по неймспейсам должно быть такое, какое удобно пользователю твоей либы. То есть не нужно делать много маленьких неймспейсов, а то он задолбается писать юзинги, и постоянно будет натыкаться на ошибку о неизвестном идентификаторе,
А что, using'и кто-то еще пишет руками?
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Re[15]: Короткие или длинные исходинки - Модульный подход
Здравствуйте, stalcer, Вы писали:
S>Вот такие дела...
Кстати, сказать, в Open Source BlackBox модуль выгружать можно, за исключением случая когда он импортирован другим модулем (сначала надо выгрузить тот — и так по очереди от листьев к корню). А что до хуков (адресов процедур которых больше нет) — глюкаются они конечно со страшной силой, но особого вреда системе не причиняют — там поставлены системные ловушки (что-то вроде catch-ей). Например, если выгрузить модуль в котором был описан объект View, который отображался, то вместо рисунка этого View появится сеточка — дескать объект неожиданно сдох под воздействием непреодолимой силы.
Здравствуйте, Cyberax, Вы писали:
C>Сторонние либы гадят в основной неймспейс? Еще помогает то, что у нас нэймспейсы организованы наподобии пакетов в Java.
Ну не не нравится мне он. К томуже глючит... я сейчас посмотрел там не все классы которые есть в проекте...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Короткие или длинные исходинки - Модульный подход
Для С#.
Не делать. Что касается конкретной работы, то Studio не очень помогает при навигации со своими namespace. Даже скорее мешается. Важнее и достаточно само понятие сборки и классов. Смысла в namespace больше чем как разрешения конфликтов имен, я не вижу. Поэтому у меня редко в сборке более 1 namespace.
Для С++
Тут вообще всегда обходился одним namespace или без оного. И как-то никогда более не требовалось. Не попадал на такие ситуации, и по старинке уникальность определялась только именем класса.
Здравствуйте, VladD2, Вы писали:
VD>Скажу крамольную фразу. Размер отдельных исходных файлов и количество типов в одном файле обратно пропорционален классу программиста.
Да!!!
А уж для языка С++ это категорически так.
Причем должна быть известна функция ИмяФайла=F(ИмяТипа).
Здравствуйте, stalcer, Вы писали:
S>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
Тут внизу равертывается дикое обсуждение, а все потому, что код бывает разный, и предназанчение кода бывает разное. Если вы пишете библиотеку, да еще шаблонную, то пихать каждый маленький функутор в отдельный файл не стоит.
Разбиение на файлы диктуется
— удобством
— логической зависмостью классов
— физическим размером кода
— нежеланием иметь в одном заголовочном файле классы, применяемые независимо
— размером команды и организаией работы в команде
и др.
начнем с конца, самого главного.
+Если у вас в команде принято делить отвественность и исправлять баги и добавлять фичи в коде, созданном другими людьми (лучший вариант, особенно для команд работающих в разных часовых поясах и разных офисах), то выгодно иметь много мелких файлов, так как не тратится время на мерджинг, легко находить файлы, которые люди забыли добавить в проект, а часто легко догадаться о содержимом файла, если его забыли положить вообще.
+Кроме того, история изменений для каждого отдельного файла становится короче, легко анализировать изменения. +Легко находить ответственного за ошибку.
+При использовании блокирующих систем контроля версий, реже возникают конфликты.
-если изменение затронуло группу файлов, иногда нужно тратить больше времени и услилий, чтобы его просмотреть через большой промежуток времени, так как надо искать изменения за одну дату.
Далее. Иногда, если классики маленькие разбрасывать вспомогательные классы по файлам не хочется.
С другой стороны если файлы большие, то лучше разложить по файлам.
Во-первых, не факт что не пригодится отдельно.
А во-вторых, с ними становится удобнее работать, потому что редактор запоминает позицию курсора в каждом файле. И хотя редакторы позволяют открыть один файл в разных лкнах, этим мало кто пользуется.
Ну а вопрос о размерах класса и размерах функции — отдельный, и к делу не относится.
Здравствуйте, Xentrax, Вы писали:
X>Здравствуйте, stalcer, Вы писали:
S>>Кто как предпочитает писать: Много маленьких исходных текстов или немного, но более длинных? Какова средняя длина (хотя бы с точностью до порядка)? Аргументы в пользу того или иного подхода?
X>Тут внизу равертывается дикое обсуждение, а все потому, что код бывает разный, и предназанчение кода бывает разное. Если вы пишете библиотеку, да еще шаблонную, то пихать каждый маленький функутор в отдельный файл не стоит.
X>Разбиение на файлы диктуется X>- удобством X>- логической зависмостью классов X>- физическим размером кода X>- нежеланием иметь в одном заголовочном файле классы, применяемые независимо X>- размером команды и организаией работы в команде
X>Далее. Иногда, если классики маленькие разбрасывать вспомогательные классы по файлам не хочется.
см. меня. Я уже об этом писал, особенно по поводу того, что классы имеют свойства разрастаться. Потом не очень-то удобно их разделять на файлы, да и названия файлов тогда хуже согласуются.
X>С другой стороны если файлы большие, то лучше разложить по файлам.
X>Во-первых, не факт что не пригодится отдельно.
X>А во-вторых, с ними становится удобнее работать, потому что редактор запоминает позицию курсора в каждом файле. И хотя редакторы позволяют открыть один файл в разных лкнах, этим мало кто пользуется.
X>Ну а вопрос о размерах класса и размерах функции — отдельный, и к делу не относится.
Как раз относится.
В общем, по моему Xentrax написал резюме того, что тут говорилось при обсуждении.
Здравствуйте, Cyberax, Вы писали:
C>Есть вкладка "ClassView" — в ней класс точно так же выбрать можно.
Ты не поверишь, но при большом количестве файлов ClassView тоже доступен. Вот только почему-то я не часто им пользуюсь. Почему? Да потому, что там просто свалка из классов. Даже фильтраций в 2005-ой студии дает слишком много вариантов в больших проектах. А вот в недерве проекта разобраться элементарно, так как это дерево. Все файлы структурированы каталогами и на их поиск почти не тратится вренмени.
C>У меня в солюшене 20 проектов, кода около мегабайта. Файлов порядка 100.
C>Поиск определения "глазками" — не напрягает абсолютно, в каждом файле C>1-3 класса. Самое большее — 20 (классы узлов AST-дерева).
Вауууу!!!
Это выходит в среднем по 5 файлов на проект? Если не ошибаюсь ты на С++ пишешь? Значит из этих 5 файлов еще и инклюды есть?
Да и 20 проектво это тоже явный перебор.
Для сравнения могу привести характиристики R#-а.
Количество проектов — 13. Из них 1 проекты CocoR (к R#-у отношения не имеет) и 4 проекта генерирующие код (т.е. не С#-ные).
Количество .cs-файлов — 673. (кстати, это C#-файлы, так что на С++ их объем заметно увеличился бы).
Объем в мегабайтах — 2.7.
Количество АСТ-классов 187.
Боюсь, чтодучи построенным по твоим принципам он просто развалился бы.
>> C>VisualAssist справляется. >> Помню я как он справлялся. Вместо АТЛ-а показывал МФЦ. А на более >> менее сложных шаблонах врал безбожно. C>Он с тех пор улучшился.
Но не думаю, что он дошел до качества компилятора. А для безошибочной работы нужно именно это.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>WolfHound wrote:
>> C>Есть вкладка "ClassView" — в ней класс точно так же выбрать можно. >> Никогда им не пользуюсь ибо там утонуть можно...
C>namespace спасают.
Ты же вроде с АСТ возишся. Так? Тогда кому как не тебе знать, о том что бывают случаи когда простраства имен оказываются ну очень большими. В AST R#-а более 180 классов. Смотреть на них как на плоских список занятие не из приятных.
>> C>У меня в солюшене 20 проектов, кода около мегабайта. Файлов порядка 100. >> А у меня 78 проектов 10,078,520 байтов кода в 2268 файлах.
C>У нас в проекте лежит еще куча либ, с ними кода мегов на 20 будет.
Щаз он тебе расскажет о размере фрэймворка.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
ГВ>>Классы программы образуют её логическую структуру. Файлы с исходным кодом — файловую (или "физическую") структуру. ГВ>>Для чего нужны классы? Для того, чтобы структурировать представление о предметной области. WH>Бесспорно. ГВ>>Для чего нужны файлы? Для того, чтобы это представление было удобно модифицировать одному или нескольким людям. "Удобство" означает и примлемую навигацию, и трансляцию, и check-in/out и т.п. WH>Согласен. Но "удобство" понятие субъективное.
+1 В том-то и дело.
WH>Например в моей практике был случай когда мне пришлось разделить один класс на несколько файлов. Ибой искать конци в файле в несколько тысяч строк мне очень не понравилось. WH>Только не надо про кривизну дизайна. Нужно было реализовать в одном классе несколько здоровых COM интерфейсов которые придумал не я.
Дык к таким классам (aka API, aka Facade) мои рассуждения не особо и относятся.
VD>>> Ну, и для рефакторинга лучшеп пользоваться средствами вроде Решарпера. ГВ>>Он не всегда помогает. WH>Например?
Например, если меняется протокол взаимодействия объектов.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>>> Основная причина — различия в работе с одним и несколькими файлами в текстовом редакторе. VD>>>И что прыганье по туче мест в одном файле проще чем выбрать в дереве проекта нужный файл-класс? ГВ>>Чёй-то я не понимаю противопоставления. Тут уж или "выбрать несколько файлов", или вообще никакого противопоставления нет. VD>Не понимашь? Тогда о чем споришь?
Я и не спорю. Я предполагаю возможные трактовки.
VD>>>Нет. Из этого следует, что для С++ (если бы не тормоза при компиляции и проблему необходимости предварительной декларации) в первую очередь полезно разносить классы по отдельным файлам. ГВ>>А кто спорит с полезностью разнесения классов по файлам вообще? VD>Мне показалось, что ты. Я ошибся?
Да, ошибся.
ГВ>> Я как раз оспариваю постулат, что "один класс = один файл". VD>Оспаривай.
В соседней ветке
[...] ГВ>> я уж даже удивляться перестал. VD>А ты удивлялся?
Нет, аккурат с 2002 года.
ГВ>>Другое дело, что основания для такого твоего вывода выглядят всё более зыбкими... VD>Аутотренинг тебе явно вреден.
Чей?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, FDSC, Вы писали:
ГВ>>А вот тут давай поподробнее. С чего ты взял, что "серьёзные классы", размер которых приводит к "аду" в навигации по его телу вообще должны быть? Моё и, кстати, не только моё мнение по этому поводу сводится к тому, что большие классы нужно рубить на куски. Чем раньше, тем лучше. В противном случае получаем суровую ошибку проектирования. Разумеется, это не относится к классам-API типа какого-нибудь навороченного интерфейса IMyCoolSoftware о двухстах методах, поскольку такие классы как правило содержат очень простой шлюзовой код и ничего более.
FDS>Между прочим, при анализе исходников, в "серьёзных классах" ориентироватся гораздо легче, т.к. при разбиении последних обычно получается запутанная иерархическая структура — ад для отладки и производительность обычно ниже. И вообще, что такое "серьёзный класс" ещё подумать надо прежде чем писать (я уже не подумал, у меня всегда так)
Ну, это уже зависит не только и не столько от размера, сколько от других факторов.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
VladD2 wrote:
> C>Есть вкладка "ClassView" — в ней класс точно так же выбрать можно. > Ты не поверишь, но при большом количестве файлов ClassView тоже > доступен. Вот только почему-то я не часто им пользуюсь. Почему? Да > потому, что там просто свалка из классов. Даже фильтраций в 2005-ой > студии дает слишком много вариантов в больших проектах. А вот в > недерве проекта разобраться элементарно, так как *это дерево*. Все > файлы структурированы каталогами и на их поиск почти не тратится вренмени.
Просто можно изначально ориентироваться на "чистый" ClassView — тогда
все будет нормально.
> C>У меня в солюшене 20 проектов, кода около мегабайта. Файлов порядка 100. > C>Поиск определения "глазками" — не напрягает абсолютно, в каждом файле > C>1-3 класса. Самое большее — 20 (классы узлов AST-дерева). > Вауууу!!! > Это выходит в среднем по 5 файлов на проект? Если не ошибаюсь ты на > С++ пишешь? Значит из этих 5 файлов еще и инклюды есть?
Инклуды не посчитал, сглючил, только cpp взял. С инклудами — в 4 раза
больше файлов.
> Да и 20 проектво это тоже явный перебор.
А что делать... Проекты действительно логически отдельные.
> Боюсь, чтодучи построенным по твоим принципам он просто развалился бы.
Нет, были у меня и такие проекты — вполне нормально жили. Буст же живет
вполне нормально.
>>> C>VisualAssist справляется. >>> Помню я как он справлялся. Вместо АТЛ-а показывал МФЦ. А на более >>> менее сложных шаблонах врал безбожно. > C>Он с тех пор улучшился. > Но не думаю, что он дошел до качества компилятора. А для безошибочной > работы нужно именно это.
А 100% безошибочность от Vassist'а и не нужна (в отличие от
компилятора). Вполне достаточна 95%, современный ассист как раз примерно
на этом уровне и работает.
VladD2 wrote:
> C>namespace спасают. > Ты же вроде с АСТ возишся. Так? Тогда кому как не тебе знать, о том > что бывают случаи когда простраства имен оказываются ну очень > большими. В AST R#-а более 180 классов. Смотреть на них как на плоских > список занятие не из приятных.
namespace val_nodes;
namespace literal_nodes;
namespace bindable_nodes;
...
>>> C>У меня в солюшене 20 проектов, кода около мегабайта. Файлов > порядка 100. >>> А у меня 78 проектов 10,078,520 байтов кода в 2268 файлах. > C>У нас в проекте лежит еще куча либ, с ними кода мегов на 20 будет. > Щаз он тебе расскажет о размере фрэймворка.
VladD2,
> ПК> Начал было расписывать явные "ляпы", но решил не тратить время: там все без очков видно. Одно напихивание в этот и без того раздутый интерфейс функциональности, связанной с e-mail чего стоит...
> Можешь подобные вещи просто не брать врассчет. И без того интерфейс будет огромен.
Там подобных вещей больше половины интерфейса. Значительное количество функциональности из оставшейся части должна быть сделана делегацией вызовов другим классам. В общем, огромного интерфейса, приводящего к объемному классу реализации в данном случае (при нормальном дизайне) не наблюдается.
> ПК> Если же это фасад (что может быть оправданием такому ужасу), то тогда и говорить не о чем: полный код будет немногим больше, чем список членов. В общем, непоказательный пример.
> Ясно. Как всегда все вокруг криворукие. А грамотный дизайн — это то что делаешь сам.
Правильно ли я тебя понял, что ты считаешь приведенный интерфейс примером грамотного дизайна?
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Там подобных вещей больше половины интерфейса. Значительное количество функциональности из оставшейся части должна быть сделана делегацией вызовов другим классам. В общем, огромного интерфейса, приводящего к объемному классу реализации в данном случае (при нормальном дизайне) не наблюдается.
Ну, что же. Видимо ты лчше все остальных знашь как делать правильно. Но на этой планете есть еще смертные которые не смогут засунуть слона в спичечный копробок. И для таких людей (и для меня) возможность помещать один класс в отедьные файлы очень кстати. Благо никаких вредных побочных эффектов от этого не наблюдается.
В общем, будем радоваться хотя бы тому, что мы не спорим о том нужно ли пихать в один файл 20 пухлых файлов или нет.
ПК>Правильно ли я тебя понял, что ты считаешь приведенный интерфейс примером грамотного дизайна?
Не правильно. Мне просто плевать на этот интерфейс. Я ткнул пальцем в небо (выбрал первое попавшееся под руку более менее большое приложение) и попал в Ворд. Точно так же можно ткнуть в любой коммерческий грид или еще во что нибудь.
Мой посыл был в том, что всегда найдется задача требующая огромного (ну, относительно) класса. Опять таки всегда можно извернуться и попытаться обойти это требование. Но проще иметь банальные средства разбиения на файлы большой сущьности. Это не частое явление, но все же иногда от этого не уйти.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>А кто спорит с полезностью разнесения классов по файлам вообще? VD>>Мне показалось, что ты. Я ошибся? ГВ>Да, ошибся.
Тогда нам не очем спорить. Предлагаю заройтись.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И пользователь твоих классов будет вынужден ссылаться на все эти сокращения только потому что тебе было влом разнести классы по файлам?
C>Компилируется в набор файлов весом 5Мб
Во-во. А фрэймворк в сжатом вид 20 мег. Прикинь насколько у него длинее...
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
