Класс C# функционирует членское объявление и реализация

Нет, в C # нет концепции реализации и файлов заголовков, как в C / C ++. Ближе всего к этому можно подойти к использованию интерфейса, но интерфейс может определять только общедоступные члены вашего класса. Тогда вы получите сопоставление классов и интерфейсов один-к-одному, что на самом деле не является целью того, как интерфейсы должны использоваться.

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

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

Это действительно тот случай, когда нужно сделать шаг назад и увидеть более широкую картину. В Visual Studio есть много-много инструментов, которые помогут вам писать код и управлять им, начиная с выделения, # регионов, представления классов, диаграмм классов, окно определения кода и многое другое.

C # - это не C ++, если вы попытаетесь сделать это так, то споткнетесь о себя, и никто другой не сможет прочитать ваш код.

День, потраченный обучение использованию инструментов Visual Studio многократно окупит вложенные средства с точки зрения производительности, и вы скоро задаетесь вопросом, как вы когда-либо жили с этим способом работы на C ++.

Обновление в ответ на комментарии

У меня давно так как перестал рассматривать мой код как простые текстовые файлы. Я считаю код органичной вещью и считаю, что позволяя себе полагаться на многофункциональную среду IDE, я могу легче перемещаться вверх и вниз по уровням абстракции и бесконечно повышает мою продуктивность. Я полагаю, что это может быть личная черта, и, возможно, это не для всех; У меня очень "визуальный" ум, и я лучше всего работаю, когда вижу вещи на картинках.

Тем не менее, умная IDE - не оправдание плохому стилю. Есть лучшие методы написания «чистого кода», не требующего умной IDE. Один из принципов чистого кода - сохранить определение чего-либо рядом с его использованием, и я думаю, что это можно расширить, чтобы охватить декларацию и определение. Лично я считаю, что разделение объявления и определения делает код менее понятным. Если вы обнаружите, что у вас есть классы-монстры, которые трудно понять, то это может быть признаком того, что вы нарушаете принцип единой ответственности.

Причина отдельного определения и объявления в c / C ++ заключается в том, что C ++ использует однопроходный компилятор, в котором прямые ссылки не могут быть разрешены позже, в отличие от C # и его двухпроходного компилятора , который может легко находить ссылки независимо от порядка объявления. Это различие проистекает из различных философий проектирования компиляторов: C / C ++ считает каждый исходный файл единицей компиляции, тогда как в C # единицей компиляции считается весь проект. Я полагаю, когда вы привыкли работать в стиле C / C ++, тогда разделение объявления и определения может показаться желательным элементом стиля, но я лично считаю, что сохранение объявления и использования (или в данном случае объявления и определения) улучшает, а не снижает читабельность. Раньше я сам был программистом на C, пока не начал использовать C # в 2001 году. Я всегда любил C и думал, что это «пчелиные колени». Сейчас, когда я читаю код C / C ++, я думаю, что он выглядит ужасно, и не могу поверить, что мы привыкли работать таким образом. Все дело в том, к чему ты привык,

Похоже, вы имеете в виду интерфейсы . В C # вы можете определить все свои функции-члены в интерфейсе, а затем реализовать их в другом классе.

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

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

Но если подумать, если ваши классы сами становятся все более сложными по мере того, как вы пишете программу, возможно, это больше проблема дизайна, чем проблема языка? Я думаю, что класс должен иметь одну ответственность и не брать на себя все больше и больше обязанностей по мере роста программы; скорее, количество классов и количество используемых классов должны расти и становиться все более сложными по мере того, как вы продолжаете разрабатывать свое программное обеспечение?

Определить интерфейс.

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

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

C # не является C ++ и, вероятно, не должен рассматриваться как C ++.

Есть два способа исправить это, чтобы сделать его более похожим на C ++:

• Создайте файл интерфейса, который объявляет все сигнатуры и свойства методов.
• Реализуйте этот интерфейс в классе в нескольких файлах с использованием модификатора partial в определениях классов

Редактирование:

// File: ICppLikeInterface.cs
public interface ICppLikeInterface
{
    ...
}

// File: CppLikeImplementation1.cs    
public partial class CppLikeImplementation : ICppLikeInterface
{
    ...
}

// File: CppLikeImplementation2.cs    
public partial class CppLikeImplementation : ICppLikeInterface
{
    ...
}

Способ разделения интерфейса в файл заголовка в C ++ в основном (я думаю) связан с ранним дизайнерским решением, когда C был создан для разрешить быструю инкрементную компиляцию в «старые времена», поскольку компилятор отбрасывает любые метаданные, в отличие от Smalltalk. Это не относится к C # (или Java), где десятки тысяч строк компилируются за секунды на новейшем оборудовании (C ++ все еще этого не делает)

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

Когда это возможно или желательно, я использую предыдущие ответы и определяю интерфейс. но это не всегда уместно.

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