Здравствуйте, AndrewVK, Вы писали:
AVK>Более того — ограничение C# первой версии на размещение класса в одном файле во второй версии убрано совсем не зря.
Немного не в тему, но это ограничение снято на для удобства написания классов, а для удобства использования кодогенераторов (в том числе и form designer и ASP)
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, AndrewVK, Вы писали:
AVK> Более того — ограничение C# первой версии на размещение класса в одном файле во второй версии убрано совсем не зря.
В смысле, теперь один класс можно будет размазать по нескольким файлам? Ёёёёёёёёёёёёёёёёёё
Ок. Есть логический порядок следования классов в API некой подсистемы компиляции:
namespace compiler
{
public class CompileException {}
public class SomeSpecificException : CompileException {}
public class OtherSpecificException : CompileException {}
public interface ICompilationModuleCallbacks {}
public interface ICompilationModuleLoader {}
public interface ICompilationModuleManager {}
public class TypeDeclContext {}
public class MemberDeclContext {}
public class ExpressionCompContext {}
public class BodyCompContext {}
public class Compiler {}
}
Делаем для каждого класса отдельный файл и видим следующее:
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Я что-то не понял, какой проблемы?
S>Необходимости объявлять mutual-depended классы в одном исходнике.
Ну а в моем сообщении говорилось не об исходниках, а о модулях:
...то типы "А" и "Б" должны быть описаны в одном модуле....
Re[6]: Короткие или длинные исходинки - Модульный подход
Сергей Губанов wrote:
> C>А что, в Обероне нет опережающих описаний (forward declarations)? > Не понимаю, при чем тут Оберон, но если Вас это так сильно интересует, > то для описания типов циклически ссылающихся друг на друга > предварительные объявления не требуются: > >A = POINTER TO RECORD > b: B > END; > >B = POINTER TO RECORD > a: A > END; >
Это в одном файле. В С++ я могу делать так:
class A;
boost::shared_ptr<A> A_ptr;
struct B
{
A_ptr field;
};
При этом я могу структуру B использовать без всякого знания о
внутренностях класса A (кроме знания о самом его существовании). При
этом этот класс может быть определен в любой единице компиляции.
Здравствуйте, xvost, Вы писали:
X>Немного не в тему, но это ограничение снято на для удобства написания классов, а для удобства использования кодогенераторов (в том числе и form designer и ASP)
Это сделано и для того, и для другого. Например, я уже с удовольствием использую данную фичу для структуризации больших классов. Получается очень удобно. Отдельные функциональные куски лежат в отдельных файлах, что дает очень быстрый и простой доступ кним.
А что до дизайнеров, то они то как раз могут и в один и тот же файл писать.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
AVK>> Более того — ограничение C# первой версии на размещение класса в одном файле во второй версии убрано совсем не зря.
СГ>В смысле, теперь один класс можно будет размазать по нескольким файлам?
Да.
СГ>Ёёёёёёёёёёёёёёёёёё
Сам такой. Это чертовски удобно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, stalcer, Вы писали:
S>Здравствуйте, AndrewVK, Вы писали:
S>Ок. Есть логический порядок следования классов в API некой подсистемы компиляции:
Про папки слышал? Вот ими и отражай свою логическую структуру.
S>...И начинаем судорожно лазить по каталогу, заглядывая в каждый файл, для того, чтобы выделить логические группы.
Зачем? Есть дерево проекта в студии или каталоги на диске. Все что унжно находится просто по именам файлам и их пути внутри проекта.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote:
> S>Ок. Есть *логический* порядок следования классов в API некой > подсистемы компиляции: > Про папки слышал? Вот ими и отражай свою логическую структуру.
Не совсем удобно получается, папки повторяют "тонкую" структуру проекта
и по ним неудобно становится ходить.
> S>...И начинаем судорожно лазить по каталогу, заглядывая в каждый > файл, для того, чтобы выделить логические группы. > Зачем? Есть дерево проекта в студии или каталоги на диске. Все что > унжно находится просто по именам файлам и их пути внутри проекта.
Удобно иметь два метода навигации: по логической структуре
(namespace/package и по классам) и по физической (каталоги/файлы).
В С++ поэтому удобно группировать схожие классы в один файл — типа
allocators.h в котором лежат shared_allocator, locked_allocator,
st_allocator.
VladD2,
> я уже с удовольствием использую данную фичу для структуризации больших классов. Получается очень удобно. Отдельные функциональные куски лежат в отдельных файлах, что дает очень быстрый и простой доступ кним.
Почему-то мне кажется, что класс, который приходится разбивать по нескольким файлам из-за размера, просит рефакторинга. Если это приходится делать из-за слабой функциональной связности, то, на мой взгляд, класс уже не просит, а требует...
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, VladD2, Вы писали:
S>>Ок. Есть логический порядок следования классов в API некой подсистемы компиляции: VD>Про папки слышал? Вот ими и отражай свою логическую структуру.
Э... не надо путать логическую и физическую структуру. Это суть две разные вещи. И прежде всего по причинам сопровождабельности не всегда удобно раскидывать сущности по файлам по правилу "одна сущность = один файл".
S>>...И начинаем судорожно лазить по каталогу, заглядывая в каждый файл, для того, чтобы выделить логические группы. VD>Зачем? Есть дерево проекта в студии или каталоги на диске. Все что унжно находится просто по именам файлам и их пути внутри проекта.
OK. Имеем пачку частичных специализаций примерно такого вида:
// Специализируется только один методtemplate<typename X, typename Y, typename Z>
void Foo<X, Y, Z, int>::bar() {...}
template<typename X, typename Y, typename Z>
void Foo<X, Y, Z, double>::bar() {...}
// etc.
Дальше что? Пуляем каждую специализацию в отдельный файл? Как назовём файлы?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Почему-то мне кажется, что класс, который приходится разбивать по нескольким файлам из-за размера, просит рефакторинга. Если это приходится делать из-за слабой функциональной связности, то, на мой взгляд, класс уже не просит, а требует...
Бывает по разному. Бывает, что большой файл — это следствие плохого дизайна, а бывает что следствие большого интерфейса. Например, в текстовом редакторе куча функциональности помещается во View. При этом View становится довольно большим классом чтобы по нему было не удобно лазить. Разбиение его на части дает отличный результат. Например, вот разбиение на файлы View из редактора кода:
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote:
>> S>Ок. Есть *логический* порядок следования классов в API некой >> подсистемы компиляции: >> Про папки слышал? Вот ими и отражай свою логическую структуру.
C>Не совсем удобно получается, папки повторяют "тонкую" структуру проекта C>и по ним неудобно становится ходить.
Зависит от разумности формирования проекта. Что такое "тонкая структура" я не знаю. Если интересно могу привести структуры проектов с которыми я работаю.
C>Удобно иметь два метода навигации: по логической структуре C>(namespace/package и по классам) и по физической (каталоги/файлы).
Логической навигации никто не отменял. Вот только при хорошей организации проекта обычно проще просто ткнуть в нужный файл (если конечно ты не стоишь на идентификаторе по которму можно прыгнуть на его определение).
C>В С++ поэтому удобно группировать схожие классы в один файл — типа C>allocators.h в котором лежат shared_allocator, locked_allocator, C>st_allocator.
Ничего удобного тут нет. Искать код в 10 классах по поределению труднее чем в одном. Если классы занимают пару строк, то еще куда не шло. А для полноценных классов каждый из которых занимает по 40 и более строк такое решение приведет к тому, что на поиск конкретного метода буде уходить по куча времени. В С++ часто прибегают к напихиванию классов в один файл из-за банальной медленности компиляции. А уж говорить серьезно о навигации по логической структуре большого и сложного С++-проекта вовсе не приходится. Все виденные мной средства навигации обычно ломаются уже на средних проектах. Этот язык банально слишком сложен для разбора в рельном времени.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Э... не надо путать логическую и физическую структуру. Это суть две разные вещи.
Так соедени их в одну и не мучайся. Хотя с плюсами конечно в данном вопросе не все ОК.
ГВ>И прежде всего по причинам сопровождабельности не всегда удобно раскидывать сущности по файлам по правилу "одна сущность = один файл".
Озвучь причины... обсудим. Я вижу ровно обратное. Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них.
ГВ>OK. Имеем пачку частичных специализаций примерно такого вида:
ГВ>
ГВ>// Специализируется только один метод
ГВ>template<typename X, typename Y, typename Z>
ГВ>void Foo<X, Y, Z, int>::bar() {...}
ГВ>template<typename X, typename Y, typename Z>
ГВ>void Foo<X, Y, Z, double>::bar() {...}
ГВ>// etc.
ГВ>
ГВ>Дальше что? Пуляем каждую специализацию в отдельный файл? Как назовём файлы?
Если они умещаются в одну-три строки, то можно конечно и в одном файле оставить. Но это уже плюсовые тараканы. В Шарпе тоже есть одно исключение — делегаты. Они описываются в одну строку и конечно городить из-за делегата одтельный файл не разумно.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ГВ>>Э... не надо путать логическую и физическую структуру. Это суть две разные вещи. VD>Так соедени их в одну и не мучайся. Хотя с плюсами конечно в данном вопросе не все ОК.
Выделенное — дорога в ад. Можешь поверить. Такая широкая-широкая. Причин много, потому озвучу основную — неправомерная агрегация сущностей.
ГВ>>И прежде всего по причинам сопровождабельности не всегда удобно раскидывать сущности по файлам по правилу "одна сущность = один файл".
VD>Озвучь причины... обсудим.
Простейший пример — вносим изменения в набор логически связанных классов. Мотаться по файлам туда-сюда, ИМХО, не так удобно, как пройтись по одному файлу, тем паче, что в той же VS2003 есть очень удобная возможность на время сколлапсировать лишние строки.
VD> Я вижу ровно обратное. Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них.
Забавный пример неправомерного обобщения. В принципе, я совершенно согласен, что "Поддерживать хорошо структурированные небольшие файлы в кторых заранее известно что лежит намного проще чем шариться по файлам в поиске файлов и функций в них" но ведь из этого никак не следует, что в каждом файле лежит ровно один класс, верно? Эх, демагогия...
Зато когда классы разложены группами по файлам, очень удобно "отгонять" части проекта для того, чтобы с ними поиграться — добавить функциональность, переделать что-то и т.п. Опять таки, комментарии, если они относятся к группе классов, удобно размещать в таких файлах и использовать для автогенерирования документации.
ГВ>>OK. Имеем пачку частичных специализаций примерно такого вида:
[skip]
ГВ>>Дальше что? Пуляем каждую специализацию в отдельный файл? Как назовём файлы? VD>Если они умещаются в одну-три строки, то можно конечно и в одном файле оставить.
Я сознательно поставил многоточия между фигурных скобок. Специализации могут быть и объёмными.
VD> Но это уже плюсовые тараканы.
Или — шарповые недоработки.
VD>В Шарпе тоже есть одно исключение — делегаты. Они описываются в одну строку и конечно городить из-за делегата одтельный файл не разумно.
Про typedef-ы мы тут вроде, речи не вели. Я специально предложил специализации классов, посколкьу результат специализации — суть новый класс, и если следовать постулату "один класс — один файл", то их нужно раскидывать по вороху отдельных файлов. Если же мы вводим дополнительные оганичения, типа "если класс больше 3-х строк", то автоматически получаем понятие "логических групп", поскольку как ни крути, а куда-то такие классы всё равно класть нужно. И не факт, что специализации нужно помещать в один файл с исходным шаблоном.
Короче говоря, политика "один класс — один файл" применима далеко не всегда и не везде из-за того, что для группы файлов и одного файла отличаются:
— способы навигации в редакторах (кстати, на MSVS свет клином не сошёлся);
— способы обработки разными тулзами (сравнения, генерация документаций и т.п., вполть до makefile-ов);
— способы управления (переносы, копирования, архивирование).
Вот когда эти различия будут стёрты, вопрос отпадёт сам собой.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
C>>В С++ поэтому удобно группировать схожие классы в один файл — типа C>>allocators.h в котором лежат shared_allocator, locked_allocator, C>>st_allocator.
VD>Ничего удобного тут нет. Искать код в 10 классах по поределению труднее чем в одном. Если классы занимают пару строк, то еще куда не шло. А для полноценных классов каждый из которых занимает по 40 и более строк такое решение приведет к тому, что на поиск конкретного метода буде уходить по куча времени.
Вообще-то, основная проблема обычно не в поиске метода, а в том что с ним делать.
VD>В С++ часто прибегают к напихиванию классов в один файл из-за банальной медленности компиляции.
Чушь. Э... Не соответствует действительности. Основная причина — различия в работе с одним и несколькими файлами в текстовом редакторе.
VD>А уж говорить серьезно о навигации по логической структуре большого и сложного С++-проекта вовсе не приходится. Все виденные мной средства навигации обычно ломаются уже на средних проектах. Этот язык банально слишком сложен для разбора в рельном времени.
Дык. Из этого следует, как минимм то, что а) на C++ нельзя слепо переносить практики C# и б) средства навигации ещё не доросли до возможностей C++.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
.
Это чертовски удобно.
Эх, демагогия... 