Здравствуйте, Геннадий Васильев, Вы писали:

VD>>Так соедени их в одну и не мучайся. Хотя с плюсами конечно в данном вопросе не все ОК.

ГВ>Выделенное — дорога в ад. Можешь поверить. Такая широкая-широкая. Причин много, потому озвучу основную — неправомерная агрегация сущностей.

Звучит красиво... Но требует расшифровки.

ГВ>Простейший пример — вносим изменения в набор логически связанных классов. Мотаться по файлам туда-сюда, ИМХО, не так удобно, как пройтись по одному файлу, тем паче, что в той же VS2003 есть очень удобная возможность на время сколлапсировать лишние строки.

Плохой пример. Как раз заниматься рефакторингом нескольких мелких файлов куда проще чем возиться с монстром. Основное время тратится на нахождение нужного места и анализ кода. Свертка кода вещь полезная, но у всего есть свои приделы. При привышении некоторого размера файла навигация по нему превращатся в ад.

Ну, и для рефакторинга лучшеп пользоваться средствами вроде Решарпера.

VD>> Я вижу ровно обратное. Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них.

ГВ>Забавный пример неправомерного обобщения.

Скорее очередное наклеивание ярлыков... с твоей стороны.

ГВ> В принципе, я совершенно согласен, что "Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них" но ведь из этого никак не следует, что в каждом файле лежит ровно один класс, верно?

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

ГВ> Эх, демагогия...

Да, уж любиш ты к ней прибегать. Тут не поспоришь.

ГВ>Зато когда классы разложены группами по файлам, очень удобно "отгонять" части проекта для того, чтобы с ними поиграться — добавить функциональность, переделать что-то и т.п. Опять таки, комментарии, если они относятся к группе классов, удобно размещать в таких файлах и использовать для автогенерирования документации.

К сожалению я не знаком с техникой "отгона" (или правильнее "отгоняния"?) частей проекта. Но проблем с управлением проектом или эксперемениами я почему-то не испытываю. А вот пролистывание огромных файлов в поисках нужной функции и чтение коментариев только чтобы найти нужный участок кода меня не водушивляет.

ГВ>Я сознательно поставил многоточия между фигурных скобок. Специализации могут быть и объёмными.

Тогда засовывать их в один файл не рзумно.

VD>> Но это уже плюсовые тараканы.

ГВ>Или — шарповые недоработки.

Тебе виднее.

ГВ>Про typedef-ы мы тут вроде, речи не вели. Я специально предложил специализации классов, посколкьу результат специализации — суть новый класс,

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

ГВ> и если следовать постулату "один класс — один файл", то их нужно раскидывать по вороху отдельных файлов. Если же мы вводим дополнительные оганичения, типа "если класс больше 3-х строк", то автоматически получаем понятие "логических групп", поскольку как ни крути, а куда-то такие классы всё равно класть нужно. И не факт, что специализации нужно помещать в один файл с исходным шаблоном.

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

Если не брать в рассчет тараканы плюсов, то "один класс — один файл" очень даже разумная стратегия. Даже если весь класс помещается на одном экране все равно удобнее будет получить к нему доступ просто открыв файл. А ведь есть еще системы контроля версий в которых разные навигации не работают и хранение классов в отдельных файлах существенно упрощает жизнь.

ГВ>Короче говоря, политика "один класс — один файл" применима далеко не всегда и не везде из-за того, что для группы файлов и одного файла отличаются:

ГВ>- способы навигации в редакторах (кстати, на MSVS свет клином не сошёлся);
Согласен. Есть еще такие хиты как Инея и т.п.

ГВ>- способы обработки разными тулзами (сравнения, генерация документаций и т.п., вполть до makefile-ов);

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

ГВ>- способы управления (переносы, копирования, архивирование).

Ясно. Мы живем в разных мирах. Я пользуюсь системой контроля вресий вроде SVN-а для управления исходниками. MSBuild-ом для сборки проектов. И студией 2005 или на худой конец 2003 + решарпер, чтобы редактировать код. Плюс плюсы для меня в прошлом и их тараканы меня больше не волнуют.

