Laden...

Klasse je nach App.config einstellungen instanzieren

Erstellt von Bad_Hoschi vor 17 Jahren Letzter Beitrag vor 16 Jahren 6.653 Views
B
Bad_Hoschi Themenstarter:in
55 Beiträge seit 2006
vor 17 Jahren
Klasse je nach App.config einstellungen instanzieren

Hallo.

Ich habe zwei klassen die von der selben schnittstelle abgeleitet sind.
Jetzt möchte ich, dass ich in den appsettings festlegen kann welche der klassen instanziert werden soll.
Das möchte ich dann einfach abrufen können um die angegebene klasse zu instanzieren ohne das ich mit switch oder if, je nach string der appsettings, entscheiden muss.

Geht das überhaupt und wenn ja wie? 🙂

Gruß
kai

4.207 Beiträge seit 2003
vor 17 Jahren

Hallo,

ja, das geht ... schau Dir mal die Einträge unter http://www.des-eisbaeren-blog.de/Default.aspx?SearchKey=service%20locator an ...

Viele Grüße,

Golo

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

B
Bad_Hoschi Themenstarter:in
55 Beiträge seit 2006
vor 17 Jahren

Hallo.

vielen dank für deine antwort.
geht es vielleicht auch ein wenig einfacher? 😉 ich wollte jetzt nicht noch einen extra service dafür schreiben.

bis jetzt hab ich es damit versucht:


new System.Configuration.AppSettingsReader().GetValue("UsedWorkspace", typeof(IWorkspace))

die appsettings:


	<appSettings>
		<add key="UsedWorkspace" value="namespace.FakeWorkspace" />
	</appSettings>

so bekomme ich aber eine Exception:
System.InvalidOperationException : Der Wert namespace.FakeWorkspace wurde im appSettings-Konfigurationsabschnitt für den Schlüssel UsedWorkspace gefunden. Dieser Wert ist kein gültiger namespace.IWorkspace.

naja bis auf die exception hatte ich mir das eigentlich so gedacht (vom prinzip her jedenfalls) und das wäre ja kein großer aufwand. aber so in die richtung gibt es keine lösung?

gruß
kai

Z
43 Beiträge seit 2006
vor 17 Jahren
Eine mögliche Lösung...

... es lohnt sich nicht, nach dem Sinn zu fragen, oder?!



// Vorbereitung
// Diese Klassen und das Interface werden weiter unten verwendet.

public interface I
{
	string GetMessage();
}

public class A : I
{
	string I.GetMessage()
	{
		return "Objekt der Klasse A";
	}
}
public class B: I
{
	string I.GetMessage()
	{
		return "Objekt der Klasse B";
	}
}


<?xml version="1.0" encoding="utf-8" ?>
<!-- Die Konfigurationsdatei app.config -->
<configuration>
	<appSettings>
		<add key="InstanzVon" value="A" />
	</appSettings>
</configuration>

Was du erreichen willst, ist - wenn ich dich richtig verstanden habe, Klassen in Abhängigkeit von Konfigurationseinstellungen zu instanziieren. Dazu müssen wir besinnlich das Assembly betrachten, ob wir entsprechende Klassen überhaupt besitzen --- kurz "Reflection" ist das Zauberwort für die Lösung dieser lustigen Aufgabe.

Der Einfachheit halber gehe ich von folgenden Voraussetzungen aus:
Alle zu instanziierenden Klassen befinden sich im selben Namespace.
Es treten keine Fehler auf.


void EineMethodeInMeinerFabrik() 
{
	// Zuerst lesen wir die Einstellung aus der app.config...
	string instanzVon = System.Configuration.ConfigurationManager.AppSettings["InstanzVon"];

	// Das war einfach. 
	// Und jetzt? ... Nehmen wir das lokale Modul...
	Module module = Assembly.GetExecutingAssembly().GetModules(false)[0];
	// ... und durchsuchen es, ob es darin einen Typ gibt, der dem entspricht, den wir lt. Vorgaben erwarten.
	Type type = module.FindTypes(Module.FilterTypeName, instanzVon)[0];
	// Da wir einen gefunden haben, brauchen wir nur noch eine Instanz davon.
	// Doch das ist nicht ganz so einfach.
	// Zunächst erstellen wir im Blindflug eine Instanz, von der wir das Handle bekommen.
	object handle = AppDomain.CurrentDomain.CreateInstance(Assembly.GetExecutingAssembly().FullName, type.FullName);
	// Damit könnten wir jetzt lustige Sachen machen.
	// Nur verwenden können wir es nicht.
	// Also packen wir dieses Handle aus ...
	// ... und sprechen es über die Schnittstelle an...
	MessageBox.Show(((I)((System.Runtime.Remoting.ObjectHandle)handle).Unwrap()).GetMessage());

	// et voila ...
	// Wenn's geklappt hat, 
	// solltest du jetzt eine MessageBox mit dem Text	 
	// "Objekt der Klasse A"
	// sehen...

}

