Почему я не могу передать более общий объект в параметр out? [Дубликат]

Вы боретесь с классической проблемой ковариации (и контравариантности) ООП, см. wikipedia : многое, поскольку этот факт может игнорировать интуитивные ожидания, математически невозможно разрешить замену производных классов вместо базовые для изменяемых (назначаемых) аргументов (а также контейнеров, чьи позиции можно присваивать по той же причине), все еще соблюдая принцип Лискова . Почему это так набросано в существующих ответах и ​​более подробно изучается в этих статьях и ссылках на них.

Языки ООП, которые, как представляется, делают это, оставаясь традиционно статически типичными, «обманывают» (вставляя скрытую динамику проверять тип, или требовать проверки всех источников во время компиляции); фундаментальный выбор: либо отказаться от этой ковариации и принять недоумение практикующих (как это делает C # здесь), либо перейти к подходу с динамической типизацией (как к самому первому языку ООП, Smalltalk), или перейти к неизменяемому (однострочному) задание), как и функциональные языки (по неизменности, вы можете поддерживать ковариацию, а также избегать других связанных головоломок, таких как тот факт, что вы не можете иметь прямоугольный подкласс Rectangle в мире изменяемых данных).

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

class A {}

class B : A {}

class C
{
    C()
    {
        var b = new B();
        Foo(b);
        Foo2(ref b); // <= no compile error!
    }

    void Foo(A a) {}

    void Foo2<AType> (ref AType a) where AType: A {}  
}

Поскольку предоставление Foo2 a ref B приведет к некорректному объекту, потому что Foo2 знает, как заполнить A часть B.

Разве это не то, что компилятор говорит вам, что вы хотите, чтобы я явно бросил объект, чтобы он мог быть уверен, что вы знаете, каковы ваши намерения?

Foo2(ref (A)b)

Рассмотрим:

class C : A {}
class B : A {}

void Foo2(ref A a) { a = new C(); } 

B b = null;
Foo2(ref b);

Это нарушит безопасность типа

Если вы используете практические примеры для ваших типов, вы увидите следующее:

SqlConnection connection = new SqlConnection();
Foo(ref connection);

И теперь у вас есть ваша функция, которая принимает предка ( ie Object):

void Foo2(ref Object connection) { }

Что может быть с этим связано?

void Foo2(ref Object connection)
{
   connection = new Bitmap();
}

Вам просто удалось назначить Bitmap на ваш SqlConnection.

Это нехорошо.

Повторите попытку с другими:

SqlConnection conn = new SqlConnection();
Foo2(ref conn);

void Foo2(ref DbConnection connection)
{
    conn = new OracleConnection();
}

Вы наполнили OracleConnection поверх вашего SqlConnection.

Поскольку в обоих случаях вы должны иметь возможность присвоить значение параметру ref / out.

Если вы попытаетесь передать b в метод Foo2 в качестве ссылки, а в Foo2 вы попытаетесь определить a = new A (), это будет недействительным. По той же причине, которую вы не можете написать:

B b = new A();

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

class Derp : interfaceX
{
   int somevalue=0; //specified that this class contains somevalue by interfaceX
   public Derp(int val)
    {
    somevalue = val;
    }

}


void Foo(ref object obj){
    int result = (interfaceX)obj.somevalue;
    //do stuff to result variable... in my case data access
    obj = Activator.CreateInstance(obj.GetType(), result);
}

main()
{
   Derp x = new Derp();
   Foo(ref Derp);
}

Это не будет компилироваться, но будет ли оно работать?

В моем случае моя функция приняла объект, и я не мог отправить ничего, поэтому я просто сделал

object bla = myVar;
Foo(ref bla);

И это работает

My Foo находится в VB.NET и он проверяет тип внутри и делает много логики

Прошу прощения, если мой ответ повторяется, но другие слишком длинны