Bubble

Es gibt verschiedene Profiler-Funktionsweisen. Benötigst Du einen Profiler aus einem ganz bestimmten Grund, oder möchtest Du Dir Profiler einfach nur einmal ansehen?

Wie wäre es damit, den Tonfall zu überdenken? Und um zur Ausgangsfrage trotzdem noch eine Antwort hinzuzufügen: Es ist nicht vorgesehen, Java Programme ohne JRE auszuführen.

Die Bytes in der Datei müssen erst dem Dateiformat entsprechend interpretiert werden, bevor eine Ausgabe sinnvoll ist.

Kann man. Man kann aber auch anders auf grade/ungrade testen. Das Beste ist jedoch, dass solch ein Test, egal wie, bei der beschriebenen Aufgabenstellung völlig überflüssig ist.

Ich würde dafür ein eigenes Control erstellen. Zuerst die Datenstruktur festlegen, die die Tageseinträge verwaltet. Danach, darauf basierend, einen Renderer für die GUI des Controls schreiben. Wofür willst Du das Control einsetzen?

Was meinst Du mit angehen? Vom (grafischen) Design her? Oder wie man eine Spalte programmiert, in die Daten eingetragen werden können?

Implementiert hat sie jemand anderes, Du nutzt sie nur. Die Zeile des Quelltextes mit dem return Statement enthält zwei Fehler. Es muss dort "qMinusEins.doubleValue()" stehen, denn qMinusEins ist ein BigDecimal und muss erst in eine double Variable konvertiert werden, wenn der Multiplikations-Operator angewendet werden soll. "qhochAnzJahrMinusEins" ist hingegen bereits eine double Variable und braucht nicht mehr zu einer solchen konvertiert werden, d.h. es muss ".doubleValue()" weggelassen werden. Mit diesen Änderungen sollte der Quelltext kompilieren.

Kundennummern kannst Du grundsätzlich auch als Barcode auf ein Blatt Papier oder eine festere Karte drucken. Falls kein funktionierender Barcodescanner vorhanden ist, muss man sie eben eintippen. Daher mal eine andere Frage: Was soll das System eigentlich erreichen? Nur eine bequeme Eingabemöglichkeit der Kundennummer?

Vermutlich ist keine DirectX Runtime installiert, die Managed DirectX enthält.

Die Umsetzung soll weglassen und es sollen nur "so könnte man es vielleicht machen" Vorschläge unterbreitet werden? Warum soll die Programmierung nur den "geringsten Teil" darstellen und was ist mit Testläufen? Wie sieht es mit der Unsterstützung von Deinstallationen aus? Auch das ist wichtig. Für Windows gibt den Windows-Installer, auf dem viele Lösungen aufsetzen. Warum soll dieser zur Installation der Software auf Windows-Systemen nicht verwendet werden?

Die Datei wird vermutlich so groß, weil Du keinen Videocodec eingestellt hast bzw. die komprimierten Videodaten nicht einfach ohne Bearbeitung durchreichen lässt.

Schreibe lieber ein Programm, dass im Kontext des jeweiligen Benutzers läuft.

Noch eine kleine Ergänzung: Das ganze könntest Du zusätzlich noch mit Properties kombinieren, wenn Du lieber Properties haben willst, bei denen klar ist, dass man sie nicht verändern kann (das geht bei den Member-Variablen allerdings auch nicht, da der nötige Konstruktor privat ist), die Umsetzung (der Properties) variabel lassen willst oder Du einfach mal alle Properties ohne viel Aufand z.B. in einem PropertyGrid darstellen möchtest. Das sähe dann z.B. so aus: ... private static E e1 = new E("e1"); private static E e2 = new E("e2"); ... public static E E1 { get { return e1; } } public static E E2 { get { return e1; } } ... Das entspricht von der Verwendung her grundsätzlich der vorigen Lösung. Man könnte die Klasse zusätzlich noch als sealed anlegen, um deutlich zu machen, dass Erweiterungen zwecklos sind.

Mir ist vorhin noch eine Variante eingefallen, die Dir auch gefallen könnte. Sie ersetzt die Properties durch statische Member-Variablen: public class E : IStringProvider { private string stringToUse; private E(string useThis) { stringToUse = useThis; } public static E e1 = new E("e1"); public static E e2 = new E("e2"); public static E e3 = new E("e3"); public string MyString { get { return stringToUse; } } } Der Zugriff auf die Objekte erfolgt dann, wie gehabt, z.B. mit E.e2.