Ein wunderschöner Vierzeiler, nicht wahr?!
Geht's noch einfacher?

4.207 Beiträge seit 2003
vor 17 Jahren

Original von zero
... es lohnt sich nicht, nach dem Sinn zu fragen, oder?!

Wie meinst Du das?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

S
8.746 Beiträge seit 2005
vor 17 Jahren

Ergänzend kann man hinzufügen, dass das Unwrap() optional ist, sofern das Objekt innerhalb der AppDomain (CurrentDomain) erzeugt wird.

Wenn man unbekannte Implementierungen (z.B. über dynamisch geladene Assemblies) verfügbar machen will, ist es wichtig ein entsprechendes Interface bereitzustellen. Die Klasse selbst ist ja zur Compile-Zeitg nicht bekannt und damit auch nicht verfügbar

Z
43 Beiträge seit 2006
vor 17 Jahren
Wie ich es sagte; Golo Haas. :)

Diese Art der externen Einflussnahme ist kreuzgefährlich für die Anwendung. Wesentlich praktikabler sind Automatismen, da sowieso nur eine endliche und überdies bekannte Menge von Typen existieren kann. (Es sei denn, Bad_Hoschi wollte dynamische - quasi lernfähige - Bibliotheken erzeugen, die sich selbst um spezielle Typen erweitern, diese aber nur bedingt verwenden dürfen. ... Wobei diese Bedingungen nichtdeterministisch sein müssten; anderenfalls sie über Workflows realisiert werden könnten...)

Der IMO einzige einigermaßen sinnvolle Aspekt derartiger externer Konfiguration wäre es, wenn die Anwendung dynamisch und willkürlich Bibliotheken austauscht, wobei gleichzeitig hochperformanter Zugriff auf die Typen sichergestellt werden muss. ... Aber dann dürfte er sich, ohne ihm zu nahe treten zu wollen, mit dem Vorladen und Analysieren der Bibliotheken reichlich schwer tun. ...

4.207 Beiträge seit 2003
vor 17 Jahren

Ich sehe das ein wenig anders - sofern CFD mit TDD betrieben wird, kann ein solches Vorgehen beispielsweise den Einsatz von Mockobjekten stark erleichtern.

Gerade im Hinblick auf Komponentenorientierung ist dieses Modell doch üblich - siehe Dependency Injection und Service Locator Patterns.

Was ist daran falsch?

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Z
43 Beiträge seit 2006
vor 17 Jahren
Selbst dann wäre es zumindest fraglich, Golo Haas.

... CFD mit TDD ... Einsatz von Mockobjekten stark erleichtern

Auch in diesem (Spezial-)Fall sehe ich nicht wirklich den Nutzen derartiger externer Steuerung. Immerhin willst du gegen mögliche Kombinationen testen. Das wäre IMO nur dann sinnvoll, wenn du keine eindeutig definierbaren Tests fahren kannst und das blinde Stochern einschränken und/oder teilautomatisieren möchtest. Das würde zwar partiell den Sinn des TDD verkehren, aber dennoch wäre das ein - der einzige? - Fall, den ich akzeptieren könnte.

Und auch im Sinne des genannten SL Patterns (Du steckst gerade in einem solchen Projekt, ja? 😉) ist es schlicht fragwürdig, würde es doch wie ein Filter " ... das ja --- das auch --- das nicht --- das ja --- das nicht ..." wirken. Und das kann man wunderbar automatisieren; so die Störanfälligkeit drastisch senken und gleichzeitig den abstrakten Determinismus fördern.
Service Locators stellen konsolidierte Funktionalität bereit, die sie aus anderen Quellen zusammenfassen. Welchen Sinn macht es da, einzelne Typen oder Typen-Bereiche willkürlich/nichtdeterministisch auszugrenzen?

