|
|
|
|
|
|
|
| | Sehr geehrter Herr Danzelot,
im Wintersemester 2010/11 bis Wintersemester 2011/12 werden Sie von der Gebührenpflicht nach § 3 und § 5 Abs. 1 LHGebG befreit[...] | |
|
|
|
|
|
|
|
|
|
|
Sie nennen dich tatsächlich "Danzelot", Herr  ?
Edit: Was ein dummes Komma vor dem Danzelot. 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SkunkyVillage am 24.07.2010 15:50]
|
|
|
|
|
|
|
|
|
Ich würde ja sagen, ausm Krieg. Aber wieso rennt das Kleinkind dann so unbekümmert da rum?
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Smoking am 24.07.2010 15:47]
|
|
|
|
|
|
|
|
| | Zitat von igor]2
Whoa, pubertärer Humor zum Frühstück. Ich verbringe zuviel Zeit mit Leuten, die ihre Projekte "PIM Mail" und ähnlich nennen. 
| |
Gnihihi
|
|
|
|
|
|
|
|
|
|
|
|
Experten für das Visitor-Pattern hier?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [DK]Peacemaker
Experten für das Visitor-Pattern hier?
| |
Frag einfach mal. 
|
|
|
|
|
|
|
|
|
|
|
Also ich hab eine Baumstruktur deren Aufbau klar ist, jeder Knoten darin weiß auch über den Visitor bescheid und ist so implementiert, dass es die Methode im Visitor aufruft, die zum Typen passt. Ich bereite nun eine konkrete Implementierung für den Visitor vor, bei dem ich diesen Baum auch nachverfolge.
Beispiel:
| |
| Code: |
class Element { virtual void Apply(IVisitor) { visitor.Visit(this); } }
interface IVisitor { void Visit(Element); void Visit(Book); void Visit(Chapter); }
class Chapter : Element { Apply(...) { visitor.Visit(this); }
class Book : Element
{
Apply(...) { visitor.Visit(this); }
ICollection<Chapter> Chapters { get; }
}
|
|
Dann möchte ich einen Visitor implementieren, der diesen Baum abläuft
| |
| Code: |
class Visitor : IVisitor
{
virtual void Visit(Element element)
{ }
virtual void Visit(Chapter chapter)
{
this.Visit((Element)chapter);
}
virtual void Visit(Book book)
{
foreach (Chapter chapter in book)
{
chapter.Apply(this);
}
}
}
|
|
Ich denke mir, dass es sinnvoll ist, die Visit() Methode für die Basis-Klasse auch aufzurufen, wie im Fall von Visit(Chapter), bei der ich dann Visit(Element) aufrufe. Jetzt ist das in diesem Fall sehr trivial, weil der Visitor für mich nur ein Gerüst darstellt, bei dem ich dann bestimmte virtuelle Methoden überschreiben will. Dazu 2 Fragen:
1. Sollte ich die Visit()-Methoden für die Basis-Klassen wirklich aufrufen?
2. Falls 1=Ja, sollte ich die Basis-Methode vor oder nach der Verarbeitung meiner spezialisieren Klasse aufrufen? Also im Beispiel oben, vor oder nach dem ForEach?
|
|
|
|
|
|
|
|
|
|
|
Wenn du Visit(Book) aufrufst, weißt du doch, dass du danach, dass alles eine Hierarchiestufe darunter ein Chapter ist. Warum da also noch mal einen Double Dispatch?
Wobei ich auch noch nicht ganz verstanden hab, was du vor hast.
|
|
|
|
|
|
|
|
|
|
|
|
Ich mache jetzt ein social media experiment und starte farmville!
|
|
|
|
|
|
|
|
|
|
|
Meine Antwort zu 1.: Nein
Ich sehe auch keinen Grund warum du noch eine weitere Klassen (Visitor) einbaust, die dein Interface implementiert und schlussendlich die Klasse nochmal zu erweitern.
Ich würde in deiner konkrete Implementierung (also das, was Visitor erweitern würde) einfach das Interface so implementieren wie es muss.
Andersrum die Frage an dich: Was für einen Vorteil bringt es, da noch eine weitere Klassen (Visitor) zwischen zu machen?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [Dicope]
Wenn du Visit(Book) aufrufst, weißt du doch, dass du danach, dass alles eine Hierarchiestufe darunter ein Chapter ist. Warum da also noch mal einen Double Dispatch?
Wobei ich auch noch nicht ganz verstanden hab, was du vor hast.
| |
Vielleicht noch ein Beispiel:
| |
| Code: |
Element element = new Book
{
Chapters =
{
new Chapter(),
new Chapter(),
new Chapter()
}
};
Visitor visitor = new Visitor();
element.Apply(visitor);
|
|
Daraus ergibt sich dann folgende Sequenz im Visitor:
| |
| Code: |
visitor.Visit(Book)
visitor.Visit(Chapter)
visitor.Visit(Chapter as Element)
visitor.Visit(Chapter);
visitor.Visit(Chapter as Element);
visitor.Visit(Chapter);
visitor.Visit(Chapter as Element);
visitor.Visit(Book as Element)
|
|
Fall ich mich zum Beispiel nur für Vorkommen von "Element" interessiere, würde ich sie so immer mitbekommen.
Achsel:
Die Schnittstelle IVisitor ist praktisch nur dazu da, um von einem "Element" den konkreten Typ zu ermitteln, ohne einen Cast durchzuführen.
Meine zusätzliche Implementierung ist dafür da, einen ganzen Baum durchzulaufen (Depth-First) und dabei immer den richtigen Typ des aktuellen Elements zu ermitteln. Somit ließe sich dann sehr einfach eine Xml-Serialisierung durchführen.
| |
| Code: |
class XmlVisitor : Visitor // Das ist jetzt meine Implementierung mit virtuellen Methoden
{
override Visit(Book book)
{
writer.WriteStartElement("Book");
base.Visit(book);
writer.WriteEndElement();
}
override Visit(Chapter chapter)
{
writer.WriteStartElement("Chapter");
base.Visit(chapter);
writer.WriteEndElement("Chapter");
}
}
|
|
Wenn man sich den Baum jetzt etwas komplizierter vorstellt, kann ich ihn auch nutzen, um bestimmte Elemente zu suchen und dabei nicht von Hand den Baum zu durchsuchen. Man stelle sich einen wirklich komplexen Baum vor, bei dem meine Element-Basis Klasse eine Eigenschaft "Name" hat. Und ich such nur die Elemente, die mit dem Buchstaben "X" anfangen. Dann brauch ich nur die virtuelle Methode Visit(Element) zu überschreiben.
| |
| Code: |
class StupidSampleVisitor : Visitor
{
private List<Element> elements;
override Visit(Element element)
{
if (element.Name.StartsWith("X"))
elements.Add(element);
}
}
|
|
Dies wäre zum Beispiel nicht möglich, wenn ich die Basis-Klassen nicht aufrufen würde. Dabei kennt meine "zwischen"-Implementierung ja den Aufbau aller Klassen (z.B. das Book viele Chapters hat), so dass ich das nicht duplizieren muss.
|
|
|
|
|
|
|
|
|
|
|
|
Erinnert mich mal, dass ich morgen um 5 meine Sojabohnen ernte!
|
|
|
|
|
|
|
|
|
|
|
Weil 500 Euro im Semester, die ich nicht zahlen muss.
Es sieht ansonsten aus als gehts ab morgen an den Lago Maggiore, das wird schön 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Danzelot
Weil 500 Euro im Semester, die ich nicht zahlen muss.
Es sieht ansonsten aus als gehts ab morgen an den Lago Maggiore, das wird schön
| |
Is ja mal wieder typisch! Luxusmäßig in urlaub fahren und den armen unschuldigen hart arbeitenden Bürger mit rumgetrödel an der Uni belasten!!!!1111
|
|
|
|
|
|
|
|
|
|
|
*Durchatem*
beim erstellen des Symlinks für das User-Dir hab ich eben beinahe alle User-Dirs gelöscht
Boah wasn schreck 
|
|
|
|
|
|
|
|
|
|
|
Von wegen schöne einfache Lösung. Vis Symlink das User-Dir umzuziehen ist Krieg ;(
Ich versteh nicht was sein kack Problem ist
"Die Anmeldung des Dienstes "Benutzerprofildienst" ist fehlegschlagen"
Das Benutzerprofil kann nicht geladen werden
Starte ich im abgesicherten Modus ist der symlink aber völlig funktionabel
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TriggerTG
Von wegen schöne einfache Lösung. Vis Symlink das User-Dir umzuziehen ist Krieg ;(
Ich versteh nicht was sein kack Problem ist
"Die Anmeldung des Dienstes "Benutzerprofildienst" ist fehlegschlagen"
Das Benutzerprofil kann nicht geladen werden
Starte ich im abgesicherten Modus ist der symlink aber völlig funktionabel
| |
Einen Unter-Ordner des Nutzer-Verzeichnis auswählen (nicht deinen Nutzer-Ordner direkt, sondern z.B. "Desktop", "Dokumente" oder "Eigene Musik"), rechte Maustaste->Eigenschaften. Reiter "Pfad" und dort "c:\.." durch "d:\.." ersetzen. Zwei mal "Ja" und "Amen" drücken.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [DK]Peacemaker am 24.07.2010 18:40]
|
|
|
|
|
|
|
|
|
Ich will aber, dass diese generische Lösung funktioniert:
| |
Quelle: c't-Magazin, 2010/06, Seite 10
1. Vom Installationsmedium booten und bei der Sprachauswahl "Shift-F10" drücken. Es erscheint eine Eingabeaufforderung.
2. Mit "dir" überprüfen, welche Laufwerksbuchstaben zugeordnet wurden (können sich temp. ändern!).
3. Nun wird der ganze "Users"-Ordner kopiert, z. B. mit "robocopy c:\users d:\users /mir /sec /xj"
4. Der alte Ordner wird mittels "rd c:\users /s /q" ohne Rückfragen gelöscht
5. Nun erstellt man den symbolischen Link: "mklink c:\users d:\users /j"
| |
|
|
|
|
|
|
|
|
|
|
|
userdir, symlinks, seit wann werden diese begriffe mit windows verbunden? seit microsoft denkt, sudo erfunden zu haben?
peacemaker, ich habe eine frage: bei allen geschmackssachen und religiösen diskussionen: nutzt du wirklich den IE? wenn ja: warum?
|
|
|
|
|
|
|
|
|
|
|
Schnauze voll, ich geb auf. Bleiben die scheiß Profile halt auf der kleinen Systempartition.
Wäre der Typ der Windows installiert hat nich so'n dämlicher System-Daten-Trenner, hätte ich diese 2 Stunden so schön verbringen können 
e\ Oh, einfaches "Alles wieder so machen wie es war" reicht scheinbar nicht aus
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von TriggerTG am 24.07.2010 18:59]
|
|
|
|
|
|
|
|
|
| | Zitat von flying sheep
userdir, symlinks, seit wann werden diese begriffe mit windows verbunden? seit microsoft denkt, sudo erfunden zu haben?
peacemaker, ich habe eine frage: bei allen geschmackssachen und religiösen diskussionen: nutzt du wirklich den IE? wenn ja: warum?
| |
Das hat nur in sofern etwas mit Religion zu tun, dass ich nicht gerne Software auf meinem Rechner habe, die ich nutze bzw. wo ich eine habe, die das selbe tut.
Um der nächsten Frage direkt zuvorzukommen: Der IE tut für mich alles das, was ICH von einem Browser erwarte. Wenn ich Plugins, Mausgesten etc. benötigen würde, wäre ich auch sicherlich nicht mit dem IE unterwegs. Er kommt mir nicht langsam vor, stürzt nicht ab, unterstützt Flash, keine Website, die mich interessiert, wird falsch gerendert (und die, die falsch gerendert werden, sind Demo-Pages für HTML5). Und wenn man mal meine Kriterien auf andere Browser bezieht, so wird es schwierig da zum Beispiel Geschwindigkeitsvorteile im merklichen Bereich festzustellen.
Fairerweise muss man dazu sagen, dass wenn ich irgendwann wohl mehr Zeit investieren würde, um andere Browser ausgiebig zu testen (benutzt hab ich alle schon einmal) und die Vorzüge irgendwelcher Plugins kennenzulernen, dann sicherlich auch nicht beim IE bleiben würde.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TriggerTG
Ich will aber, dass diese generische Lösung funktioniert:
| |
Quelle: c't-Magazin, 2010/06, Seite 10
1. Vom Installationsmedium booten und bei der Sprachauswahl "Shift-F10" drücken. Es erscheint eine Eingabeaufforderung.
2. Mit "dir" überprüfen, welche Laufwerksbuchstaben zugeordnet wurden (können sich temp. ändern!).
3. Nun wird der ganze "Users"-Ordner kopiert, z. B. mit "robocopy c:\users d:\users /mir /sec /xj"
4. Der alte Ordner wird mittels "rd c:\users /s /q" ohne Rückfragen gelöscht
5. Nun erstellt man den symbolischen Link: "mklink c:\users d:\users /j"
| |
| |
das ganze ist nicht ganz unproblematisch, wenn die d-Partition irgendwann mal fehlt. Ich würd eher als Administrator die einzelnen Benutzerkonten per Symlink umziehen. Also Konto erstellen, abmelden, als Admin anmelden, Dateien auf anderes Laufwerk umziehen und Symlink unter c:\users erstellen.
|
|
|
|
|
|
|
|
|
|
|
dem hab ich nur hinzuzufügen, dass das richtige rendern der webseiten eher nicht so der verdienst des mächtigen trident ist.
ich denke halt, dass viele leute so viel zeit im internet verbringen, dass es sich durchaus lohnt, hin und wieder ein stündchen das ein oder andere feature aauszuprobieren. ich versteh nicht, wie jemand z.b. „facebook login“ jedes mal googelt, anstatt sich ein lesezeichen zu setzen (wir erinnern uns).
ähnlich ists in allen bereichen des webs: wer dauernd bei rapidshare runterlädt, macht sich das leben schwer, wenn er nicht skipscreen nutzt. wer ne lahme verbindung und abneigung gegen werbung hat, hat keinen grund, nicht sofort nen adblocker zu installieren.
|
|
|
|
|
|
|
|
|
|
|
|
Es lebe die Systemwiederherstellung. Olé
|
|
|
|
|
|
|
|
|
|
|
Zu der Visitorgeschichte sind mir da ein paar Punkte aufgefallen. Ich verstehe, was du da machst und warum.
Zunaechst...
interface IVisitor { void Visit(Element); void Visit(Book); void Visit(Chapter); }
Damit deklarierst du ja schon drei verschiedene Visitormethoden, weil C# dich nicht einfach nur "Visit(Element)" definieren laesst, um dem Interface zu genuegen, sondern du dafuer immer alle drei definieren musst. Im Endeffekt koenntest du die also auch VisitElement, VisitBook, VisitChapter nennen. Du koenntest in dem Beispielcode wohl die Aufrufe von "base.Visit(book)", "base.Visit(chapter)" etc. direkt durch "VisitElement(book)" etc. ersetzen, denn im wesentlichen macht deine Visitor-Klasse ja nur einen Cast nach Element, um eine andere Funktion gleichen Namens aufzurufen. Ich sehe in dieser Gleichbenennung der drei Funktionen wenig mehr als einen Missbrauch von OO-Prinzipien, weil es eine Ableitungshierarchie impliziert, die es so an dieser Stelle nicht gibt (danke, C#-Interfaces).
Zweitens wuerde ich mich Achsel anschliessen und diese Visitor-Zwischenklasse heraustreten. Die Logik, dass z.B. bei der Visitation eines Books auch alle Chapters besucht werden muessen, gehoert m.M.n. sowieso in die Datenstruktur selbst, d.h. nach Book.Apply.
Drittens ist das, was du da eigentlich gerne haettest, nur eine Art Pattern Matching auf den Typ, also sowas hier:
public class MyVisitor : IVisitor
{
void Visit(Book b) { ... }
void Visit(Element e) { ... }
}
wo automagisch die Funktion mit am weitesten abgeleiteten, passenden Parametertyp ausgewaehlt wird. Pattern Matching auf den Parametertyp quasi. C#'s statisches Typsystem laesst das nun einmal nicht zu, aber du kannst das bei Bedarf nachbauen.
Ich wuerde empfehlen, das so aufbauen: IVisitor auf eine Methode Visit(Element) kuerzen, Visitor-Zwischenklasse ganz entfernen (Logik fuer den Durchlauf wie o.g. in die Datenstruktur schieben), und in der Visit-Methode deiner eigenen Visitorimplementierung halt bei Bedarf per Laufzeit-Typcheck gucken, welche jeweilige Unterklasse das ist. Mir ist klar, dass du wahrscheinlich ausgebildet bist, solche switch-on-type-Konstrukte zu vermeiden, aber in diesem Fall machen sie, wie demonstriert, Sinn.
Koenntest alternativ auch natuerlich noch zwei getrennte Visitorinterfaces bauen (eins fuer Elements, eins fuer Chapters/Books), aber das ist auch schon wieder... baeh.
|
|
|
|
|
|
|
|
|
|
|
Wobei wir wieder bei "...Visitor... Es dient zum Kapseln von Operationen, die auf Elementen einer Objektstruktur ausgeführt werden. Neue Operationen können dadurch ohne Veränderung der betroffenen Elementklassen definiert werden."
Wenn er also irgendwann mal vorhar verschiedene Chapter-Unterklassen zu benutzen ist das Visitor Pattern dem Laufzeit-Check überlegen
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [DK]Peacemaker
| | Zitat von TriggerTG
Von wegen schöne einfache Lösung. Vis Symlink das User-Dir umzuziehen ist Krieg ;(
Ich versteh nicht was sein kack Problem ist
"Die Anmeldung des Dienstes "Benutzerprofildienst" ist fehlegschlagen"
Das Benutzerprofil kann nicht geladen werden
Starte ich im abgesicherten Modus ist der symlink aber völlig funktionabel
| |
Einen Unter-Ordner des Nutzer-Verzeichnis auswählen (nicht deinen Nutzer-Ordner direkt, sondern z.B. "Desktop", "Dokumente" oder "Eigene Musik"), rechte Maustaste->Eigenschaften. Reiter "Pfad" und dort "c:\.." durch "d:\.." ersetzen. Zwei mal "Ja" und "Amen" drücken.
| |
Warum nur bei einem der Unterordner? Die Pfadangabe dort bezieht sich doch auch nur auf den einen Unterordner??
|
|
|
|
|
|
|
|
|
|
|
Hmm, ich hab im Moment eine funktionierende Lösung, bin aber sehr angetan von der Idee, die Datenstrukturen um die entsprechende Behandlung der Apply()-Methode zu erweitern, so dass ich mir den zusätzlichen Visitor sparen kann.
Ansonsten seh ich aber irgendwie auch keine Möglichkeit sämtliche Type-Checks zu vermeiden. Ich bin schon verrückt genug, dass ich nicht einfach direkt HTML in die Datenbank speichere, da will ich nicht auch mehr Performance verschenken.
Dann wollen wir doch mal diese "Refactoring", wo von immer alle sprechen, mal ausprobieren...
|
|
|
|
|
|
|
|
| Thema: Gehirnsalat ( wir unter uns ) |
![[dk]peacemaker](./avatare/[dk]peacemaker.gif)
![[Dicope]](./avatare/drkleiner.gif)
