Cod Rob

атрибуты - это некая метаинформация, которая может быть кем-то прочитана и на основании которой кто-то принимает какие-то решения.
например, в метод, помеченный [HttpGet] попадут только Get запросы от клиента.

вообще, я говорю, лучше от практики отталкиваться в изучении. иначе это получается какое-то себе сферическое. и в памяти не отложится и понимание не придёт. а когда видишь как это работает, совсем другое дело. поменяй немного метод изучения на упор каких-то задач. а то так можно много вопросов задавать с примерно 0 КПД.

Все объекты одинаковы и в памяти имеют одинаковое строение, да имеет все, что есть у object, строка, как и массивы, выделяют память в куче на хранение данных. Вот стоит посмотреть https://youtu.be/KbuJdkPLAjw

У Рихтера кстати по моему все то же самое описано, во всяком случае дальше.
tooslowexception.com/how-does-gettype-work

Зачем хранить нам что она константа, если мы компилируем её так, что её не кто не меняет. А если кто-то пытается, то не компилируем.
Ну а вообще изучайте reflection, можете начать с этого https://docs.microsoft.com/ru-ru/dotnet/api/system...

если поле константа - все использования этого поля будут заменены на значение константы в момент компиляции.

исходный пример:

class Program
    {
        static void Main(string[] args)
        {
            const int i1 = 10;
            var k1 = i1 + Func(i1);
            Console.WriteLine(k1);


            var i2 = 10;
            var k2 = i2 + Func(i2);
            Console.WriteLine(k2);
        }

        private static int Func(int i)
        {
            return i * 2;
        }
    }

результат декомпиляции:

internal class Program
  {
    private static void Main(string[] args)
    {
      Console.WriteLine(10 + Program.Func(10));
      int i = 10;
      Console.WriteLine(i + Program.Func(i));
    }

    private static int Func(int i)
    {
      return i * 2;
    }
  }

Базовый класс можно даже через рефлексию вытащить можно. По нескольким последним вопросам, я думаю, вы не туда копаете, не понимая многих базовых принципов. Рано вам ещё под капот лезть. Ну и у Рихтера вы не найдете ничего про внутренности, не смотря на очень громкое название. Ну если уж и очень охота под капот залезть, поищите Станислава Сидристого книгу, он ее на гитхаб выложил, Саши Гольдштейна, оптимизация .net приложений, есть конференция dotnext, они на канале yt выкладывают записи с выступлений. Но повторюсь вам ещё рано туда залезать, направьте свои силы на изучение базы. Да и чтобы под капот лезть, необходимо, хотя бы минимальное, знание архитектуры ПК, знание ассемблера, устройства памяти, процессов.

So, как в куче помечено, что класс B унаследован от класса А?

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

вот можно начать отсюда https://docs.microsoft.com/en-us/archive/msdn-maga...

Почему это происходит?

потому что-то конструктор класса А может инициализировать поля которые потом нужны конструктору класса B.

ни как. это записано в тексте программы, а последовательность вызовов строит компилятор
ps

если мы в методе Main напишем B b = new B();, то у нас сначала вызовется статический конструктор в классе B, потом статический конструктор в классе A, потом динамический конструктор в классе A, и динамический конструктор класса В.

а над статикой не заморачивайтесь вообще, пока хорошенько не поймете что это такое. это не очень понятно на начальных этапах изучения, и это точно не надо учитывать, пока не дойдете до необходимости создания собственных переопределений статических конструкторов

Статические члены относятся к типу класса, а не его экземпляру. Это на один уровень выше в иерархии типов.

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

Например, мы хотим иметь несколько разных методов вычисления площади класса "гиперсфера" в зависимости от размерности пространства. Классический подход: передавать размерность в конструктор, а в методе GetSquare() каждый раз у каждого объекта проверять размерность и использовать соответствующую формулу. Однако, было бы проще задать размерность сразу для типа "гиперсфера", т. е статически. Тогда и в конструкторе меньше параметров, и каждый раз проверять не требуется, и лишняя память не тратится, и меньше кода писать, и новые объекты сразу создаются с нужной формулой. Иными словами, паттерн "фабрика".

Одна из реализаций паттерна синглтон, на статическом поле класса строится. Ну и как выше, всякие счётчики, какой нибудь класс обработчик, общий на все классы, да куча разных кейсов.

Статическая область памяти инициализируется до начала исполнения точки входа main.

Статический класс гарантирует существование единственного экземпляра класса.

Статическое поле позволяет реализовать хранение данных, которые будут существовать вплоть до выхода из функции main.

Статический конструктор позволяет произвести предварительную инициализацию для класса ещё до создания хотя бы одного экземпляра класса.

Статические данные, таким образом, можно считать достоянием главного потока, исходного процесса.

В общем случае, всё статическое используется для инициализации, которая должна произойти раньше рантайма. Но это справедливо только для области каждого класса / иерархии классов, а не всего набора классов в исходном коде, потому что управлять порядком отработки статических конструкторов - моветон.

Если использование кода не предполагает использование класса в нескольких потоках, то допускается использование "общих" данных в статических полях, но как правило, это рационально только для readonly и const.

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

Да и код обрамляйте в тэги.

Несколько мыслей.

1) Существуют языки программирования в которых рекурсия вообще заменяет цикл (Haskell, Erlang) и другого способа описать итерацию кроме как через рекурсивную функцию - нету. Но наверное в топике тема рекурсии - не основная - а просто частный пример.

2) Во всех случаях всегда надо выбирать "читабельность". Прошли времена когда программисты отдавали дань ассемблеру или указателям на сырую память. Сегодня так пишут все меньше и меньше. И основная задача написания кода - сделать его понятным для вашего коллеги. Цитата : "Код пишется человеком для прочтения человека и лишь в очень редких случаях - для машины".

Вобщем пишите код. Просите коллег чтоб они его посмотрели и ПОНЯЛИ что вы имели в виду. И если коллеги будут кричать WTF! - фиксируйте их замечания и доводите до такого состояния чтобы ни у кого не было вопросов.
Это будет идеальный код по Роберту Мартину.

String хитрый тип, до недавнего времени его нельзя была задать в роли константы, т.к. он действительно ссылочный тип. Ещё по-умолчанию он интернированный, т.е все одинаковые тексты ссылаются на одним объект. Текст нельзя поменять, можно только создать новый объект с новым текстом.
У вас же передаётся ссылка на объект "str", а затем в методе создаётся новый объект текста и ссылка сохраняется в переменную.
Отсюда следует, что если вы собираете условный json постоянными склейками текстов, то вы генерируете кучу новых объектов - не эффективно расходуя память. Для это лучше использовать StringBuilder, который весь текст складывает в один буфер с заранее большей длинной.