ГВ>Вот когда эти различия будут стёрты, вопрос отпадёт сам собой.

Все это ты сам для себя придумл чтобы опрадать свою точку зрения. Ни одна из перечисленных тобой проблем меня не трогает. А вот качество структурированности кода меня трогает очень сильно. Я люблю программировать быстро. И ненавижу все что этому мешает. Засовывание кучи классов в один файл мешает этому в первую очередь.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вообще-то, основная проблема обычно не в поиске метода, а в том что с ним делать.

Ну, у каждого свои проблемы.

VD>>В С++ часто прибегают к напихиванию классов в один файл из-за банальной медленности компиляции.

ГВ>Чушь. Э... Не соответствует действительности.

Ну, с такими аргументами не поспоришь.

ГВ> Основная причина — различия в работе с одним и несколькими файлами в текстовом редакторе.

И что прыганье по туче мест в одном файле проще чем выбрать в дереве проекта нужный файл-класс?

VD>>А уж говорить серьезно о навигации по логической структуре большого и сложного С++-проекта вовсе не приходится. Все виденные мной средства навигации обычно ломаются уже на средних проектах. Этот язык банально слишком сложен для разбора в рельном времени.

ГВ>Дык. Из этого следует, как минимм то, что а) на C++ нельзя слепо переносить практики C# и б) средства навигации ещё не доросли до возможностей C++.


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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Имхо, большой интерфейс — в большинстве случаев следствие плохого дизайна.

Как я уже говорил, бывает и так. Но бывает, что этого требует логика создаваемого ПО. Ради хохмы открой ворд, нажми Alt+F11 и погляди список членов документа ворда. Все они должны быть как минимум описаны в одном классе. А многие потребуют еще энного количества скрытых членов для реализации и т.п. В итоге интерфейс некоторого компонента может быть очень и очень большим.

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

VladD2,

> ПК> Имхо, большой интерфейс — в большинстве случаев следствие плохого дизайна.

> Как я уже говорил, бывает и так. Но бывает, что этого требует логика создаваемого ПО. Ради хохмы открой ворд, нажми Alt+F11 и погляди список членов документа ворда.

Посмотрел. Типичный пример "жирного" интерфейса. Скорее всего, обусловлен историческими или еще какими-то подобными причинами, но уж никак не может быть образцом хорошего дизайна. Начал было расписывать явные "ляпы", но решил не тратить время: там все без очков видно. Одно напихивание в этот и без того раздутый интерфейс функциональности, связанной с e-mail чего стоит... Если же это фасад (что может быть оправданием такому ужасу), то тогда и говорить не о чем: полный код будет немногим больше, чем список членов. В общем, непоказательный пример.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Посмотрел. Типичный пример "жирного" интерфейса. Скорее всего, обусловлен историческими или еще какими-то подобными причинами, но уж никак не может быть образцом хорошего дизайна. Начал было расписывать явные "ляпы", но решил не тратить время: там все без очков видно. Одно напихивание в этот и без того раздутый интерфейс функциональности, связанной с e-mail чего стоит...

Можешь подобные вещи просто не брать врассчет. И без того интерфейс будет огромен.

ПК>Если же это фасад (что может быть оправданием такому ужасу), то тогда и говорить не о чем: полный код будет немногим больше, чем список членов. В общем, непоказательный пример.

Ясно. Как всегда все вокруг криворукие. А грамотный дизайн — это то что делаешь сам.

Здравствуйте, VladD2, Вы писали:

VD>>>Так соедени их в одну и не мучайся. Хотя с плюсами конечно в данном вопросе не все ОК.
ГВ>>Выделенное — дорога в ад. Можешь поверить. Такая широкая-широкая. Причин много, потому озвучу основную — неправомерная агрегация сущностей.
VD>Звучит красиво... Но требует расшифровки.

Классы программы образуют её логическую структуру. Файлы с исходным кодом — файловую (или "физическую") структуру.

Для чего нужны классы? Для того, чтобы структурировать представление о предметной области. Для чего нужны файлы? Для того, чтобы это представление было удобно модифицировать одному или нескольким людям. "Удобство" означает и примлемую навигацию, и трансляцию, и check-in/out и т.п.

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