Nur wenn die Regel nichtdeterministisch wäre, du also nicht im Voraus wüsstest, mit welchen Typen du es zu tun bekommst und dennoch dezidierte (abstrakte) Typen/Typen-Gruppen aus-/einschließen möchtest, würde es IMO sinnvoll werden --- jedenfalls sehe ich derzeit keine andere Option. Aber ich mag da mangels nützlicher Ideen durchaus noch recht unflexibel sein...

Ich jedenfalls haue meinen Jungs regelmäßig auf die Finger, wenn die ankommen und meinen "Hey, da bauen wir einen geilen work around/Schalter/Brücke und dann geht das wieder...". Diese Willkürlichkeit macht es unglaublich schwierig, Software zu adaptieren. Wozu es noch fördern?!

Und Dependency Injection, als abstrakt erweitertes Factory Pattern, ist nun wahrlich vollständig regelbasiert. Alles andere würde das Pattern kompromittieren.

Was ist daran falsch?

Ich sehe es doch nicht als "falsch", sondern einfach nur als extrem fragwürdig. Nicht alles, was machbar ist, macht auch Sinn. Zweifellos ist das willkürliche Beeinflussen (meistgebrauchte Ausrede: "Keine Zeit, wir müssen abkürzen!") gängige Praxis, allerdings sieht man auch, wohin es in 73% aller Fälle führt: Projektverriss & Kostenexplosion...

S
8.746 Beiträge seit 2005
vor 17 Jahren

Welche Verfahrensweise für die Intergration von Mock-Funktionalität würdest du denn anstelle von DI vorschlagen, ohne gleich komplett generativ zu arbeiten?

T
512 Beiträge seit 2006
vor 17 Jahren

Vieleicht will er auch einfach nur probieren wie sowas geht und arbeitet nicht am nächsten Steuersystem für Langstreckenraketen.

Ich seh das ehrlich gesagt als einen ersten Schritt in Richtung Plugins. Da ist es ja doch eher üblich nicht unter der Voraussetzung zu entwickeln, dass man alle Plugins kennt.

e.f.q.

Aus Falschem folgt Beliebiges

Z
43 Beiträge seit 2006
vor 17 Jahren
Oh, wir haben einen Sokrates im Forum... :)

Der prinzipielle Haken von Mocks ist, dass sie bereits beim Testen Lücken (entstehen) lassen (können), die sich später als überaus gefährlich erweisen (können); und es leider auch immer wieder machen. Microsoft testet beispielsweise seine Patches häufig gegen solche Mocks. Das Resultat: Es werden weitere Patches gebraucht, weil die Dummys inkompatibel waren. Das neue Patch schließt zwar Lücken, reißt aber auch in der Produktivumgebung an anderer Stelle unerwartet neue auf. Die Lehre: Mocks sind verdammt kompliziert und erfordern daher ungeheuren Aufwand; sowohl im Design als auch in der Implementierung. Und der Aufwand steigt bei jedem Durchlauf exponenziell, wenn man in iterativer Software testet.

Ich halte, obwohl wir es selbstverständlich gelegentlich auch einsetzen, Mocks generell für Mummenschanz. Die Möglichkeit, in gefakten (Bah, wie deutscht man das ein? ... i meant "faked") Umgebungen zu testen, ist - leider - viel zu oft dafür missbraucht worden, dem Kunden mit einem fetten Grinsen im Gesicht zu "beweisen", dass man noch optimal im Plan läge und er bedenkenlos weiteres Geld zuschießen könne. (Merke: Lasse nie die Marketing-Affen in die Testlabore! Und mache es wie die alten Ägypter: Sperre die Baumeister deiner Testumgebungen luft- und wasserdicht, vor allem aber ohne Kontakt zu fremden Menschen, weg.)

Wenn man TDD schon einsetzen will, dann lässt es a) eine ganze Reihe von Optionen zu, die Tests sinnvoll zu strukturieren (Induktionstests, Deduktionstests, etc.), die man b) auch nutzen sollte.

