Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Interfaces per Fassade?
norman_timo
myCSharp.de - Member

Avatar #avatar-1775.jpeg


Dabei seit:
Beiträge: 4.506
Herkunft: Wald-Michelbach (Odw)

Themenstarter:

Interfaces per Fassade?

beantworten | zitieren | melden

Hallo C#-Community!

Ich bin zufälligerweise auf eine Interface Implementierung gestossen, die ich bisher in dieser Form nicht kannte. Bisher war ich der Meinung, dass ein Interface der Klasse übergeben wird, und dann die notwendigen zu implementierenden Methoden in der Art in entsprechender Klasse verwirklicht werden, dass man sie mit einem Accessor und der Methodenrümpfe einträgt. Also so:


using System;

namespace testraum
{
	public interface testinterface
	{
		void Testmethode();
	}

	public class TestKlasse: testinterface
	{
		public TestKlasse()
		{
		}

		// interface implementation
		public void Testmethode()
		{}
	}

}

Jetzt habe ich folgende Implementierung gesehen:


using System;

namespace testraum
{
	public interface testinterface
	{
		void Testmethode();
	}

	public class TestKlasse: testinterface
	{
		public TestKlasse()
		{
		}

		// interface implementation
		void testinterface.Testmethode()
		{}
	}

}

Was zur Folge hat, dass ich die 'Testmethode' nur noch über das Interface ansprechen kann. Also nur wenn ich code in folgendem Stil verwende:


TestKlasse tk = new TestKlasse();
((testinterface) tk).Testmethode();

Was hat das für einen Vorteil? Das erste was mir da in den Sinn kommt, wäre so etwas wie eine Fassade, so dass ich den Konstructor als 'protected' deklariere, und dann nur noch über die Interface Methoden gehe. Aber ist das sinnvoll?

Was ist der wesentliche Unterschied im Hinblick auf die Nutzbarkeit beider Varianten?

Ciao
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
private Nachricht | Beiträge des Benutzers
svenson
myCSharp.de - Member



Dabei seit:
Beiträge: 8.746
Herkunft: Berlin

beantworten | zitieren | melden

Wenn eine Klasse mehrere Interfaces implementieren soll, dann kann es zu Namenskonflikten kommen, wenn beide Interface eine Funktion gleichen Namens und Signatur vorschreiben. Für diesen Fall gibt es die sogenannte "explizit Interface"-Implementierung.

Wird reichlich im Framework eingesetzt (man schaue sich mal IConvertibable auf den Basistypen an), leider via Intellisense nicht sichtbar und auch in der Hilfe nur über Umwege zu erreichen.
private Nachricht | Beiträge des Benutzers
Xqgene
myCSharp.de - Member



Dabei seit:
Beiträge: 2.051

beantworten | zitieren | melden

** nur als kleine info nebenbei **

zu den Patterns gibt es bei MS eine ganze Webcast-Reihe: https://www.microsoft.com/germany/msdn/webcasts/serien/MSDNWCS-0506-03.mspx

unter anderem auf zum Facade Pattern.
"A programmer is a tool which converts coffein to code."

Evely ToDo-Manager 1.2 (Build 1.2.585)
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

Hallo norman_timo,

Fassade wäre genau anderesherum. Es man sieht die Schnittstelle, aber nichts dahinter (jedenfalls nicht in der Fassaden-Klasse selbst).

herbivore
private Nachricht | Beiträge des Benutzers
norman_timo
myCSharp.de - Member

Avatar #avatar-1775.jpeg


Dabei seit:
Beiträge: 4.506
Herkunft: Wald-Michelbach (Odw)

Themenstarter:

beantworten | zitieren | melden

Hallo Herbivore!

Ja das genau hab ich gemeint, nur nicht explizit in Code ausgedrückt. Facade würde ich irgendwie dann so umsetzen (wenn denn zwingend mittels Interface, wobei es hier bessere Lösungen gibt):


using System;

namespace testraum
{
    public interface testinterface
    {
        void Testmethode();
    }