Только тихо, тихо. Я в курсе, что в Java, например, такой бардак отродясь. Сути дела в общем это не меняет.

ГВ>>Простейший пример — вносим изменения в набор логически связанных классов. Мотаться по файлам туда-сюда, ИМХО, не так удобно, как пройтись по одному файлу, тем паче, что в той же VS2003 есть очень удобная возможность на время сколлапсировать лишние строки.
VD>Плохой пример. Как раз заниматься рефакторингом нескольких мелких файлов куда проще чем возиться с монстром. Основное время тратится на нахождение нужного места и анализ кода. Свертка кода вещь полезная, но у всего есть свои приделы. При привышении некоторого размера файла навигация по нему превращатся в ад.

Да, всё верно. Если не забывать про ключевой момент: "При привышении некоторого размера". И это справедливо для любых файлов. Другое ограничение можно сформулировать так: "при превышении некоторого количества файлов"... Окончание то же, что и у тебя. Разница в том, что в первом случае (n классов на один файл) второе ограничение будет нарушаться реже, чем во втором. Ты же предлагаешь модификацию 10-12 классов автоматом "превращать в ад", поскольку решарпер помогает далеко не всегда.

VD> Ну, и для рефакторинга лучшеп пользоваться средствами вроде Решарпера.

Он не всегда помогает.

VD>>> Я вижу ровно обратное. Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них.
ГВ>>Забавный пример неправомерного обобщения.
VD>Скорее очередное наклеивание ярлыков... с твоей стороны.

Чуть ниже я расшифровал, почему употребил определение "неправомерное обобщение". Странно, что ты называешь подобный термин "ярлыком".

ГВ>> В принципе, я совершенно согласен, что "Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них" но ведь из этого никак не следует, что в каждом файле лежит ровно один класс, верно?
VD>Не верно. Файл даже с двумя более менее серьезными классами в принципе не может быть маленьким и простым.

А вот тут давай поподробнее. С чего ты взял, что "серьёзные классы", размер которых приводит к "аду" в навигации по его телу вообще должны быть? Моё и, кстати, не только моё мнение по этому поводу сводится к тому, что большие классы нужно рубить на куски. Чем раньше, тем лучше. В противном случае получаем суровую ошибку проектирования. Разумеется, это не относится к классам-API типа какого-нибудь навороченного интерфейса IMyCoolSoftware о двухстах методах, поскольку такие классы как правило содержат очень простой шлюзовой код и ничего более.

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

Правильно, этот паттерн на само проектирование не влияет. Только давай не путать файлы-монстры и классы-монстры. И потом, почему ты сбрасываешь со счетов обыкновенный здравый смысл? По твоему получается, что если не декларировано использование паттерна ОФОК, то естественное следствие — высокая вероятность получения файлов-монстров. Странная какая-то зависимость.

ГВ>>Зато когда классы разложены группами по файлам, очень удобно "отгонять" части проекта для того, чтобы с ними поиграться — добавить функциональность, переделать что-то и т.п. Опять таки, комментарии, если они относятся к группе классов, удобно размещать в таких файлах и использовать для автогенерирования документации.
VD>К сожалению я не знаком с техникой "отгона" (или правильнее "отгоняния"?) частей проекта. Но проблем с управлением проектом или эксперемениами я почему-то не испытываю. А вот пролистывание огромных файлов в поисках нужной функции и чтение коментариев только чтобы найти нужный участок кода меня не водушивляет.

Копируем X файлов из каталогов проекта в отдельный каталог и начинаем "баловацца вафсю"! Если что-то дельное получается — копируем файлы обратно.

ГВ>>Я сознательно поставил многоточия между фигурных скобок. Специализации могут быть и объёмными.
VD>Тогда засовывать их в один файл не рзумно.

Угу. И получить примерно... эдак... с полтора десятка новых файлов на совершенно ровном месте, только потому, что паттерн "ОФОК" так повелел?

ГВ>>Про typedef-ы мы тут вроде, речи не вели. Я специально предложил специализации классов, посколкьу результат специализации — суть новый класс,
VD>Вообще-то специализации новых классов не порождают.