Verfahrensweise für die Intergration von Mock-Funktionalität würdest du denn anstelle von DI vorschlagen ... errrr ... Ich verstehe die Frage nicht. Anstelle von DI? Dependency Injection (DI) ist, wenn wir vom Gleichen reden, ein abstrakt erweitertes Factory Pattern. Ob DI verwendet wird, ist eine Designfrage. Keine Implementierungsfrage.

Dabei ist DI strikt regelbasiert - das sagt doch schon der Name. Und wer eine Regel findet, die nicht deterministisch ist, der sollte es - bei dem Glück - mal mit Lotto Spielen probieren. Einigermaßen intelligente Fallback Flows würden aber selbst diesen Extremfall auffangen können. Dennoch - ich gebe es zu -: Theoretisch besteht die Möglichkeit, dass es absoluten Zufall gibt (und in 90% der Fälle sitzt er bekanntlich vor dem Monitor). Wer dagegen testen muss, der entwickelt aber auch die traumzauberbaumschen "Steuersysteme für Langstreckenraketen" und wird entsprechende Vorsorge treffen müssen. Und sei es auch nur, dass er seine AGB erweitert. 😉

Grundsätzlich rate ich beim Einsatz von Mocks, und insbesondere in Kombination mit TDD, zu "statischen" Testbibliotheken. TDD setzt sowieso die Tests an den Anfang. Also kann man es auch richtig machen und die Testbibliotheken mit Typen füllen, die exakt die zu testenden Parameter besitzen. Externe Steuerung/Einflussnahme würde hier nur dafür sorgen, dass die Tests weniger zuverlässig werden (vgl. Merksatz). Das funktioniert ähnlich wie eine Messlehre: Passt das Objekt durch das vorbereitete Loch, ist alles im Lot. Passt es nicht, muss noch dran gefeilt werden. Niemand kann die einmal eingestellten Parameter verändern, so dass sie nur ein einziges Mal in Kooperation mit dem Kunden abgesprochen und eingestellt werden müssen. Das spart Geld und Zeit. Es kostet allerdings vermutlich eine ganze Menge Nervenzellen, die auf dem Weg zum optimalen Testverfahren verbraucht werden...

Klingt einfach. Ist es aber nicht. Das weiß ich auch. Wäre es einfach, würden nicht so viele Projekte scheitern. Und insbesondere das Extreme Testing (TDD) ist eine unglaubliche Herausforderung, die ihre Schwierigkeiten am Anfang nicht wirklich zeigt und sich am Ende nicht mehr realistisch ändern lässt.

@Traumzauberbaum

Vieleicht will er auch einfach nur probieren wie sowas geht und arbeitet nicht am nächsten Steuersystem für Langstreckenraketen. Wenn ich in der Projektkoordination eines gelernt habe, dann "Wehret den Anfängen!", Traumzauberbaum. Hast du eine Ahnung, wie schwer es ist, Leuten ihre (dummen/schlechten/unangenehmen) Angewohnheiten abzugewöhnen? Egal, ob es um "== true" oder externe Steuerungsschalter/Quasi-Brücken geht?!

Da ist es sinnvoller, von Anfang an auch die Gefahren aufzuzeigen und sie so zu sensiblisieren, dass das, was sie da tun, durchaus möglich, aber nicht zwingend oder nur begrenzt sinnvoll ist. Ich weiß nicht, wie es heute ist, aber das Gleiche machte man übrigens auch bei mir noch im Werkunterricht: "Das ist ein Hammer. Damit kann man Nägel in die Wand und Daumen blau schlagen. Ersteres ist gut. Letzteres tut weh.".

als einen ersten Schritt in Richtung Plugins Das ist es auch. Allerdings mit veralteten Ideen. Smart Apps sind die Gegenwart. Und erst recht die Zukunft. Und da das zugrunde liegende Konzept in eine andere Richtung geht, ist selbst die "Ausrede" ... "Hey, ich will nur mal sehen, wie das geht." nicht/nur bedingt zutreffend. 😉

4.207 Beiträge seit 2003
vor 17 Jahren

Ich kann Deine Argumentation nicht ganz nachvollziehen ... folgendes Szenario:

Es wird ein Kontakt I definiert, und zwei Typen A und B, die jeweils I implementieren. I definiert also die Syntax von A und B. Außerdem wird ein (1!) Test T gegen I geschrieben, der I als Blackbox betrachtet und die Semantik der von I angebotenen Methoden testet. Da A und B austauschbar sein sollen, müssen sie die gleiche Semantik aufweisen, sprich, T muss für A und B gelten.

