Где «найти» C # структуры?/ Как организовать структуры в проекте

Question

Я пытаюсь понять, каково соглашение о размещении структур C # и / или C ++ в проекте.В его собственном исходном файле?Если да, есть ли какие-то соглашения, которым я должен следовать по привычке?

В первый год соглашения в действительности не обсуждались, но, как правило, мы «прикрепляли» структуру везде, где она использовалась или «чувствуется "наиболее актуальным ...

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

Answer 1

В C ++, если структура «принадлежит» определенному классу или интерфейсу или тому подобному, я предпочитаю объявлять ее как внутренний тип тому, кому она принадлежит.Если структура является общим протоколом, который используют многие разные классы, я помещаю его в свой собственный файл .h.Если структура является одним из связанных наборов структур с малым числом элементов, то я создаю пространство имен для таких вещей и объявляю все структуры в одном файле .h, который предоставляет это пространство имен.

В C # я бы, вероятно,сделать эквивалент как в C ++.

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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