Возможно ли?
Попробовал как в плюсах, не помогло. В хелпе тоже ничего подобного не нашел.

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

V>Возможно ли?
V>Попробовал как в плюсах, не помогло. В хелпе тоже ничего подобного не нашел.

интерфейс?

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

V>Возможно ли?
V>Попробовал как в плюсах, не помогло. В хелпе тоже ничего подобного не нашел.

Используйте интерфейсы или абстрактные классы.

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

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

V>>Возможно ли?
V>>Попробовал как в плюсах, не помогло. В хелпе тоже ничего подобного не нашел.

AK>интерфейс?

Не понял, можно пример?
Допустим, как такую конструкцию перенести на CS:

class A
{
int B();
}

int A::B ()
{
return 232323;
}

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

V>Возможно ли?

Нет.

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

V>Здравствуйте, alexey.kostylev, Вы писали:

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

V>>>Возможно ли?
V>>>Попробовал как в плюсах, не помогло. В хелпе тоже ничего подобного не нашел.

AK>>интерфейс?

V>Не понял, можно пример?
V>Допустим, как такую конструкцию перенести на CS:

V>

V>class A
V>{
V>int B();
V>}

V>int A::B ()
V>{
V>return 232323;
V>}
V>

непонятно что значит перевести.

class A
{
  public int B()
  {
   return 323233;
  }
}

вот класс на C#. непонятно что надо.

можно интерфейс объявить и реализовать его, на С++ тоже можно так делать. Если есть желание просто объявить метод вне класса, то так нельзя.

V>

V>class A
V>{
V>int B();
V>}

V>int A::B ()
V>{
V>return 232323;
V>}
V>

Так же не переписать.
Можно выделить интерфейс IA, но это уже не тоже самое будет.
Тут главное то, что в С++ подобная конструкция необходима для
опережающего объявления, но в c# такой проблемы нет.

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

V>>

V>>class A
V>>{
V>>int B();
V>>}

V>>int A::B ()
V>>{
V>>return 232323;
V>>}
V>>

L>Так же не переписать.
L>Можно выделить интерфейс IA, но это уже не тоже самое будет.
L>Тут главное то, что в С++ подобная конструкция необходима для
L>опережающего объявления, но в c# такой проблемы нет.

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

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

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

V>>>

V>>>class A
V>>>{
V>>>int B();
V>>>}

V>>>int A::B ()
V>>>{
V>>>return 232323;
V>>>}
V>>>

L>>Так же не переписать.
L>>Можно выделить интерфейс IA, но это уже не тоже самое будет.
L>>Тут главное то, что в С++ подобная конструкция необходима для
L>>опережающего объявления, но в c# такой проблемы нет.

V>Я чувствовал себя куда комфортней когда описания методов мог разнести по разным модулям, а некоторый хлам (типа конструкторов) оставить прямо в классе, и, честно говоря, немного в шоке в связи с невозможностью данного в C#.

partial class и extensions смотрел?

V>Я чувствовал себя куда комфортней когда описания методов мог разнести по разным модулям, а некоторый хлам (типа конструкторов) оставить прямо в классе, и, честно говоря, немного в шоке в связи с невозможностью данного в C#.

А зачем? Хотите отделить интерфейс от реализации — используйте интерфейсы, хотите разбить большой файл — используйте partial class.

ЗЫ. Если класс вызывает дискомфорт из-за своего размера — рефакторте его.

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

AK>partial class и extensions смотрел?

Нет конечно, сейчас займусь, спасибо.

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

V>>Я чувствовал себя куда комфортней когда описания методов мог разнести по разным модулям, а некоторый хлам (типа конструкторов) оставить прямо в классе, и, честно говоря, немного в шоке в связи с невозможностью данного в C#.

L>А зачем? Хотите отделить интерфейс от реализации — используйте интерфейсы, хотите разбить большой файл — используйте partial class.

L>ЗЫ. Если класс вызывает дискомфорт из-за своего размера — рефакторте его.

Наверное вы правы, но это как-нибудь на потом отложу.

V>Наверное вы правы, но это как-нибудь на потом отложу.
А еще есть #region, тоже могут выручить.

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