Gilt T nun für A und B, dann kann ich A und B beliebig mit Hilfe beispielsweise eines Service Locators in meiner Applikation gegeneinander austauschen, da der Kontrakt und das Verhalten gleich sind. Wie A und B zu ihrem Verhalten intern kommen, interessiert mich nicht, da sie nur als Blackboxes gesehen werden.

Gilt T nun nicht für A und B, dann kann ich A und B logischerweise nicht austauschen, allerdings schlägt dann auch mein Unittest fehl, da eine von beiden Komponenten eine andere Semantik aufweist.

Ob alles zusammen funktioniert, jeweils mit A oder B, lässt sich wiederum mittels Integrationstests sicherstellen.

Wo genau siehst Du in diesem Szenario, in dem ein Service Locator verwendet wird, und A als Real- und B als Mockimplementierung gelten könnte, eine Gefahr?

PS: Ich arbeite derzeit nicht an einem Projekt, in dem das so eingesetzt wird, aber (nicht nur) ich wäre froh, es würde eingesetzt 😉.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von zero
Der prinzipielle Haken von Mocks ist, dass sie bereits beim Testen Lücken (entstehen) lassen (können), die sich später als überaus gefährlich erweisen (können);

Testing läßt immer Lücken. Liegt in der Natur der Sache.

Und der Aufwand steigt bei jedem Durchlauf exponenziell, wenn man in iterativer Software testet.

Warum das? Testaufwand steigt proportional zur Programmkomplexität....

Wenn man TDD schon einsetzen will, dann lässt es a) eine ganze Reihe von Optionen zu, die Tests sinnvoll zu strukturieren (Induktionstests, Deduktionstests, etc.), die man b) auch nutzen sollte.

Interessante Terminologie. Kannst du mal erklären, was Induktions- bzw. Deduktionstests ausmachen?

Dabei ist DI strikt regelbasiert - das sagt doch schon der Name. Und wer eine Regel findet, die nicht deterministisch ist, der sollte es - bei dem Glück - mal mit Lotto Spielen probieren. Einigermaßen intelligente Fallback Flows würden aber selbst diesen Extremfall auffangen können. Dennoch - ich gebe es zu -: Theoretisch besteht die Möglichkeit, dass es absoluten Zufall gibt (und in 90% der Fälle sitzt er bekanntlich vor dem Monitor). Wer dagegen testen muss, der entwickelt aber auch die traumzauberbaumschen "Steuersysteme für Langstreckenraketen" und wird entsprechende Vorsorge treffen müssen. Und sei es auch nur, dass er seine AGB erweitert. 😉

Viele Worte, aber wo bleibt die Antwort auf die Frage, wie man nicht-invasiv Testcode in die Anwendung einschiesst?

Das ist es auch. Allerdings mit veralteten Ideen. Smart Apps sind die Gegenwart.

Einmal geht es um die Konfiguration von Systemen und -familien, das andere mal ums Deployment. Sehe keinerlei direkten Zusammenhang.

Z
43 Beiträge seit 2006
vor 17 Jahren
Warte, warte, warte...

Wenn wir nur gegen I testen, wozu dann zwei (funktional differente?) Klassen?

Um zwei Vollimplementationen zu testen, müssen auch beide getestet werden. Das kann durch einen internen Schalter - ich weiß ja, was ich testen will - geschehen.

Teiltests, also A als Vollimplementierung und B als (teilimplementierten) Mock ... yep. Okay. Doch selbst dann sind im TDD vordefinierte Bibliotheken weit weniger störanfällig. Beispielsweise kann das durch definierte (und damit qualitätssichernde) Testabfolgen, die bis zum aktuellen Stadium durchlaufen werden, realisiert werden. ... Auch hier: Keine Switches notwendig.

Wo genau siehst Du in diesem Szenario, in dem ein Service Locator verwendet wird, und A als Real- und B als Mockimplementierung gelten könnte, eine Gefahr? Ganz einfach: Der externe Schalter, der es ermöglicht, dass "versehentlich" dein B-Mock rennt... Das ist eine Sicherheitslücke, so groß wie ein Scheunentor.