Bitte

@farmed: Das habe ich eben beschrieben.

Sind das meine Ideen nicht immer? Ja, es wird eine neue Instanz erzeugt. Es ist aber die Frage, ob es sich wirklich lohnt, hier anders vorzugehen. Vielleicht wird es ja ohnehin optimiert. Willst Du es denn in einer performancekritischen Schleife verwenden? Wenn Du trotzdem möglichst selten ein Objekt der Klasse D erzeugen möchtest oder einfach mal eine andere Vorgehensweise testen willst: Du könntest (ohne associative array) die einzelnen Instanzen selbst cachen und sie nur dann erzeugen, wenn noch keine existiert, d.h. beim jeweils ersten Abruf eines Properties. Pro weiterem Property Aufruf wäre es dann nur die nötige if-Abfrage (ob die Instanz bereits existiert), sowie der Zugriff auf die gespeicherte Instanz des Objektes. Die Instanzen blieben jedoch bis zum Programmende im Speicher, da ständig eine Referenz auf sie gehalten wird, wenn Du dagegen nicht noch zusätzlich etwas unternehmen willst.

Du musst nicht zwangsläufig mit dem statischen Array arbeiten, wenn Du Angst hast, dass etwas durcheinander gerät. Du könntest stringToUse als String festlegen und die Properties dann ein Objekt mit dem passenden String erstellen lassen. Das sähe dann beispielsweise so aus: public class D : IStringProvider { private string stringToUse; private D(string useThis) { stringToUse = useThis; } public static D d1 { get { return new D("d1"); } } public static D d2 { get { return new D("d2"); } } public static D d3 { get { return new D("d3"); } } public string MyString { get { return stringToUse; } } }

Noch eine Anmerkung: Diese Vorgehensweise verhindert natürlich nicht, dass jemand anderes ebenfalls die Schnittstelle implementiert und so doch andere Strings an foo übergibt. Nur der Aufwand steigt.

Wie wäre es hiermit? Das sollte Deinen Wünschen doch weitgehend entsprechen. Beim Verwenden würde ich die Properties (d1, d2, d3) in meinem Beispiel allerdings durch Methoden ersetzen, da ich es unschön finde, bei einem Zugriff auf eine Property ein neues Objekt zu erstellen, das ist IMO in einer Methode schöner aufgehoben. class Program { public interface IStringProvider { string MyString { get; } } public class D : IStringProvider { static private string[] someStrings = { "d1", "d2", "d3" }; private int stringToUse; private D(int useThis) { stringToUse = useThis; } public static D d1 { get { return new D(0); } } public static D d2 { get { return new D(1); } } public static D d3 { get { return new D(2); } } public string MyString { get { return someStrings[(int)stringToUse]; } } } static void foo(IStringProvider a) { Console.WriteLine(a.MyString); } static void Main(string[] args) { foo(D.d1); foo(D.d2); foo(D.d3); }

Und warum sollen die Strings statisch sein?

Ausgehend von dem ersten Ansatz, habe ich ein Beispiel entworfen. Irgendwie sind Deine Ansätze bzw. Beispiele aber alle recht unterschiedlich. Was möchtest Du denn, unabhängig von einer Implementierung, erreichen? Wenn nötig, beschreibe es einmal genauer, vielleicht sollte man das Problem besser anders angehen. Das Beispiel: class Program { public interface IStringProvider { string MyString { get; } } public class A : IStringProvider { public static string a1 { get { return "a1"; } } public string MyString { get { return a1; } } } public class B : IStringProvider { public static string b1 { get { return "a2"; } } public string MyString { get { return b1; } } } static void foo(IStringProvider a) { Console.WriteLine(a.MyString); } static void Main(string[] args) { foo(new A()); foo(new B()); } }

Erzeuge doch einfach eine Instanz, was spricht dagegen?

Du könntest ein Interface definieren, dass die Klassen (im Beispiel A und implementieren müssen.

Verkettete Listen und Arrays sind unterschiedlich: Auf die Elemente eines Arrays kann in beliebiger Reihenfolge in O(1) zugegriffen werden.