Согласен, поскольку действительно, специализация (частичная) — ещё не класс. Но тем не менее, в контексте обсуждения организации исходного кода вполне правомерно утверждение "специализация шаблона = класс", равно как и "шаблон = класс". Просто я полагал это по умолчанию.

VD>Или тогда нужно говорить, о том, что любое применение шаблона с новым типом параметра порождает новый класс. (что мягко говоря натянуто).

Ну, вообще-то, мы об организации исходников говорим. А в этом контексте, повторюсь, что классы, что структуры, что шаблоны, что специализации (полные и частичные) шаблонов — одно и то же.

ГВ>> и если следовать постулату "один класс — один файл", то их нужно раскидывать по вороху отдельных файлов. Если же мы вводим дополнительные оганичения, типа "если класс больше 3-х строк", то автоматически получаем понятие "логических групп", поскольку как ни крути, а куда-то такие классы всё равно класть нужно. И не факт, что специализации нужно помещать в один файл с исходным шаблоном.
VD>Мне кажется, что выделенное жирным довольно разумно.

Да, совершенно верно. Но только в некоторых случаях. В некоторых — нет. Например, библиотечный шаблон T может специализироваться классом X, определяемым в некотором модуле Z системы. Если мы положим специализацию T<X> в ту же единицу трансляции, что и сам T, то туда же придётся затолкнуть и сам класс X и ещё неизвестно что из модуля Z. В итоге получим концентрацию всякого барахла в библиотечном модуле. Кашу, короче говоря, получим. Так что, рецепт работает не всегда. Но вот специализации фундаментальными и какими-то well-known типами как правило вполне можно положить вместе с библиотечным шаблоном.

VD>Но опять таки — это специфика плюсов отсутствующая во многих других языках.

Согласен, но это означает, что паттерн "ОФОК" не всегда работоспособен. Как минимум, для C++.

VD>И уж точно это не является разумным оправданием для запихивания в один файл груды полноценных классов.

Depends on, как я это только что показал. Потом, с чего ты решил, что шаблон = неполноценный класс? Давай уж определимся с терминами. Пока что, "полноценный класс" в твоей интерпретации выглядит как чудовище-монстр аццких габаритофф, который и в один-то файл положить страшно, тогда как я уверен, что за подобные классы нужно отлучать от программирования. Это, кстати, можешь считать комментарием к твоему исходному тезису о "классности программистов".

VD>Если не брать в рассчет тараканы плюсов, то "один класс — один файл" очень даже разумная стратегия.

Здесь не в "плюсах" проблема, а в размерах и количестве классов. Даже на Java применение ОФОК нехило треплет нервы время от времени — когда нужно мотаться по груде файлов вместо того, чтобы расставить закладки по одному файлу и спокойно по нему прыгать. То есть, абсолютизация этой стратегии имеет и негативные стороны.

VD>Даже если весь класс помещается на одном экране все равно удобнее будет получить к нему доступ просто открыв файл. А ведь есть еще системы контрол версий в которых разные навигации не работают и хранение классов в отдельных файлах существенно упрощает жизнь.

Опять в одной куче розы и паровозы. А почему? А потому что на "зы"!

С одной стороны — да, разбиение проекта на отдельные файлы упрощает жизнь (обрати внимание на формулировку), а вот максималистическое применение ОФОК как раз жизнь усложнит.

ГВ>>- способы обработки разными тулзами (сравнения, генерация документаций и т.п., вполть до makefile-ов);
VD>Если "тулзы" не кривые, то никакой необходимости засовывать все в один файл нет. Мэйки вообще пережиток прошлого (хотя тоже не ясно как он может повлиять на организацию файлов).

Хорошо, скажем по-другому. Если мы что-то пытаемся оттранслировать в пакетном режиме, то раскидывая классы по отдельным файлам в соответствии с паттерном ОФОК существенно чаще будем заставлять сами себя править пакетное задание. Само по себе это ни на что сильно не влияет, но факт отличий остаётся.