Weißt du, warum das Hubble-Teleskop zunächst nahezu blind war?
Man hatte übersehen, dass die Testumgebung des Spiegels eine fehlerhafte Konfiguration hatte. Logischerweise fertigte man demzufolge ein fehlerhafte Produkt an, das nur mit einem Patch (zusätzliche Linsen) korrigiert und funktionsfähig gemacht werden konnte...

Und wer seine Testbedingungen nicht sauber definieren kann, der sollte das TDD vielleicht nicht unbedingt einsetzen, denkst du nicht auch?!

Herrgott noch mal: Ihr wollt mir etwas sagen, aber ich sehe es einfach nicht.

@svenson

Testaufwand steigt proportional zur Programmkomplexität Schön wär's. Verwechsle bitte nicht den real betriebenen, mit dem theoretisch notwendigen Testaufwand.

Was meinst du wohl, warum man das "Beta"-Testen immer mehr auf die Schultern der Kunden verlagert? Weil der "proportionale" Aufwand, mit anderen Worten "die Anwendung", zu groß geworden ist, um sie ausreichend zu testen?

Kannst du mal erklären, was Induktions- bzw. Deduktionstests ausmachen? Nicht böse sein. Die Antwort lautet schlicht: Logik.

Sehe keinerlei direkten Zusammenhang. Statische/externe Konfiguration vs. dynamische/interne Konfiguration. Das ist der Zusammenhang. Jedenfalls dann, wenn wir das Ursprungsthema dieses Threads im Auge behalten wollen.

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von zero
Schön wär's. Verwechsle bitte nicht den real betriebenen, mit dem theoretisch notwendigen Testaufwand.

Wenn das deine Erfahrung ist, dann bedeutet das nur, dass in den frühen Stadien zu wenig getestet wird. Nur so wäre ein temporärer (!) exponentieller Testaufwand zu beobachten.

Nicht böse sein. Die Antwort lautet schlicht: Logik.

Genau so ist es. Deswegen würde ich gerne wissen, wie du solche Verfahren auf imperative Software anwenden willst.... oder übersetzt du deinen Code erstmal in funktionalen um ihn dann beweisen zu können? Nicht böse sein, aber Induktion und Deduktion haben nix mit Testing zu tun...

Statische/externe Konfiguration vs. dynamische/interne Konfiguration. Das ist der Zusammenhang. Jedenfalls dann, wenn wir das Ursprungsthema dieses Threads im Auge behalten wollen.

Und was hat dies nun damit zu tun, dass nur "Smart Apps" Software der Gegenwart sind - im Gegensatz zu Plugin-Vefahren?

Herrgott noch mal: Ihr wollt mir etwas sagen, aber ich sehe es einfach nicht.

Das denke ich irgendwie die ganez Zeit auch....

T
512 Beiträge seit 2006
vor 17 Jahren

@zero

Also ehrlich, statt hier meterlange Absätze darüber zu schreiben, was den Threadersteller garnicht interessiert und zu beschreiben wie schlecht das alles ist, beschreib doch mal wie man es mit SmartApps in der Gegenwart macht.

Mir fällt echt nicht die geringste Idee ein ein Pluginsystem zu bauen, ohne irgendwo in einer Konfiguration den Plugintyp anzugeben.

PS Zum Thema TDD.
Ich kenne Deduktiv und Induktiv auch nur aus der Logik, bzw. als Synonyme für Bottom-Up und Top-Down. Was das mit Tests zu tun hat weiß ich erhlich gesagt auch nicht. Wäre nett wenn du auch das mal erklärst.

e.f.q.

Aus Falschem folgt Beliebiges

4.207 Beiträge seit 2003
vor 17 Jahren

Original von zero
Wenn wir nur gegen I testen, wozu dann zwei (funktional differente?) Klassen?

Weil I die Semantik beschreibt, und sich A und B gleich verhalten müssen ... das ist schließlich der Sinn von Interfaces, verschiedene Implementierungen zu abstrahieren ...

Die beiden Klassen sind nicht funktional different, sie sind verschiedene Implementierungen der gleichen Semantik.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

Z
43 Beiträge seit 2006
vor 17 Jahren
Entschuldige, svenson...

... aber...

