Обычно в проекте создают папку "Types" и помещают туда описание всех пользовательских типов данных, основанных на структурах и перечислениях (т.е. значимые типы). При желании, если типов много, их распихивают по файлам - в каждом файле группа "однотипных" типов.
Что касается классов, то обычно для каждого класса выделяют отдельный файл, даже если он (класс) содержит свойства чего-то, т.е. по смыслу ближе к типам, чем к объектам... 
Это формальное (синтаксическое) разделение типов.

Если подойти к вопросу с позиций предметной области, то правильнее будет другое оформление по каталогам значимых типов и классов - скажем, в папке Types могут лежать как значимые типы, так и классы, которые по смыслу выполняют роль типов. Но в этом случае возникает проблема неодинаковой обработки этих структур (среди которых имеются структуры только со значимыми типами в качестве полей, так и структуры с сылочными значениями полей), поскольку при работе со структурами более приемлемо поверхностное копирование, а при наличии в труктуре ссылочных типов приходится вызывать методы типа Clone() или DeepClone(). А это уже смахивает на классы...

Кто что думает по этому вопросу ?  Кто как делает ?
И придерживается ли кто-нибудь следующего критерия: если некоторая сущность (в абстрактном понимании) содержит ссылочные поля, то эту сущность следует оформлять как класс.

2 вопроса для рассмотрения:
1. Раскидывание по каталогам классов, выполняющих роль типов, и значимых типов и структур.
2. В каком виде оформлять сущности (в абстрактном понимании), выполняющие роль типов (некоторых свойств), а не объектов (в абстрактном понимании) - в виде классов или структур ?

1 - раскидывают по каталогам - кому как нравиться. 
вообще я придерживаюсь подхода с простанствами имен.
есть пристранство - в нем группа классов, структур, делегатов, событий...
если их мало(<10) все храняться в корне.
если много, то создаются соответсвующие каталоги.
причем в каждой папке(namespaсe) каталоги могут иметь предметную окрашенность - не только типы или классы,
а шарики, фонарики, бантики и т.д.
хотя сами они могут содержаться в папке Классы или Структуры.

отсюда вывод:
а) проект - отдельная папка
б) в ней папки пространств имен (),
в) в каждом пространстве папки: Классы, Структуры, События, Делегаты ...
г) в каждой из них конкретные: Шарики, Фонарики...

2 - если в структуре находятся ссылочные данные - это (моё мнение) неправильное проектирование.
Как известно в стек кладутся только те структуры, размер которых не превышает определенного размера (16 байт?)
т.е. если структура занимает больше - она в куче, она ссылка 
массив intов -тоже  ссылка

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


P.S. это только моё мнение

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


Скажем, имеется структура, характеризующая параметры (свойства) рисования на объекте Graphics. В качестве полей: цвет фона, размер страницы (SizeF), цвет границы страницы, объект Pen, которым происходит рисование. Среди этих свойств (которые по смыслу - свойства) имеется один ссылочный объект - Pen, который также характеризует свойство. В данном случае вышеизложенное правило будет основано прежде всего на формальных позициях (внутреннее представление некоторых сущностей), нежели на "смысловых". Cкажем, SizeOf теоретически тоже можно было бы представить в виде ссылочного объекта, а Pen - в виде структуры...

Добавлено через 2 минуты и 27 секунд
Т.е. возникает проблема противоречия между формальной (с позиций внутреннего представления) стороной и семантической (с позиций предметной области)...

Добавлено через 3 минуты и 33 секунды
... причём как в отношении выбора структур/классов, так и и в отношении их группировки по каталогам...

НЕТ конечно. просто лежать будет она не в стеке.

на сечет второго...
в структуре всё-равно используют ссылки - организовать очередь, дерево или еще че нить.
просто ссылка - это ссылка, а значение - это значение.
и никак ты их вместе не сведешь!


на сечет всего остального
если физически структура больше крайнего размера, какой смысл делать её?
надо использовать класс.

ИМХО, ты изначально неправильно подходишь к проблеме.
Про подход, который требует класть все структуры и классы, исполняющие роль структур данных, в отдельную папку, я вообще впервые слышу. А тем более неразумно ещё и рассуждать о том, как эти структуры умещаются в памяти и на основании этого делать какие-то выводы. Какое это имеет значение  ?
Разделение кода на "типы данных" и обычные классы неправильно; гораздо логичнее разделить приложение по разным на логические уровни (GUI, бизнес-логика, БД) и соответственно разделить эти "типы данных": например, структуру DBRecord -- в папку DB, RecordInfo -- в папку BusinessLogic и т.п

Это сообщение отредактировал(а) Exception - 28.6.2007, 11:41

А как насчёт распределения по файлам классов и структур ?  В одном файле могут быть одновременно и классы, и структуры, и перечисления или каждый класс - в отдельный файл ?

я разделяю 
логические уровни - для каждого уровня - свой namespace
физически - для каждого логически самостоятельного класса (структуры) - отдельный файл.

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

Смысл такого разделения: разделение работы между девелоперами. Девелопер должен быть в состоянии залочить файл с классом на себя и работать с ним (тестить, апгрейдить) автономно. Если подчиненные только тестируемому классу типы лежат в отдельных файлах и никому, кроме тестируемого типа, понадобиться не могут - то какой смысл их в отдельный файл класть? 

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

Обсуждение откладывается на месяц... (вышел в отпуск... серфингу - ура...)