    public class TestKlasse: testinterface
    {
        protected TestKlasse()
        {
        }

        public static testinterface GetInstance
        {
                get
                {
                        TestKlasse tk = new Testklasse();
                        return (testinterface) tk;
                }

        // interface implementation
        void testinterface.Testmethode()
        {}
    }

}

Dann bin ich doch bei Facade-Pattern, oder?

Ciao
Norman-Timo


P.S.:
Hab für Design Patterns immer hier geschaut:
Dofactory Design Patterns

Alle in C# mit Theorie- und Realbeispiel, sehr zu empfehlen ;-)
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 49.486
Herkunft: Berlin

beantworten | zitieren | melden

Hallo norman_timo,

hm, also ich kriege deinen Code nicht mit dem Fassade-Pattern unter einen Hut. Aber nur an der Fassaden-Klasse ist es ohnehin schwer zu sehen, weil die Fassaden-Klasse sich ja (eben als Fassade) vor einen ganzen Sack von Klassen stellt (und diese dadurch versteckt).

herbivore
private Nachricht | Beiträge des Benutzers
norman_timo
myCSharp.de - Member

Avatar #avatar-1775.jpeg


Dabei seit:
Beiträge: 4.506
Herkunft: Wald-Michelbach (Odw)

Themenstarter:

beantworten | zitieren | melden

Hallo Herbivore!

Ja, ich glaube ich weiß warum Du das nicht siehst :-)

Vielleicht, weil ich einen entscheidenden Teil vergessen hab *schäm*.

Natürlich sollte die Testklasse auch von irgendwas erben, z.B. von System.Web.UI.HtmlControls.HtmlTable (wäre dann genau mein Anwendungsfall :-)

Dann wären alle public Eigenschaften und Methoden von HtmlTable durch die Testklasse verdeckt, und man könnte nur auf Interface Methoden zurückgreifen.

Oder aber man erstellt als Testklasse-Klassenvariablen Objekte von diversen Klassen, und greift innerhalb der Schnittstellenimplementation dann auf Methoden der instanziierten Klassen zurück.

Sorry, ich hab heut schon zu lang gearbeitet ;-)

Ciao
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
private Nachricht | Beiträge des Benutzers
Pulpapex
myCSharp.de - Member



Dabei seit:
Beiträge: 939
Herkunft: Rostock

beantworten | zitieren | melden

Eine Fassade kann man als eine Art Steuerzentrale für ein System sehen.

Sie verbirgt ein grösseres, nicht einfach handhabbares, aber dennoch erforderliches Klassenmodell. Die Verwendung der Funktionen des Klassenmodell wird erleichtert, aber auch eingeschränkt. Es geht Flexibilität verloren.

Mit Vererbung und Interfaces hat das überhaupt nichts zu tun. Im Gegenteil, eine Fassade ist meistens eine fest implementierte, sehr spezielle Klasse. Ihre Schnittstelle ist eine ganz andere als die der Klassen, die sie verbirgt.
private Nachricht | Beiträge des Benutzers
Golo Roden
myCSharp.de - Member

Avatar #avatar-2167.png


Dabei seit:
Beiträge: 4.207
Herkunft: Riegel am Kaiserstuhl

beantworten | zitieren | melden

Mal ein simples Beispiel für eine Facade:

Du hast einen Compiler gebaut, einen Linker, beide benutzen einen Parser, es gibt noch irgendein Zusatztool .... halt alles, was man so braucht, um Quellcode in Maschinencode zu übersetzen.

Nun ist es zwar schön, dass man 30 Methoden aufrufen kann / muss, das ganze in der richtigen Reihenfolge, aber so wirklich praktisch ist das für 99 % der Fälle nicht.

Also schreibst Du Dir eine Klasse, die eine Methode CompileFromSource enthält, die als Zwischenschicht eingezogen wird, um die Komplexität der Übersetzung zu verbergen. DAS wäre eine Facade.
Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de
private Nachricht | Beiträge des Benutzers