Ab heute werden alle Threads automatisch geschlossen und müssen erst durch einem Moderator explizit geöffnet werden. Nach jeder neuen Antwort wird ein Thread automatisch sofort wieder geschlossen.
Um ehrlich zu sein - ich glaube, der Unterschied wäre in einigen Threads und bei einigen Moderatoren kaum spürbar ... SCNR
Ich würde mir irgendein Konzept im Detail erklären lassen - zum Beispiel die Garbage Collection: Was sind Generationen? Wann wird collected? Was ist ein Finalizer? Warum sollte man Finalizer - wenn möglich - vermeiden? Was ist die FReachable-Queue? Wie findet der GC die zu entfernenden Elemente?
Also einfach Dinge, von denen ich davon ausgehe, dass sie ein 08/15-Programmierer nicht kennt, aber die ich von einem wirklich guten Entwickler erwarten würde.
Außerdem würde ich ihm eine Aufgabe stellen, die ihn herausfordert, um zu sehen, wie er arbeitet. Das sagt IMHO mehr aus als das reine Wissen.
ZB: Schreibe eine Methode, die einen String umkehrt - ohne Schleifen zu verwenden, und ohne die String.Reverse-Methode zu verwenden. Und dann: Performance messen und optimieren. Kommt derjenige zB auf die Verwendung von Tail Recursion? Wie geht er mit der Aufgabe überhaupt um? Legt er direkt los? Plant er? Googlet er? ...?
Anscheinend nicht, sonst kämen ja nicht immer wieder verschiedene Nachfragen ;-).
Deine Aussage
Zitat
Aber EBC 2.0 halte ich einfach für so krank, dass ich darin nicht den mindesten Aufwand investieren werde. Das ist für mich ein tot geborenes Kind. Ich habe es bisher vermieden, das so deutlich zu sagen. Aber dein Beitrag zwingt mich dazu, offen zu legen, warum ich mich in diesem konkreten Fall auf keine Diskussion einlasse. Jede Beschäftigung damit ist in meinen Augen verlorene Zeit.
Damit sollte jetzt wirklich alles klar sein.
hast Du (anscheinend nicht nur) für meinen Geschmack immer noch nicht begründet - was genau findest Du denn "so krank"?
@ Arithmetik: Jups, kann mich da Peter nur anschließen. EBCs erfordern ein Umdenken in Richtung streambasierter Datenverarbeitung, aber hey, auch die OOP hat ein Umdenken erfordert. TDD ebenfalls. Funktionale Programmierung erfordert ein Umdenken. Na und?
EBCs haben diverse sehr deutliche Vorteile, der wichtigste aus meiner Sicht ist die extreme Entkopplung. Die Eignung für TDD & Co sind daraus eigentlich nur Folgen.
Aber wie Ralf ja schon angeboten hat: Wer Zweifel hat und ein ehrliches Interesse an einem Vergleich, ist herzlich zu einem "Shootout" eingeladen.
(Wetten das dieser Beitrag gleich gelöscht ist? *fg*)
erstaunlich, es steht noch drin .... normalerweise hätte ich darauf nämlich auch gewettet ;-).
Übrigens kann ich mich Deiner Meinung nur anschließen:
@ herbivore: Ralf ist im Gegensatz zu Dir sachlich geblieben, und Formulierungen wie "krank" empfinde ich in diesem Zusammenhang als leicht "krank" ... Ralf kommt ja nun auch nicht daher und behauptet, mit den EBCs das Beste seit der Erfindung von geschnittenem Brot gefunden zu haben. Er hat ja nun schon mehrfach darauf hingewiesen, dass er an Erkenntnisgewinn und Erfahrungsaustausch interessiert ist.
Dass Du das so abblockst - schade. Zumal die Gründe zumindest für mich nicht wirklich nachvollziehbar sind (Argumente sehen für mich anders aus), mit "ich finde das krank" kann ich ja alles aushebeln und mich einer Diskussion entziehen.
Und was genau Du für ein Problem mit EBCs hast, wo Du die Nähe zur prozeduralen Programmierung siehst - das habe ich zumindest leider noch nicht verstanden, weil außer ein paar flapsigen Kommentaren keine wirkliche Antwort von Dir auf die Fragen kam.
Der PC war doch eh noch nie *DIE* Spieleplattform schlechthin, es war immer die Plattform Nummer 2.
Die Nummer 1 waren:
- C64, Amiga 500, ...
- Parallel dazu NES, SNES, Atari 2600, ...
- Danach Nintendo 64, GameBoy, PS, ...
- Danach XBox, GameCube, GameBoy Color, PS2
- Inzwischen XBox 360, PSP, PS3, Wii, ...
Je komplexer Spiele werden, und je exakter die Steuerung sein muss, desto eher fand man die Spiele auf dem PC. Und das wird sich auch nicht ändern, da alle anderen Plattformen wesentlich beschränktere Eingabemöglichkeiten haben.
ABER: Der PC wird IMHO auch nie die Nr. 1 werden ...
Naiv gefragt: Wo liegt das Problem, in der Astaro-Software für Dich bzw Deine IP Zugriff auf die entsprechende Domain zuzulassen?
Wenn Du die Erlaubnis hast, wird es organisatorisch ja wohl kein Problem sein, und ich kenne die Astaro-Software nun nicht, kann mir aber kaum vorstellen, dass man so was nicht gezielt freigeben können sollte?
Und was das ursprüngliche Beispiel angeht: Hier geht es um zwei Aktionen: Auslesen eines Wertes, und dann den Index erhöhen. Wenn das doch zwei Aktionen sind, warum sollte ich die krampfhaft in eine Zeile zusammenziehen? Das trägt IMHO ebenfalls nicht zur Lesbarkeit bei.
Es ist schon die große Frage, warum x++ so verbreitet ist, obwohl so gut wie alle Analogieüberlegungen für ++x sprechen.
Weil die Analogieüberlegungen in der Praxis in diesem Fall irrelevant sind. In den meisten Fällen (Schleifen zB oder obigem Beispiel) ist es nämlich egal, welche Variante genutzt wird.
Genauso wie die Frage, wie man es nun an sich macht, letztlich irrelevant ist. Die Codequalität wird dadurch nicht besser oder schlechter. Die Performance ist nicht besser oder schlechter. Per se ist auch nicht die Lesbarkeit besser oder schlechter.
Der Punkt ist einfach: Es hat sich halt so etabliert, vermutlich, weil die meisten Beispiele für Schleifen mit i++ und nicht mit ++i arbeiten, und weil C++ nun mal C++ heißt und nicht ++C, und dabei ist es dann einfach geblieben.
Natürlich kann man jetzt lang und breit argumentieren, warum, wieso, weshalb man das doch anders machen sollte - aber mal ganz ehrlich: Wozu?
Genauso gut könnte man darüber diskutieren, ob man bei einer Eigenschaft erst get und dann set oder erst set und dann get implementieren sollte. Das ist genauso egal. Fakt ist aber, es hat sich so eingebürgert, erst get, dann set - warum sollte man es da nun anders machen, auf die Gefahr hin, Missverständnisse drastisch zu erhöhen?
also ich muss mich da auch Peter anschließen - ich finde die Variante mit Postfix und in zwei Zeilen ebenfalls lesbarer.
Ist die Postfix-Schreibweise verbreiteter als die Präfix-Schreibweise. Postfix sind die meisten Entwickler gewohnt, Präfix nicht. Verwendet man nun Präfix, was ja durchaus einen semantischen Unterschied macht, läuft man Gefahr, dass die Lesbarkeit des Codes leidet. Insofern würde ich Präfix nicht einsetzen.
Und was das ursprüngliche Beispiel angeht: Hier geht es um zwei Aktionen: Auslesen eines Wertes, und dann den Index erhöhen. Wenn das doch zwei Aktionen sind, warum sollte ich die krampfhaft in eine Zeile zusammenziehen? Das trägt IMHO ebenfalls nicht zur Lesbarkeit bei.
Die Argumente für Präfix waren zwar viele, aber sonderlich überzeugend haben sie auf mich auch nicht gewirkt.
Geht auch mit einer Extension-Method, die die zu Grunde liegende Liste verändert und ohne ToArray o.ä. auskommt:
using System;
using System.Collections.Generic;
namespace ListAdd
{
public class Program
{
public static void Main()
{
var list = new List<int>().AddItem(23).AddItem(42);
foreach(var item in list)
{
Console.WriteLine(item);
}
Console.ReadLine();
}
}
public static class ExtensionMethods
{
public static IList<T> AddItem<T>(this IList<T> source, T item)
{
source.Add(item);
return source;
}
}
}
Einziger Haken: Sie kann nicht Add heißen, weil der Compiler sie dann findet (IntelliSense interessanterweise allerdings schon ;-)).
der Lösung mit der Basisklasse würde ich den Vorzug geben, wobei die Basisklasse für meinen Geschmack noch abstract sein sollte.
Begründung Nr. 1: Die Basisklasse erfüllt keine "eigene" Funktionalität, es geht nur um das Auslagern von gemeinsamem Code. Insofern ist eine Basisklasse - zumal abstract - hierfür IMHO in diesem Fall die richtige Wahl.
Begründung Nr. 2: Helper-Klassen sind mir immer suspekt. Helper-Klassen haben oft so eine Aura der Art "Ich wusste nicht, wo ich das Zeug sonst hinpacken sollte".
Aber mal ganz abgesehen davon: Warum nicht per DI auflösen? Dann hättest Du das Problem gar nicht.
Nein, das gleiche kannst Du mir nicht vorhalten, weil:
ich mich seit rund einem dreiviertel Jahr intensiv mit Unittests und TDD beschäftige
von Dir keine einzige relevante Quelle kam, die Deine Meinung bestätigt hätte
ich beide Seiten aus eigener Erfahrung kenne, so wohl das Testen von privatem Code als auch der Verzicht darauf
ich lernfähig bin, was TDD angeht, das habe ich öffentlich genug bewiesen, indem ich über meine eigenen Fehler und meine daraus gezogenen Lehren geschrieben habe
ich mich vor 9 Monaten geäußert habe, dass Unittests und TDD vollkommen überbewertet seien, mir was anderes gesagt wurde, und ich mir das dann zu Herzen genommen habe
All diese Punkte fehlen bei Dir. Insbesondere den letzten vermisse ich.
So lange Du es nämlich nicht anders kennst und Du es nur von vornherein verurteilst, ist es schwierig, zu argumentieren - weil was will man gegen "Ich find das aber gut so" schon groß sagen?
Letztlich musst Du das nicht tun. Wie gesagt, wenn Du glücklich so bist, dann bleib dabei. Nur das dann als allgemeingültiges Gesetz der Form "Es spricht nichts dagegen, privaten Code per Reflection zu testen" zu erheben, wenn alle Welt was anderes sagt, das ist ein bisschen vermessen ...
Offensichtlich hast Du weder MVVM verstanden, noch hast Du das Problem mit der Reflection verstanden. Mit TDD hast Du Dich nach eigener Aussage noch nicht groß beschäftigt, und Unittests sind für Dich nach eigener Aussage noch relativ neu.
Man kann Dir zum Thema "privaten Code testet man nicht" als Quelle vorsetzen, was man will - Du siehst den Vorteil in den Accessoren als so überdramatisch wichtig an und ignorierst sämtliche Hinweise, dass an Deiner Testvorgehensweise etwas falsch sein könnte. So wie Du es beschreibst, hast Du auch nicht verstanden, wie das Testen in VS funktioniert bzw wie die Codecoverage arbeitet.
Da Du aber offensichtlich nicht gewillt bist, es Dir auch einfach mal anzugucken, und Deine bisherige Vorgehensweise für das Nonplusultra hältst, mit der Du sehr gute Architekturen baust und anscheinend ja perfekt getesteten Code entwickelst - was will man da noch sagen? Da fehlen mir irgendwann einfach die Worte.
Teste so, wie Du es für richtig hältst. Viel Erfolg damit.
@ CSL: Nein, ein TabControl gehört in die View. Weil es ein Control ist, das etwas anzeigt. Genauso gehören die Buttons zum Blättern in die View, weil sie die UI-Elemente darstellen.
Logik zum Weiterblättern ist nichts sichtbares und hat damit auch nichts in der View verloren, weil es eben keine UI, sondern UI-Logik ist. Deswegen gehört so was ins ViewModel.
Natürlich kannst Du es anders machen.
Es ging darum, für Dein konkretes Beispiel zu zeigen, dass es sehr wohl möglich ist, privaten Code so in eine andere Klasse als öffentlich zu verlagern, dass er gut testbar wird. Dass dem so ist, habe ich Dir mit MVVM gezeigt. Dass Du das nicht machen willst, ist Deine Sache, es ging ja aber darum zu zeigen, ob es denn überhaupt möglich wäre. Das habe ich gezeigt.
Du hast geschrieben, dass Du Dich mit Unittests noch nicht all zu lange befasst, und TDD für Dich noch relativ neu ist. Das ist okay, jeder fängt mal an. So lange ist es bei mir selbst ja auch noch nicht her.
Du siehst keine Vorteile im Nicht-Testen von privatem Code. Das ist okay, das ist Deine derzeitige Meinung. Du hast es aber - zumindest schien mir das so - auch noch nie wirklich anders versucht, bügelst es aber von vornherein als sinnlos ab, weil Du keine Vorteile siehst. Das finde ich schade. Denn manchmal erkennt man die Vorteile erst, wenn man es einmal eine Weile lang versucht hat.