Nur so wäre ein temporärer (!) exponentieller Testaufwand zu beobachten. Ich gebe dir ja Recht, wenn du sagst, es wird lediglich Kosten/Nutzen-abgewogenes Testing betrieben und daraus ergäbe sich ein - mehr oder weniger - linear ansteigender, proportionaler praktischer Aufwand. Doch das hat nichts, aber auch gar nichts, mit dem (theoretisch) notwendigen Testaufwand zu tun.

Induktion und Deduktion haben nix mit Testing zu tun... Traumzauberbaum gab dir bereits die Anwort:
Bottom-Up und Top-Down Ich weiß nicht, wie du testest, aber wenn du stets alles gegen alles testen willst, hast du reichlich Arbeit zu liegen, svenson. 😉

Das denke ich irgendwie die ganez Zeit auch.... Wie wäre es dann, wenn du sagst, was du sagen willst, svenson? Das sokratesche Prinzip scheint doch offensichtlich zu versagen. Darauf herumzureiten bedeutet demzufolge, dass du a) nicht sagen willst, was du meinst, oder b) nicht dazu in der Lage bist. (Vorausgesetzt, ich muss nicht annehmen, dass du nur zu unflexibel bist, zielführendere Methoden anzuwenden.)

Und was hat dies nun damit zu tun,... Muss ich mich wiederholen, oder liest du noch?

@Golo Haas

Weil I die Semantik beschreibt, und sich A und B gleich verhalten müssen ... Definiere "Semantik".

@Traumzauberbaum

... statt hier meterlange Absätze darüber zu schreiben,... Eines Tages wirst du vielleicht auch feststellen, dass du den Informationsgehalt von Aussagen nur begrenzt erhöhen kannst. 😉

... was den Threadersteller garnicht interessiert ... ... errr ... Und? Was willst du damit sagen? Es gibt offensichtlich Leute, die diesem Thema mehr abgewinnen wollen. Auch dann, wenn es dein Vorstellungsvermögen anscheinend übersteigt.

... beschreib doch mal wie man es mit SmartApps in der Gegenwart macht. Das habe ich bereits getan, Traumzauberbaum.

4.207 Beiträge seit 2003
vor 17 Jahren

Definition Semantik: http://de.wikipedia.org/wiki/Semantik

Alternativ kannst Du von mir aus das Wort "Verhalten" einsetzen ... denn, wie ich bereits schrieb:

Weil I die Semantik beschreibt, und sich A und B gleich verhalten müssen ... das ist schließlich der Sinn von Interfaces, verschiedene Implementierungen zu abstrahieren ...

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von zero

Induktion und Deduktion haben nix mit Testing zu tun...
Traumzauberbaum gab dir bereits die Anwort:
Bottom-Up und Top-Down

Aha.

Den folgenden Satz hast du aber wohlweislich nicht zitiert:

Was das mit Tests zu tun hat weiß ich erhlich gesagt auch nicht. Wäre nett wenn du auch das mal erklärst.

Ich bewundere aber deine Methode, deine Ausführung mit einem Haufen selbsterfundener Buzzwords wie "Induktionstest" anzureichern... wirkt ungeheuer kompetent. Bevor man die inhaltliche Ebene erreicht, hat man sich in Diskussionen über Begriffsdefinitionen verfangen.

T
512 Beiträge seit 2006
vor 17 Jahren

Original von zero
Das habe ich bereits getan, Traumzauberbaum.

Sorry aber ich find die Stelle einfach nicht. Du hast nur mal kurz die Worte SmartApps und Gegenwart eingeworfen, aber danach finde ich ehrlich nichts mehr darüber. Ein Zitat oder ein Link würde mir da weiter helfen.

SmartApps ist imo genau wieder so ein sinnentleertes Marketingwort. Was sollen Smartapps sein, was sind deren Merkmale und wie hilft einem das bei Plugins weiter? Sei so nett und gib uns paar Informationen (Links z.B.) statt puren Schlagwörtern.

Tut mir leid aber das Einzige was ich aus deinen Posts mitnehme ist das Gefühl von Sand in den Augen.

e.f.q.

Aus Falschem folgt Beliebiges

Z
43 Beiträge seit 2006
vor 17 Jahren

Ich bin gespannt, worauf du hinaus willst, svenson.

