Du musst aber die Inkonsistenzen auflösen wenn die Mitarbeiter den ganzen Tag Dateioperationen OHNE Tortoise ausführen.

Hast Du schonmal mit SVN gearbeitet? Dann versuche es mal.

Es ist ungeeignet für deine Zwecke.

@1mannlan
Subversion ist vollkommen ungeeignet für dein Vorhaben.

Du willst doch nicht von den Mitarbeitern verlangen, dass jede Dateioperation über z.B. TortoiseSVN durchgeführt wird, oder?
Wenn Dateien einfach wie gewohnt kopiert, gelöscht und verschoben werden, hast Du bei jedem Commit unzählige Fehler von Hand aufzulösen -> Horror

Hallo

Muster die ich gerne verwende:

-Abstract Factory & Repository: Häufig in der Datenschicht.

-Strategy, State und Bridge: Sehr nützlich und eng verwandt. Eigentlich lässt sich die Idee dahinter ständig einsetzen um Verhalten wegzukapseln. Meine Meinung: Strategy ist das wichtigste aller Muster.

-Observer, Iterator, Mediator: events und IEnumerables, ist klar. Und jede Form ist Mediator ihrer Controls. Verwendet man also unbewusst ständig.

-Template Method: Kürzlich in einer Bildverarbeitungsbibliothek verwendet mit sehr sauberem Ergebnis.

-Visitor: Double-Dispatching ist eine faszinierende Idee um if-else-Kaskaden bei der Bestimmung eines konkreten Subtyps zu vermeiden.

-Facade: Einen Satz von Low-Level Schnittstellen hinter einer sauberen, kleinen Facade zu verstecken ist praktisch.

-Interpreter: Ein Rekursiv-Absteigender Parser eben. Sehr nützlich aber warum es ein Muster ist, ist mir rätselhaft.

-Builder: Bei einem Lexergenerator kürzlich verwendet: Regulärer Ausdruck -> NFA -> DFA. Der schrittweise Konstruktionsprozess von RA -> NFA kann damit schön weggekapselt werden.

-Command: Bei einem minimalistischen 3D-Modeller. Aus einer Mausaktion wird entsprechend irgendwelchen gesetzten Häckchen ein Command erstellt, das später ausgeführt wird. Sehr saubere Sache.

Muster die mich Interessieren aber noch nie in Produktivcode verwendet habe:

-Memento: Mangels friend-Schlüsselwort etwas schwierig zu verwenden in C# aber es geht trotzdem.

-Fliegengewicht: Schwierig zu verwenden weil man schnell den Überblick beim extrinsischen Zustand verliert und Anwendungsgebiete sind rar.

Muster die ich als unsauber oder wenig nützlich empfinde:

-Dekorator: Bei Streams z.B. sehe ich den Nutzen aber insgesamt sind Dekorierer gefährlich und hässlich. Wenn sich der Client-Code darauf verlässt, es mit dem "echten" Objekt zu tun zu haben, knallts.

-Proxy: Siehe Dekorator. Nützlich um auf Remote-Objekte transparent zuzugreifen aber selbst ist mir noch nie eine saubere Proxy-Implementierung gelungen.

-Adapter: Die Idee ist großartig aber in der Praxis ergeben sich mir zu selten Möglichkeiten einen Adapter zu verwenden. Zum Beispiel wenn eine Kamera gegen eine andere ausgetauscht werden soll und man für das neue Gerät einen Adapter entwickeln möchte. Oft hat Hardware solch individuelle Eigenschaften im zeitlichen Verhalten oder der Reihenfolge verschiedener Befehle, dass getrickst werden muss.

-Composite: Die Idee der Teil-Ganzes-Hierarchie ist toll aber in der Praxis habe ich sowas noch nie benötigt. Normale Baumstrukturen brauche ich dagegen oft. Edit: Ich bin gerade am überlegen. Ich habe mal einen Renderer für 3D-Levels (Quake3 und so) geschrieben und die Geometrie in einen Octree gepackt. Hier kommt das Teil-Ganzes-Prinzip schon zum Einsatz gegenüber einem einfachen Baum... Naja.

-Singleton: Ohne Worte.

Ich habe mir sehr schwer getan beim Lernen der Patterns (hab natürlich noch nicht alle drauf)

Patterns sind ja auch ein bockschweres Thema.

Eine große Hürde für mich waren die praxisfernen, konstruierten und teilweise hanebüchenen Beispiele in manchen Büchern. Der Transfer auf reale Probleme fällt damit schwer. Deswegen habe ich mir zu allen schwierigeren Mustern immer mehrere Quellen herangezogen und das Web durchforstet.

Das "Head First - Design Patterns" - Buch hat mir die Augen ein Stück weit geöffnet. Danach ist das GoF-Buch ein idealer Katalog.
Dringend abraten muss ich von "C# - Design Patterns". Das Buch erfasst die Kerngedanken hinter den Mustern nicht und die Beispiele sind fehlerhaft und schlecht implementiert.

Edit: Eine Million Tippfehler beseitigen 😄

Ribbons, Tiles, Webzentrierung, ... ich bin zwar erst 29 aber ich komme mit der Umstellung schon nicht mehr klar. Viel zu sehr bin ich an alte Menüleisten und spartanisches aber funktionales Design gewöhnt.

Nach 1,5 Jahren finde ich mich in Windows 7 immer noch nicht so zurecht wie damals unter WinXP nach wenigen Wochen. Alles wird versteckt und überall liegt ein Schleier darüber der dem Benutzer das Denken und Systemwissen abnehmen soll. Dass alles Quitschbunt ist empfinde ich als störend und schalte es so weit es geht aus.

