Übung 10, Task 2

[dom]

Ist das Design der Workbench so gedacht das man den kompletten SourceCode aus src zuerst in manual kopiert dort per Constructor löst. Dann das reultierende Design in builder kopiert und das Builder Pattern anwendet. Abschließend dann wieder das Design in guice kopiert um Google Guice zu verwenden?
Müssen wir für jeden dieser Schritte eigene UML machen nebst Text in der solution PDF?

[marcel_b]

> Ist das Design der Workbench so gedacht das man den kompletten SourceCode aus src zuerst in manual kopiert dort per Constructor löst.
> Dann das reultierende Design in builder kopiert und das Builder Pattern anwendet. Abschließend dann wieder das Design in guice kopiert
> um Google Guice zu verwenden?

Ja, falls ihr das Kopieren benötigt. Mit ein bisschen Glück hast du am Ende nur eine Version der Emailer Anwendung die mit allen drei Fällen (manuell, builder, guice) funktioniert.

Falls nicht, könnt ihr eure Versionen in verschiedene Verzeichnisse legen. Die Verzeichnisse waren dafür gedacht den Code spezielle für Guice bzw. speziell für Builder etc. aufzunehmen. Wahlweise hätten es verschiedene packages wohl auch getan... Die Struktur ist nicht so wichtig. Am Ende müssen nur alle drei Versionen lauffähig in eurem Projekt liegen.

> Müssen wir für jeden dieser Schritte eigene UML machen nebst Text in der solution PDF?

Da ihr das Design eigentlich nicht verändern müsst, sollte das finale Design recht konstant sein. Wir schauen uns euer (wenigen) Klassen an, an denen ihr die jeweiligen Emailer für English und SimpleJapanese zusammensetzt. Ein UML Diagramm ist in dieser Aufgabe nicht gefordert - darf aber gerne zwecks Training gezeichnet werden


Viele Grüße
Marcel

[TheWinf]

Ü10

Aufgabe 2.2

Wo bitte genau steht denn etwas zu "dependent-on Components" ? In Folien Übung 1 kann ich leider nichts dazu finden. In den andern Folien auch nicht wirklich.

[marcel_b]

Da hat er recht Ich habe kurz nachgesehen und fegstgestellt das ich die Bezeichnung tatsächlich nie im Text voll ausgeschrieben habe. Stattdessen wurde immer nur die Standardbezeichnung "DOC" (sowie "SUT") im Text und den Bildern verwendet. Ich werde das in den Folien nachtragen. "SUT" ist bekannt?

Danke und schöne Grüße
Marcel

[_nico]

Hi,

könntest du ein kurzes Beispiel geben was genau ein DOC ist? Ich habe mir zwar die Folien aus Übung 1 angeschaut, dort stand auch oft der Begriff DOC, aber so richtig erklärt wird es nicht.

Danke schonmal

[CloneCommander]

Das wär cool

Zusätzlich möchte ich noch fragen, ob bei der Implementierung mit Guice das eine Beispiel in der vorgegebenen Klasse mit dem EnglishTextEditor und einem MailServer unserer Wahl ausreicht?

[Remake]

Und noch eine Frage: Inwiefern soll denn getestet werden? Soll einfach die Ausgabe von z.B. ConstructionWithGuice funktionieren? Das habe ich in die vorher leere main-Methode des Builders dann jedenfalls einfach auch entsprechend gesetzt..

[triality]

Ich muss mich anschließen mit zwei Fragen:

1. Wie ist Stabilität definiert?

2. Wie kann ich erkennen, welche Klasse weder High- noch Low-Level Komponente ist (meine Definitionen von diesen Begriffen sind doch sehr schwammig)?

[marcel_b]

Zusätzlich möchte ich noch fragen, ob bei der Implementierung mit Guice das eine Beispiel in der vorgegebenen Klasse mit dem EnglishTextEditor und einem MailServer unserer Wahl ausreicht?

Das Erstell bzw. das Module für SimpleJapanese wird dich wohl nicht vor nennenswerte Herausforderungen stellen, oder ? Sind es mehr als zwei Zeilen ?

[marcel_b]

könntest du ein kurzes Beispiel geben was genau ein DOC ist?

Ein SUT ist das "System under test" - d.h., das System bzw die Komponente, die du eigentlich testen möchtest. Damit diese Komponente funktioniert, musst du sie häufig mit anderen Komponenten zusammen erzeugen (ihre Abhängikeiten). Sie geben die indirekten Inputs in euer SUT oder bekommen indirekte Outputs des SUT. Lest das mit den indirekten In- und Outputs nochmal nach wenn euch nicht klar ist, wofür das gut ist. Die Komponenten sind die DOCs.

Im Fall des Emailer ist der SpellChecker eine DOC für den Emailer. Damit Emailer funktioniert und getestet werden kann, muss es eine Instanz eines Spellchecker haben. Um das Verhalten im Emailer bezüglich der Schleife und des if-statemetents zu testen, müsst ihr verschiedenen DOCs liefern - eine, die beim spell checking mal false zurück liefert und einemal einen instanz, die immer true zurückliefert. So kmmt ihr in beide Pfade in Emailer. Ist das Beispiel für Doc und indirekte inputs in das SUT damit klarer?

[marcel_b]

Und noch eine Frage: Inwiefern soll denn getestet werden? Soll einfach die Ausgabe von z.B. ConstructionWithGuice funktionieren? Das habe ich in die vorher leere main-Methode des Builders dann jedenfalls einfach auch entsprechend gesetzt..

> Soll einfach die Ausgabe von z.B. ConstructionWithGuice funktionieren?
Im Prinzip ja.

Da ihr an dem Design wenig ändert und die Logik innerhalb der Module nicht anfasst, macht hier Tests schreiben nicht übermäßig viel Sinn. Natürlich könntet ihr über die Constructor Injection einfacher testen, wie Emailer sich im Fehlerfall beim Spellchecking verhält (siehe voriges Post). Das ist mir in dieser Aufgabe aber nicht so wichtig, da ich fest von ausgehe, dass jeder von euch den Vorteil der besseren Testbarkeit (spätestens jetzt) erkennt

[baerchen]

Ich glaube nicht dass das der richtige weg ist, um mehrere Strings nacheinander mit Guice zu übergeben, aber gibt es vielleicht Punkte wegen Originalität??

Code: Alles auswählen

Provider<String> constantsProvider = new Provider<String>() {
	int counter = 0;

	public String get() {
			if (counter == 0){
				counter++;
				return "words.en.txt";
			} else 
				return "addressbook.txt";
			}
	};

	...
	bind(String.class).toProvider(constantsProvider);

Wegen Lösungen veröffentlichen und so, ich glaub wer das in seinen Code kopiert ist selber schuld

[marcel_b]

einfacher ist es wohl eine Konstante an einen Namen zu binden. Z.B.

Code: Alles auswählen

bindConstant().annotatedWith(Names.named("addressbook.path")).to("addressbook.csv");

[banshee]

Die Frage, die jetzt noch die Welt (jedenfalls meine) bewegt, ist, wieso die Dinger dependent-on Components heißen. Der SpellChecker ist eine DOC, ist also von welchen Komponenten abhängig? Müsste dann nich der Emailer die DOC sein, weil eben dieser von der SpellChecker-Komponente abhängt?

[marluwie]

Die Frage, die jetzt noch die Welt (jedenfalls meine) bewegt, ist, wieso die Dinger dependent-on Components heißen. Der SpellChecker ist eine DOC, ist also von welchen Komponenten abhängig? Müsste dann nich der Emailer die DOC sein, weil eben dieser von der SpellChecker-Komponente abhängt?

Man kann es vielleicht mit Abhängig-Von Komponenten übersetzen . Also Komponenten auf die eine Abhängig-Von-Beziehung existiert. Das suggeriert für mich jetzt der Bindestrich. Aber der Name ist ungelungen.