Kongruent zur Änderung deines letzten Beitrags schließe ich, dass du offensichtlich doch noch einmal nachgedacht hast und den ersten Einwurf für korrigierenswert erachtetest (Ehrlich gesagt nahm ich sogar an, dass du nur "irgendwas" sagen wolltest und wollte mich gerade enttäuscht äußern.). Darf ich annehmen, dass ich, wenn ich noch länger warte, mit nochmaligen/m Korrekturen/Nachdenken rechnen kann?

buzzwords Nenne es, wie du willst, svenson. Ich erhebe (noch) nicht den Anspruch, deine Begriffswelt zu kennen, bin aber gern bereit, mich auf deine Definitionen einzulassen. Ganz offensichtlich verstehst du unter dem Begriff "Testen" ja auch nur, was physisch getan wird. Warum also nicht auch eine Reihe anderer Begriffe redefinieren? 😉 (Letztlich zählt für mich nur, dass wir wenigstens insoweit "eine Sprache" sprechen, als wir uns gegenseitig verstehen. Ich bin also gern bereit, dir so weit wie irgend möglich, entgegen zu kommen.*

Dass ich Begriffe zusammenfasse/erfinde, hat übrigens mit einer typischen Berufskrankheit zu tun: Ich werde "umgebungsblind" und rede in immer eingeschliffeneren Begriffen. Zwar mag ich TLAs nicht wirklich, aber aus "induktives Testverfahren" wird da schnell ein "Induktionstest". 😉 In diesem Sinne: Danke für den Hinweis.

(*) Nachtrag){gray}

@Traumzauberbaum

ich find die Stelle einfach nicht. Ich dachte mir sowas schon, Traumzauberbaum...

Sei so nett und gib uns paar Informationen Uns? Eure Majestät? Oder Schizophrenie?

sinnentleertes Marketingwort Das hängt davon ab, was du davon mitnimmst. "Web 2.0" ist auch nur ein "sinnentleertes Marketingwort". Oder eben eine Philosophie der Softwareentwicklung. Je nachdem, wie aufmerksam du zuhörst.

...das Einzige was ich aus deinen Posts mitnehme ist das Gefühl von Sand in den Augen. Das glaube ich dir gern, Traumzauberbaum. Ich verlange, dass man (mit-)denkt. Alles andere ist langweilig. Kein Wunder, dass du also Langeweile empfindest. 😉

@Golo Haas

... Bah! Das ist die abstrakteste aller möglichen Definitionen, die du mir da gegeben hast. Diese kenne ich auch. (Neben einer Reihe spezifischerer. Und genau das macht es mir so schwer, dir zu folgen.)

Aber wir kommen vom Thema ab. Ausgangspunkt war, wozu externe Schalter notwendig sind; nicht die Frage, wozu Interfaces nützlich sind. ... Wollen wir dahin zurückkehren? Es würde mich nämlich wirklich interessieren, wo sie nützlich sein können und nicht durch (logische) Funktionalität ersetzbar sind.

T
512 Beiträge seit 2006
vor 17 Jahren

Wunderbar, nicht der geringste Tropfen an Informationen.

Du bist nicht in der Lage auch nur eine einzige Frage zu beantworten.

e.f.q.

Aus Falschem folgt Beliebiges

4.207 Beiträge seit 2003
vor 17 Jahren

Original von zero
@Golo Haas

... Bah! Das ist die abstrakteste aller möglichen Definitionen, die du mir da gegeben hast. Diese kenne ich auch. (Neben einer Reihe spezifischerer. Und genau das macht es mir so schwer, dir zu folgen.)

Dann frag spezifischer.

Wissensvermittler und Technologieberater
für .NET, Codequalität und agile Methoden

www.goloroden.de
www.des-eisbaeren-blog.de

S
8.746 Beiträge seit 2005
vor 17 Jahren

Eliza im Coding-Modus.

M
110 Beiträge seit 2007
vor 16 Jahren

Hallo,

um mal auf das Ursprungthema zurückzukehren.

Für das Problme mit der Auswahl der Instanz gibt es einige Tools die eine Lösung bieten. Die Lösung des Problems nennt sich Dependency Injection. Das bedeutet die Abhängigkeiten von ausser über ein Framework steuern.

ein besonders gutes ist Spring.NET.

Gruss

Mirko

Mappen statt hacken mit Invist , dem .NET O/R Mapper - Code Generator