In der Registry muss der Parameter -f eingefügt werden, damit nicht nur das Multidecoder Programm startet, sondern auch noch die angeklickte Datei öffnet.
Registry Pfade:
HKEY_CLASSES_ROOT\otrkey_auto_file\shell\open\command
HKEY_CLASSES_ROOT\Applications\Multidecoder.exe\shell\open\command
Zeichenfolgen Name: (Standard)
Im Wert den Parameter -f vor “%1″ einfügen.
Beispiel:
“C:/Programme/Multidecoder/Multidecoder.exe” -f “%1″
(Pfad zum Dekoder muss angepasst werden!!)
The most common criterion that I have seen used is the TNTWIWHDI or “That’s not the way I would have done it” criterion.
But there is one set of criteria that I think all engineers will agree with. A piece of software that fulfills its requirements and yet exhibits any or all of the following three traits has a bad design.
Moreover, it would be difficult to demonstrate that a piece of software that exhibits none of those traits, i.e. it is flexible, robust, and reusable, and that also fulfills all its requirements, has a bad design. Thus, we can use these three traits as a way to unambiguously decide if a design is “good” or “bad”.
Quelle: Robert C. Martin, http://www.objectmentor.com/resources/articles/dip.pdf
In einem klassisch aufgebauten OO-System ist jedes Objekt selbst dafür zuständig, seine Abhängigkeiten, also benötigte Objekte und Ressourcen, zu erzeugen und zu verwalten. Dafür muss jedes Objekt einige Kenntnisse seiner Umgebung mitbringen, die es zur Erfüllung seiner eigentlichen Aufgabe normalerweise nicht benötigen würde. Insbesondere muss es, um die entsprechenden Objekte erzeugen zu können, ihre konkrete Implementierung kennen.
Ein Implementierungsbeispiel mit dem ASP.NET MVC Framework, dem DI Framework StructureMap 2.0 in C# und etwas TDD:
http://haacked.com/archive/2007/12/07/tdd-and-dependency-injection-with-asp.net-mvc.aspx
Mehr: http://de.wikipedia.org/wiki/Dependency_Injection
Mit dem Visual Studio 2008 (Version 9) wird eine Unit Test Komponente bereits mitgeliefert. Dennoch wird oft NUnit als Komponente hinzu installiert und mit dem Add-in TestDriven.net ergänzt.
Der Microsoft Unit Test Wizard erstellt je existierender Methode das Gerüst einer Testmethode. Das dient jedoch eher Entwicklern, die ihre Tests im Nachhinein schreiben, um der Firmenvorgabe zu folgen. Um den designbestimmenden Aspekt der testgetriebenen Entwicklung zu nutzen, müssen auch bei Altanwendungen die Tests vor der Funktionserweiterung geschrieben werden.
Da Unit Tests nur auf öffentliche Klassen und Methoden zugreifen können, eignen sie sich als Test der Schnittstellen. Ein Black Box Test also. Gerät der Unit Test bei einer umfangreichen Klasse mit vielen privaten Methoden zu aufwändig, ist das ein Hinweis, dass Funktionalität in Hilfsklassen ausgelagert werden können. Dort sind die Methoden dann öffentlich und lassen sich so über einen Unit Test abdecken.
Anwendungsfälle (Use Cases) oder sehr kleine User Stories eignen sich aber grade wegen dieser Einschränkung hervorragend als Testfälle.
Auch wenn es bei TDD sehr verlockend ist, sofort drauflos zu coden, lohnt es sich vorher ein paar Minuten über das Design der Schnittstelle nachzudenken. Das deckt oft schwammige Punkte in der Anforderungsbeschreibung auf. Diesem lokalen Modell kann man sich dann mittels TDD sehr schnell nähern.
Agilität bedeutet nicht, dass man orientierungslos vor sich her entwickelt. Durch folgende Praktiken haben die verschiedennen Interessengruppen einen guten Einblick in das Projekt.
Daneben natürlich die üblichen Klassiker: