Laden...

Warum können abstrakte Datentypen nicht privat sein ?

Erstellt von Christoph K. vor 15 Jahren Letzter Beitrag vor 15 Jahren 1.666 Views
Christoph K. Themenstarter:in
821 Beiträge seit 2009
vor 15 Jahren
Warum können abstrakte Datentypen nicht privat sein ?

Warum können abstrakte Datentypen nicht privat sein ?
kann mir jemand die Frage benatworten ?

N
203 Beiträge seit 2008
vor 15 Jahren

Private wird ja nicht vererbt, demnach kann es auch nicht abstract sein.

Besser gesagt, aus der erbenden Klasse kann nicht auf das private Element zugegriffen werden. Es ist eh nicht möglich, Felder abstract zu deklarieren, sondern nur Methoden.

Benutz doch ein abstract Property

protected abstract string blub { get; set; }

Signatur.Text = "Greetz, Neals";

1.346 Beiträge seit 2008
vor 15 Jahren

Nochmal in anderen Worten: abstract bedeutet, das überschrieben werden muss . Bei private kann aber nichts überschrieben werden, da man nicht von außerhalb der klasse darauf zugreifen kann.

Gruß pdelvo

5.941 Beiträge seit 2005
vor 15 Jahren

Hallo meisteralex

Bitte die Frage nicht nur in den Titel schreiben.
Ich habs mal korrigiert.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo meisteralex,

abstrakte Datentypen dürfen ja privat sein. Wobei Klassen dann privat sind, wenn man keinen Zugriffsmodifier davor schreibt.

/* implizit private */ abstract class A { ... }

Vermutlich meinst du aber, warum abstrakte Member (also z.B. abstrakte Methoden) nicht privat sein dürfen. Das haben die anderen ja oben schon beantwortet. Es macht eben keinen Sinn durch abstract zu sagen "das musst du überschreiben" und gleichzeitig durch private zu sagen "das darfst du nicht überschreiben, weil du es noch nicht mal kennen darfst".

Da du, wenn du es trotzdem tust, einen Syntaxfehler bekommst, siehe auch [Hinweis] Syntaxfehler selbst lösen (Compilerfehlermeldungen).

herbivore

5.742 Beiträge seit 2007
vor 15 Jahren
/* implizit private */ abstract class A { ... }  
/* implizit internal*/ abstract class A { ... }

Siehe Nicht empfehlenswert: C# 3.0 Entwurfsmuster

Also können Typen in C# niemals privat sein.

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo winSharp93,

tja, dann sieht man es mal wieder, auch ich kann mir nicht alles merken. 😃 Danke für den (erneuten) Hinweis.

herbivore

O
778 Beiträge seit 2007
vor 15 Jahren

Also können Typen in C# niemals privat sein.

Stimmt nicht. Können sie. Macht aber nur bei Nested Classes überhaupt Sinn, dann allerdings hat der Compiler auch nichts dagegen. Folgendes kompiliert bei mir (VS08) auch problemlos:

namespace Test
{
    public class BaseClass
    {

        private SubClass2 sc = new SubClass2();

        private abstract class SubClass1
        {
        }

        private class SubClass2 : SubClass1
        {
        }
    }
}

Also sind private Klassen möglich - auch abstrakte, aber eben nur nested.

R
234 Beiträge seit 2007
vor 15 Jahren

Also sind private Klassen möglich - auch abstrakte, aber eben nur nested.

Hm ... irgendwie verstehe ich aber den Sinn davon nicht. Man kann doch mit einer abstracten, privaten Nested-Class genauso wenig anfangen wie mit einer abstracten, privaten Nicht-Nested-Class. Oder übersehe ich das jetzt nur was?

/Edit: Mist, hät ich mir den Code erstmal durchlesen sollen. Ist natürlich klar, was man damit anfangen kann.

3.971 Beiträge seit 2006
vor 15 Jahren

Beim State-Pattern ist es beisbielsweise sinnvoll auch eine private abstrakte Basis-Klasse/Interface innerhalb einer Klasse zu definieren, zusätzlich zu den von der Basis-Klasse abgeleiteten Typen. Dies lässt sich beispielsweise sinnvoll mit partial umsetzen.

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...

5.742 Beiträge seit 2007
vor 15 Jahren

Stimmt nicht. Können sie. Macht aber nur bei Nested Classes überhaupt Sinn, dann allerdings hat der Compiler auch nichts dagegen.

Ja, ja - jetzt hat man mich auch erwischt 😉