V>Я чувствовал себя куда комфортней когда описания методов мог разнести по разным модулям, а некоторый хлам (типа конструкторов) оставить прямо в классе, и, честно говоря, немного в шоке в связи с невозможностью данного в C#.

partial class?

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

V>Возможно ли?

В плюсах для этого есть объективные причины. В С# особого смысла в этом нет...

V>Попробовал как в плюсах, не помогло. В хелпе тоже ничего подобного не нашел.

Смотрите ключевое слово partial. Это совсем не то, что в плюсах... но, с некоторым приближением, похоже.

Всем спасибо за внимание.

V>

V>class A
V>{
V>int B();
V>}

V>int A::B ()
V>{
V>return 232323;
V>}
V>

        class A : ABase
        {
            
        }

        abstract class ABase
        {
            public int B()
            {
                return 232323;
            }
        }

Абстрактные классы никто не отменял .

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

V>>

V>>class A
V>>{
V>>int B();
V>>}

V>>int A::B ()
V>>{
V>>return 232323;
V>>}
V>>

EB>

EB>        class A : ABase
EB>        {
            
EB>        }

EB>        abstract class ABase
EB>        {
EB>            public int B()
EB>            {
EB>                return 232323;
EB>            }
EB>        }
EB>

EB>Абстрактные классы никто не отменял .

Зачем реализацию держать в абстрактном классе....

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

V>Возможно ли?
V>Попробовал как в плюсах, не помогло. В хелпе тоже ничего подобного не нашел.

Вынести в static-методы static-класса?

*только не увлекайтесь, полезно в основном для helper-методов.

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

AK>Зачем реализацию держать в абстрактном классе....

1. А смысл тогда выносить из класса реализацию метода?
2. Если рассматривать поставленную задачу, то Вам, как мне кажется, необходимо определить, что необходимо сделать "вне" файла, в котором описан класс:
а) вынести декларацию методов
б) вынести базовую функциональность
в) разнести различную логику по разным файлам

Так вот:
а) Интерфейс позволяет декларировать (не реализовывать) то, что ДОЛЖЕН делать(не хранить) класс. Так же интерфейс удобно использовать в том случае, когда необходимо передавать класс как параметр: передаем в качестве параметра класс приведенный к тому или иному интерфейсу, от которого наследован класс. При этом остальная реализация класса, не покрытая интерфейсом/ами скрывается от получателя.

б) если у Ваших классов есть определенный функционал (вроде соединения с базой данных, чтения/записи в поток), такой функционал имеет смысл определить и РЕАЛИЗОВАТЬ в одном месте, то бишь, в абстрактном классе, а остальные классы наследовать от абстракции.
Ака пример:

    public abstract class ReportBase
    {
        protected StreamWriter sw;
        public void Open(string file)
        {
            sw = new StreamWriter(file);
        }

        public void Close()
        {
            sw.Close();
        }
    }

    public class ReportA : ReportBase
    {
        public void MakeReportA()
        {
            Open("reportA.txt");
            sw.WriteLine("ReportA!");
            Close();
        }
        // some other logic
    }


    public class ReportB : ReportBase
    {
        public void MakeReportA()
        {
            Open("reportB.txt");
            sw.WriteLine("ReportB!");
            Close();
        }
        // some other logic
    }

Абстракный класс ReportBase задает базовую функциональность для всех репортов, в каждом из наследников ReportA и ReportB нам нет необходимости переписывать код открытия/закрытия потока. Плюс абстракный класс дает нам представление о самом общем функционале той иерархии, которую он основывает.
(не судите строго за пример, старался по-быстрее сделать)

ну и
в) partial классы хороши, когда есть необходимость вынести за пределы файла некоторую функциональность класса (скажем так: разбить класс на логические части)
Я на самом деле вижу смысл такого разнесения только при автоматической генерации части кода(как в студии дизайн формы генерится в отдельный файл), ну и максимум — это разнесение GUI от логики, но на моей практике я больше пользуюсь #region/#endregion.

P.S. Я не читал лекции по ООП, по теории программирования в целом. Это результат моей многолетней практики программирования именно на C#.

С уважением,
Евген.