ГВ>>- способы управления (переносы, копирования, архивирование).
VD>Ясно. Мы живем в разных мирах. Я пользуюсь системой контроля вресий вроде SVN-а для управления исходниками. MSBuild-ом для сборки проектов. И студией 2005 или на худой конец 2003 + решарпер, чтобы редактировать код. Плюс плюсы для меня в прошлом и их тараканы меня больше не волнуют.

Мда. Только ты тогда не забывай проставлять теги ".Net/C# world only on/off", а то в заблуждение вводишь. Тогда бы я и не спорил.

ГВ>>Вот когда эти различия будут стёрты, вопрос отпадёт сам собой.
VD>Все это ты сам для себя придумл чтобы опрадать свою точку зрения. Ни одна из перечисленных тобой проблем меня не трогает.

И эти люди запрещают мне ков... тьфу, обвиняют меня в демагогии.

VD>А вот качество структурированности кода меня трогает очень сильно. Я люблю программировать быстро. И ненавижу все что этому мешает. Засовывание кучи классов в один файл мешает этому в первую очередь.

Ну вот, оказывается, где ключи-то к мастерству и быстрому программированию! Раскидать каждый класс в отдельный файл и — полный вперёд! Делов-то!

Самому не смешно? Или это ты в приёмах составления рекламных слоганов практикуешься?

Здравствуйте, VladD2, Вы писали:

ГВ>> Основная причина — различия в работе с одним и несколькими файлами в текстовом редакторе.
VD>И что прыганье по туче мест в одном файле проще чем выбрать в дереве проекта нужный файл-класс?

Чёй-то я не понимаю противопоставления. Тут уж или "выбрать несколько файлов", или вообще никакого противопоставления нет.

VD>>>А уж говорить серьезно о навигации по логической структуре большого и сложного С++-проекта вовсе не приходится. Все виденные мной средства навигации обычно ломаются уже на средних проектах. Этот язык банально слишком сложен для разбора в рельном времени.
ГВ>>Дык. Из этого следует, как минимм то, что а) на C++ нельзя слепо переносить практики C# и б) средства навигации ещё не доросли до возможностей C++.
VD>Нет. Из этого следует, что для С++ (если бы не тормоза при компиляции и проблему необходимости предварительной декларации) в первую очередь полезно разносить классы по отдельным файлам.

А кто спорит с полезностью разнесения классов по файлам вообще? Я как раз оспариваю постулат, что "один класс = один файл".

VD>Ну, и то что чем бороться с проблемами старичка проще на него забить.

Ну это-то подразумевается тобой почти в каждом посте в "философии", я уж даже удивляться перестал. Другое дело, что основания для такого твоего вывода выглядят всё более зыбкими...

Здравствуйте, VladD2, Вы писали:

ПК>>Если же это фасад (что может быть оправданием такому ужасу), то тогда и говорить не о чем: полный код будет немногим больше, чем список членов. В общем, непоказательный пример.

VD>Ясно. Как всегда все вокруг криворукие. А грамотный дизайн — это то что делаешь сам.

Просто не стоит принимать структуру интерфейса за внутреннюю структуру программы. Это, извини меня, азы.

VladD2 wrote:

> C>Не совсем удобно получается, папки повторяют "тонкую" структуру проекта
> C>и по ним неудобно становится ходить.
> Зависит от разумности формирования проекта. Что такое "тонкая
> структура" я не знаю. Если интересно могу привести структуры проектов
> с которыми я работаю.

Тонкая == fine-grained. Просто при работе с папками из FAR'а не очень
удобно, когда вложенность очень глубокая.

> C>Удобно иметь два метода навигации: по логической структуре
> C>(namespace/package и по классам) и по физической (каталоги/файлы).
> Логической навигации никто не отменял. Вот только при хорошей
> организации проекта обычно проще просто ткнуть в нужный файл (если
> конечно ты не стоишь на идентификаторе по которму можно прыгнуть на
> его определение).

Ну а чем это отличается от выбора вместо вкладки с файлами выбрать
вкладку с логической структурой?