Tja, ich bin wohl konservativ was Betriebssysteme und GUIs allgemein betrifft und in den 90-ern stecken geblieben.

Hallo.

So auf die schnelle für eine 2D-List von ints. Das kannst Du aber einfach ändern zu Flugzeug_Linie.

            int CollisionDistance = 1;

            List<List<int>> list = new List<List<int>>();
            list.Add(new List<int>());
            list.Add(new List<int>());

            list[0].Add(3);
            list[0].Add(7);
            list[0].Add(8);

            list[1].Add(9);
            list[1].Add(14);
            list[1].Add(15);

            var many = list.SelectMany(item => item);
            var result = from x in many
                         let collision = many.Where(y => x != y && Math.Abs(y - x) <= CollisionDistance)
                         where collision.Any()
                         select new { item = x, collisionset = collision };

            foreach (var r in result)
            {
                Console.Write("Item: " + r.item + " , Kollisionsmenge: ");
                foreach (var collisionCandidate in r.collisionset)
                    Console.Write(" " + collisionCandidate);
                Console.WriteLine();
            }

Zu jedem Item der Liste wird also die Menge der Kollisionskandidaten gefunden. Im Beispiel alle, die eine Entfernung von 1 haben (CollisionDistance = 1)

Ausgabe:

Item: 7 , Kollisionsmenge: 8
Item: 8 , Kollisionsmenge: 7 9
Item: 9 , Kollisionsmenge: 8
Item: 14 , Kollisionsmenge: 15
Item: 15 , Kollisionsmenge: 14

MfG

Schreibt ihr ständig Code, checkt ihn ein und prüft bei jeder Änderung ob das neu implementierte funktioniert? (Continuous Integration)?

Genauso, ja. Das Projekt ist relativ klein und die Übersetzung dauert nicht lange, so dass quasi alles direkt getestet werden kann.

Ich finde es ein wenig "gemein", dass man hier diese Vorgehensmodelle als "akademischen Quatsch" abtut. Mal ehrlich: hat sich hier im Vorhinein noch NIEMAND mal Gedanken über Klassendesign o.ä. gemacht? Sicher kommt das immer auf die Projektgröße an, aber ein wenig geplant habt ihr alle schon - oder programmiert ihr wirklich einfach "drauf los"?

Ich habe selbst Informatik (Uni) studiert also darf ich darüber lästern 😃

Ja ich programmiere einfach drauf los. Ich wäre bei neuen Projekten mit hunderten Klassen garnicht in der Lage es vorher bis auf Klassenebene zu entwerfen. Das entwickelt sich mit der Zeit. Ich muss "erforschen" was eine gute Lösung ist. Das geht einfach nicht im Vorfeld in irgendeinem albernen UML-Tool.
Naja, nicht ganz. Es geht doch: Genau dann, wenn man etwas sehr Ähnliches schon einmal gemacht hat. Wenn man sich zum Beispiel was die Datenschicht betrifft für ein Repository-Pattern entscheidet weiß man vorher genau, wie es aussieht, dass da eine abstrakte Fabrik sein wird u.s.w.. Aber warum sollte ich es dann noch aufmalen?
Umgegekehrt kaufe ich niemandem ab, dass er so etwas Komplexes, beim ersten mal und ohne vorher etwas ähnliches gemacht zu haben, mit UML entwerfen kann ohne zu erleben wie es sich in Code "anfühlt".

Die Aussagen beziehen sich auf kleinere und mittlere Projekte. Und da halte ich Vorgehensmodelle und Entwurfsphasen für Zeitverschwendung. Ja, akademischen Quatsch.

Code ist der eigentliche Entwurf. Das eigentlich wesentliche.
Unterstützung in Form von Code gibt es auch: Unit-Tests, Frameworks, Dependency-Injection-Container, OR-Mapper wie nHibernate.... Das sind Dinge die wirklich Helfen. Aber kein Klassendiagramm.

jannemann13 beschreibt schon sehr schön wie es wohl wirklich in sehr vielen Firmen abläuft.

Wenn ich sehr sauberen Code schreibe, Pattern verwende und penibel darauf achte gegen keine Prinzipien zu verstoßen, brauche ich drei bis viermal so lang wie für hingerotzen Durchschnittscode. Die Konsequenz ist, dass sich Änderungen und Wartungsarbeiten nicht mehr ganz so schnell und elegant durchführen lassen wie beim durchstylten Traumsystem. In der Summe bin ich trotzdem noch schneller wenn ich häufiger mal ein Auge zudrücke und gegen Lehrbuchmeinungen verstoße.

Ich verstehe die Vorgehensmodelle als hochgradig weltfremd was kleinere Projekte betrifft. Bei Monsterprojekten haben sie sicherlich ihre Daseinsberechtigung, das kann ich nicht beurteilen.

Code den ich zu Hause schreibe könnte man ins Museum stellen so sauber ist er. Auf der Arbeit muss es schnell gehen. Das Ergebnis zählt.

Vielleicht fehlt mir aber auch noch Erfahrung. Ich bin erst 1,5 Jahre "Profi".

Ich kann das Problem für Windows 7 bestätigen. Im Setup muss ich die Rechte für einen Unterordner von CommonApplicationData setzten sonst hat die Anwendung keinen Schreibzugriff.

Das dachte ich auch zuerst.
Aber so fügt er dem Dictionary ein neues Element ein.
Ich will ja dem Value des Dictionarys "List<MyClass>" eines neues Element anhängen.

Nein das ist schon korrekt.

Kunden und ihre absurden Wünsche. Ohne wär der Job doch nur halb so lustig 😄