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

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

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

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

_FR>Ты Why Doesn't C# Implement "Top Level" Methods? ещё не прочитал, да?

Липерт много пишет. Зачастую защищает мундир или просто исходит из однобокого взгляда. Мне не нужно читать, что-то чтобы понять то, что я и так прекрасно понимаю.

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

Единственная объективная причина того почему в С++ оставили глобальные функции — это обратная совместимость с С. С другой стороны причин по которым не сделаны глобальные функции нет.

Собственно, вот реальный ответ товарища Липерта:

First off, I reject the premise that the feature is "bad" for C#. The feature might well be good for C#, just not good enough compared to its costs (and to the opportunity cost of doing that feature instead of a more valuable feature.) The feature might become good enough for C# if its costs are lowered, or if the compelling benefit to customers becomes higher.

C# таков каков он есть, потому что создают его самыми экстенсивными методам. Отсюда это "фича хороша для C#, но недостаточно хороша при сравнении с ее стоимостью" (feature might well be good for C#, just not good enough compared to its costs).

Когда пишешь все на С++ в суровом императивном стиле, то лучшая фича та, что легче всего реализуется в лоб при этом являясь полезной для потребителя.

В таких условиях дизай превращается в хождение на поводу у сложности разработки.

Ну, и конечно не нужно сбрасывать со счетов такие вещи как заблуждение авторов и давление господствующих идеологий. Все же идея "все должно быть объектно-ориентированным" столь же фанатичная и бестолковая как идеи "все должно быть функциональным" или "все должно быть черным".

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

Здравствуйте, 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 смотрел?

Здравствуйте, 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#.

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

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

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

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

А можно немного ликбеза по объективным причинам? Причем меня всегда больше интересовал вопрос почему в С# нельзя сделать глобальную функцию.

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

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

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

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

VD>А можно немного ликбеза по объективным причинам? Причем меня всегда больше интересовал вопрос почему в С# нельзя сделать глобальную функцию.

почему нельзя, можно...

public static class A
{
    public static int Func()
    {
       return 0;
    }
}

чем не глобальная функция

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

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

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

VD>А можно немного ликбеза по объективным причинам?

Сколько проходов?

VD>Причем меня всегда больше интересовал вопрос почему в С# нельзя сделать глобальную функцию.

Ну это немного из другой оперы. причём и про это Эрик, кажется, писал, но не могу сейчас отыскать.

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

VD>>Причем меня всегда больше интересовал вопрос почему в С# нельзя сделать глобальную функцию.

_FR>Ну это немного из другой оперы. причём и про это Эрик, кажется, писал, но не могу сейчас отыскать.

Why Doesn't C# Implement "Top Level" Methods?

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

AK>

AK>public static class A
AK>{
AK>    public static int Func()
AK>    {
AK>       return 0;
AK>    }
AK>}
AK>

AK>чем не глобальная функция

Наличием класса в котором она объявлена. Скажем попробуй в C# расширить список перегрузок консольных WriteLine. Или просто вызвать их без указания класса в котором они объявлены.

Ведь по идее класс тут выполняет роль пространства имен (иначе говоря "модуля"), но в отличии от пространств имен и модулей класс мы не можем открыть using-ом (в C#).

Так что лично я никаких объективных причин не вижу. Сделали так как получилось.

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

_FR>Ну это немного из другой оперы. причём и про это Эрик, кажется, писал, но не могу сейчас отыскать.

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

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

_FR>>Ну это немного из другой оперы. причём и про это Эрик, кажется, писал, но не могу сейчас отыскать.

VD>Поверь человеку самому писавшему компиляторы, что никаких объективных причин тут нет. Это выбор дизайнеров языка. Сделать глобальные функции можно даже не смотря на то, что в дотнете такой возможности нет.

Ты Why Doesn't C# Implement "Top Level" Methods? ещё не прочитал, да?