> C>В С++ поэтому удобно группировать схожие классы в один файл — типа
> C>allocators.h в котором лежат shared_allocator, locked_allocator,
> C>st_allocator.
> Ничего удобного тут нет. Искать код в 10 классах по поределению
> труднее чем в одном. Если классы занимают пару строк, то еще куда не
> шло. А для полноценных классов каждый из которых занимает по 40 и
> более строк такое решение приведет к тому, что на поиск конкретного
> метода буде уходить по куча времени.

Семантический поиск спасет отца советской демократии.

С другой стороны, когда файлов очень много — так же сложно найти НУЖНЫЙ
файл.

> В С++ часто прибегают к напихиванию классов в один файл из-за
> банальной медленности компиляции. А уж говорить серьезно о навигации
> по логической структуре большого и сложного С++-проекта вовсе не
> приходится. Все виденные мной средства навигации обычно ломаются уже
> на средних проектах. Этот язык банально слишком сложен для разбора в
> рельном времени.

VisualAssist справляется. Не в 100% случаях (сбоит пару раз в час), но
вполне нормально. Стандартный "Go to definition" тоже работает нормально.

Кстати, есть еще "инсайдерская" информация — одна контора пишет
realtime-парсер для С++ на основе gccxml. Будет под лицензией GPL, и
скорее всего, сразу будет добавлен в KDevelop.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, VladD2, Вы писали:

VD>Про папки слышал? Вот ими и отражай свою логическую структуру.

В приведенном мной примере 4 группы. В них по 3-4 класса всего. А в последней группе — всего 1 класс. Если так мелко делать папки, то... . Это во-первых.

Во-вторых, возмем первую группу — ексепшены:

public class CompileException {}
public class SomeSpecificException : CompileException {}
public class OtherSpecificException : CompileException {}

Ну запихаю я ее в одну папку. Ну и что? Видеть то я их буду отсортированными по алфавиту, а мне надо — по иерархии наследования. Чтобы я мог быстро определить базовый класс для всех ексепшенов и т.п. (Правда данный пример неудачный, и эти две сортировки совпадают, но все же).

Здравствуйте, Erxud, Вы писали:

E>Глядя на весь этот флейм, понимаешь, как все-таки правы были авторы Java

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

С другой стороны, WinAPI, VCL, Mono, JNI, OCI, OCCI (C++ интерфейс к Oracle) сделаны большими исходниками.

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Чушь. Э... Не соответствует действительности. Основная причина — различия в работе с одним и несколькими файлами в текстовом редакторе.

И еще, потому что в каждом мелком файле надо писать одни и теже инклуды, неймспейсы и юзинги.

Здравствуйте, Cyberax, Вы писали:

C>Это в одном файле. В С++ я могу делать так:

class A;
boost::shared_ptr<A> A_ptr;
struct B
{
    A_ptr field;
};

C>При этом я могу структуру B использовать без всякого знания о
C>внутренностях класса A (кроме знания о самом его существовании). При
C>этом этот класс может быть определен в любой единице компиляции.

1) Вообще-то, тут используется указатель на класс А, а не он сам.
2) Единица компиляции — слишком громко сказано, тут это — в смысле компилируется в объектный фал, который сам по себе ничего не представляет.

А слабо использовать сам класс, а не указатель на него?
А слабо скомпилировать в динамически загружаемый исполняемый модуль (DLL)?

Здравствуйте, stalcer, Вы писали:

СГ>>

СГ>>...то типы "А" и "Б" должны быть описаны в одном модуле....

S>Опять же, зависит от языка. В моем DSL и это необязательно .

Значит он не модульный.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Значит он не модульный.

Он позволяет путем одновременной компиляции нескольких модулей делать циклические зависимости между ними. В результате компиляции все равно получается несколько модулей.

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

В Java же тоже самое. Классы (эээ, типа маленькие модули компиляции) могут ссылаться друг на друга как угодно.

Здравствуйте, VladD2, Вы писали:

СГ>>В смысле, теперь один класс можно будет размазать по нескольким файлам?
VD>Да.
СГ>>Ёёёёёёёёёёёёёёёёёё
VD>Сам такой. Это чертовски удобно.

Чертовски удобно, это как? В смысле, удобно для чертей? Да я не сомневаюсь, что это воистину дьявольская штукенция. Как бы только сам черт теперь там ногу не свернул....

Сергей Губанов wrote:

> C>При этом я могу структуру B использовать без всякого знания о
> C>внутренностях класса A (кроме знания о самом его существовании). При
> C>этом этот класс может быть определен в любой единице компиляции.
> 1) Вообще-то, тут используется указатель на класс А, а не он сам.
> 2) Единица компиляции — слишком громко сказано, тут это — в смысле
> компилируется в объектный фал, который сам по себе ничего не представляет.

То есть "не представляет"?

> А слабо использовать сам класс, а не указатель на него?

Да запросто:

class A;
class B
{
    A* field;
    void method1();
};
class A
{
    B *field;
    void method2();
};

void A::method1()
{
    field=new B();
}

> А слабо скомпилировать в динамически загружаемый исполняемый модуль (DLL)?

Не слабо. См. boost.plugin — динамическая подгрузка плугинов на С++.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

>> А слабо использовать сам класс, а не указатель на него?

C>Да запросто:
C>

C>class A;
C>class B
C>{
C>    A* field;
C>    void method1();
C>};
C>class A
C>{
C>    B *field;
C>    void method2();
C>};

C>void A::method1()
C>{
C>    field=new B();
C>}
C>

Ёёёооууу, а звездочка "*" — это разьве не указатель?
Вооще-то, ни кто не может использовать сам класс (а не указатель) не зная о нем ничего. Ведь как ни крути, но размер-то его объектов хотя бы знать-то надо...

>> А слабо скомпилировать в динамически загружаемый исполняемый модуль (DLL)?

C>Не слабо. См. boost.plugin — динамическая подгрузка плугинов на С++.

Еще раз ёёёооууу!!!! Вооще-то, ни кто не может скомпилировать в исполняемый модуль то что он сам не знает.
Нельзя получить исполняемый модуль имея всего-лишь такой исходный код:

  class A;

и не имея при этом определения того, что же есть это "А".
Unresolved external symbol однако...

Здравствуйте, stalcer, Вы писали:

S>Он позволяет путем одновременной компиляции нескольких модулей делать циклические зависимости между ними. В результате компиляции все равно получается несколько модулей.
S>Это упрощение сделано для прикладных программистов, чтобы не парить им мозги необходимостью правильного разбиения на модули, отслеживанием зависимостей и т.п.
S>В Java же тоже самое. Классы (эээ, типа маленькие модули компиляции) могут ссылаться друг на друга как угодно.

Так я и говорю не модульный. А то что Java классы — не модули и так известно. Те сущности, которые Вы называете словом "модуль", нуждаются в другом названии. Придумайте другое слово. Сипульки — например, а?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Классы программы образуют её логическую структуру. Файлы с исходным кодом — файловую (или "физическую") структуру.

ГВ>Для чего нужны классы? Для того, чтобы структурировать представление о предметной области.
Бесспорно.
ГВ>Для чего нужны файлы? Для того, чтобы это представление было удобно модифицировать одному или нескольким людям. "Удобство" означает и примлемую навигацию, и трансляцию, и check-in/out и т.п.
Согласен. Но "удобство" понятие субъективное. Лично мне удобнее когда файлы не большие.
А что касается check-in/check-out то нефиг пользоваться дурными версионниками типа VSS.

ГВ>Так вот, попытка привязать файловую структуру к логической по принципу 1:1 есть ни что иное, как связывание (агрегация) двух сущностей в одну: имени класса и имени файла в некое общее имя "классофайла". Такое связывание неправомерно, поскольку нарушается требование удобства доступа.
Если требования к структуре классов вещь довольно формальная то трубования к удобству субъективны.
Например в моей практике был случай когда мне пришлось разделить один класс на несколько файлов. Ибой искать конци в файле в несколько тысяч строк мне очень не понравилось.
Только не надо про кривизну дизайна. Нужно было реализовать в одном классе несколько здоровых COM интерфейсов которые придумал не я.

VD>> Ну, и для рефакторинга лучшеп пользоваться средствами вроде Решарпера.
ГВ>Он не всегда помогает.
Например?

ЗЫ Рекомендую завязывать с аффтарским сленгом. Здесь за это банят.