lilith2k3

Wie sähe denn der "andere Ansatz" konkret aus? Wir können ja mal ein konkretes Beispiel durchspielen. Ich fang mal an und Du kannst mir ja Verbesserungsvorschläge geben: Konkretes Szenario: Lagerverwaltung (nicht, dass ich derzeit eine entwickeln muss *g*). Es gibt Lagerhallen (L1,L2,L3,L4 etc.), Gänge (01,02,03,04 etc.), Regale (01,02,03,04 etc.), Regalreihen (01,02,03,04 etc.) Fachnummern (01,02,03,04 etc.). Für einen Lagerort bedeutet das, das er eindeutig durch einen 5-Tupel aus den Mengen gekennzeichnet ist: L101010101 wäre quasi der erste Lagerort im Lager 01. Folgendes Anwendungsszenario: Der Benutzer möchte das Lager initialisieren. Er möchte gern in einer Bulk-Operation das Lager von L101010101 bis L110101010 vorbereiten. Das kann alles im Frontend geklärt werden. Die Operation wird mittels POST an einen REST-Endpunkt übermittelt. Dort ist auch mein konkreter Ausgangspunkt oder das, was ich als "Oberfläche" bezeichne. Dort findet ein Aufruf statt, der sich in etwa so liest: LagerverwaltungsService.erzeuge(Lagerorte); Fertig. Im Lagerverwaltungsservice befindet sich folgendes Transaktionsskript: MassenJobValidator.validiere(Anforderung) ... [/php] Dort kommt es schon zu einer Reihe von ungewünschten Zuständen: 1) Die Range ist komplett verkehrt herum - also alle Angaben auf "von" sind größer als alle Angaben von "bis" 2) Es gibt diverse Maxima, die nicht überschritten werden dürfen. 3) Lagerorte sind unbekannt (e.g. "Ö1" gibts nicht, das wäre ein Tippfehler) Dafür habe ich jeweils eigene Exceptions. Entweder liefert der Validatorservice ein "True" oder es fliegt eine entsprechende Exception. Und "Nein!", ich finde [i]return[/i]-Values unzweckmäßig. Returns können ignoriert werden, Exceptions nicht. Des weiteren im Skript: [php] ... Lagerort ort=generiereLagerOrt(); ... Lagerort generiereLagerOrt(){ Lagerhalle halle=LagerHallenService.holeHalleMitId(hallenId); if(Lagerhalle==null) throw new AmArschKeineLagerhalleDaException(); return Lagerhalle } Und dergleichen mehr. Also quasi gibt es hier einen Haufen Exceptions, die ich zur "intelligenten" Fehlerbehandlung eingebaut habe. Wie sähe denn ein gegenentwurf aus?

Ja. Ich liebe diese Stacktraces:rolleyes: Aber genau um sowas geht es mir. Warum führt man das Programm nicht weiter aus? Beispiel: Exceptions zur Validierung... Illegale Objektzustände können so vermieden werden. Es kommt zu einer Validierungsexception und nach einer Benutzerinfo geht's wieder weiter im Programm. Oder Mehrstufiges Beispiel: SQL-Exception wird im DAL gefangen und in einer "DatabaseException" gekapselt und weitergereicht. Auffangen könnte man die an der "Oberfläche" und den Benutzer informieren, dass die Datenbank schrott ist, oder man fängt sie im Service-Layer auf und packt nochmal eine Service-Exception drum, die dann letzten Endes auch wieder an der Oberfläche ankäme, wo sie ähnlich behandelt würde. Allerdings hätte man das Designprinzip für Layer insoweit verletzt, als dass ein Layer nur einen Anknüpfungspunkt zum nächsten darunterliegenden haben sollte. Fachlich gesehen gebe ich Dir recht; umgangssprachlich ist logging auch eine Art der Behandlung Es ging darum, den Fehlerfall zu dokumentieren. Und nicht in jedem Fall ist ein Programmabbruch bei einer Exception nötig, vorallem, wenn es sich um Custom-Exceptions handelt. Aber es könnte dennoch wert sein, den Benutzer darüber zu informieren, oder?

Das kann man so überhaupt nicht beantworten. Es gibt mathematisch keinen Grund wieso ein 10 Zeichen Passwort mit Sonderzeichen stärker (die Entropie höher) sein sollte als ein Passwort ohne Sonderzeichen. Der Zeichenvorrat ist der gleiche; nämlich alle Zeichen inklusive Sonderzeichen. Ein Unterschied macht die Information für einen Angreifer, dass keine Sonderzeichen in Benutzung sind. "HOSENKNOPF" ist genauso sicher wie "H0$3NKN04F". Ein Unterschied macht an der Stelle die Information, dass es sich um ein zusammengesetztes Wort der Deutschen Sprache, bzw. dass es sich lediglich um Großbuchstaben handelt. Arbeitet der Angreifer mit einem Wörterbuch, so wäre es denkbar, dass letzteres Passwort länger stand hält. Das hat aber nichts mit der eigentlichen Stärke, sondern mit dem Aufbau des Wörterbuchs zu tun. Nur weil ein Passwort Sonderzeichen enthält, ist es nicht per se sicherer; aber sicher ist es schwerer zu merken

Das ist nicht der Punkt des Comics.

Ich nehme dieses Zitat mal als Ansatzpunkt, meine Problemstellung weiter zu beleuchten: Behandeln (im Sinne von "abfangen, Fehler loggen und ggf. Fehlermeldung generieren") kann ich die Exception in jedem Layer. Es ist die Frage, ob ich für jeden Layer eigene Exceptions generieren und werfen soll, oder ob ich alle aufkommenden Exceptions -egal von wo- im Controller fange und letztlich nur noch eine Fehlermeldung an den Benutzer mache.

Das sagt eigentlich alles :]

Hallo, zunächst eine Entschuldigung an den Mod, der evtl. das Thema verschieben darf, weil hier nicht der geeignete Ort ist. Es hat nichts mit Algorithmik per se zu tun. Aber mir ist echt auch nach 5 Minuten kein Subforum eingefallen, wo ich das Thema hätte anlegen können. Soetwas wie "Softwarearchitektur" oder so gibt es ja leider nicht. Zumindest hab ich sowas nicht gefunden Meine Frage ist im Grunde eine philosophische und es gibt natürlich kein Patentrezept - das ist mir klar. Aber ich möchte mir zumindest Meinungen und Rat einholen. Es geht darum, dass viele Softwareprojekte eben sogenannte "n-tier" oder "Multilayer" Anwendungen sind. Zur Diskussion vielleicht folgendes Beispiel aus meiner Praxis: Ich habe eine Webanwendung, die per REST Daten an's Backend liefert. Das ganze wird mittels MVC-Framework realisiert (welches, ist in dem Falle ja mal egal). Das heißt, nach dem Dispatching schlagen die Daten im Controller auf. Der Controller reicht die Sachen an den Service-Layer weiter. Der Servicelayer seinerseits kümmert sich um die Validierung der Daten. Anschließend werden die Daten im DAL (Data-Access-Layer) zum Persistieren aufbereitet. Die Frage, die sich nun stellt: Wo schmeiße ich welche Exceptions und wo fange ich die wieder auf? Bisher werfe ich Validierungsexceptions im Service-Layer und fange sie im darüberliegenden Layer (also dem aufrufenden Controller), wo die Sachen darüber hinaus auch weggelogged werden. Aber was mache ich beispielsweise mit Exceptions aus dem DAL? Fange ich die im Service-Layer ab und werfe von da ausgehend eine für den Layer eigene Exception? Also quasi: ich fange eine SQL-Exception im Data-Layer und packe eine "Data-Layer-Exception" drumrum. Anschließend fange ich die Exception im Service-layer und packe eine "Service-Layer-Exception" drumrum und schmeiße die wieder weiter nach oben .Oder lasse ich alle Exceptions einfach "hochbubblen" und fange die im obersten Layer ab? Fachlich richtiger wäre es wahrscheinlich die Exceptions im entsprechenden Layer aufzufangen, aber andererseits hat man dann einen Rattenschwanz an Exceptions. Das kann ja schnell Inflationär werden. Bin gespannt auf die Diskussion.

Ich würde den Admin fragen.

Äh...? Moment... Zu irgendeinem Zeitpunkt der Anwendung wird die Listbox doch auch gefüllt, oder? Das heißt, es gibt irgendeine Repräsentation dessen, was in der Listbox drinsteht. Also warum so kompliziert? Befrage doch Deine Repräsentation :]

Für die Berufsschule. Sonst hätte sie Ihre Daseinsberechtigung ja verloren, wenn es eine "Schule" ohne Noten wäre. Aber soviel "Schule" das ist, soviel zählen auch die Noten ...

Kurz und knackig meine 2Cents: Wayne? Wenn Du Dich bewirbst, ist (großes) Interesse vorauszusetzen; und das Du Dich bewirbst, ist denen auch klar. Bitte streichen. Unglücklich formuliert. Statt Deine Fähigkeiten herabzusetzen, solltest Du einfach sagen, dass Dir das Studium zu langweilig ist und Du mehr Programmieren möchtest. Aua. Sowas um Gottes Willen weg lassen. Wie zum Beispiel? Kompetenz? Woher nimmst Du die denn? Besser: "Ich stehe Ihnen für ein persönliches Gespräch zur Verfügung".

Global Assembly Cache wäre ein geeigneter Ort für eine solche Datei "globalen Interesses". Ansonsten schließe ich mich meinem Vorredner an.

Wer programmiert denn sowas heutzutage noch selbst? Wenn Du C++ nutzt, dann wirf mal einen Blick in list - C++ Reference oder für C SGLIB - A Simple Generic Library for C. Und für den Rest, bitte Code-Tags benutzen und das Problem genau formulieren :]

Das Buch hätte schon längst verboten werden sollen. Und die Aufgaben, welche das abpinnen von Infos aus dem Handbuch verlangen, gehören gleich mit verboten!

Ich kann sehr gut verstehen, was für Schwierigkeiten Du hast. Im Grunde hatte ich gegen Ähnliches anzukämpfen; meine Ausbildung habe ich im Themenumfeld von Microsoft Dynamics CRM gemacht (Kundenbeziehungsmanagement). Fachlich gesehen hat mich das Teil nicht die Bohne interessiert; dennoch kam ich nicht umhin, mich auch mit der "Problemdomäne" auseinanderzusetzen. Ich durfte mir das entsprechende Vokabular aneignen - musste Lernen, was ein "Lead" ist, was eine "Opportunity" ist und dergleichen mehr. Andererseits fand ich das System als solches, technisch interessant und konnte mich sehr gut einarbeiten. Besonders spannend fand ich das Thema "Integration" (was dann auch in meiner Abschlussarbeit Thema war), also die Anbindung oder Verbindung zwischen mehreren Systemen: Beispielsweise auch an ein SAP-System. Was heißt denn in dem Fall "kaufännisch"? Im Grunde hast Du nach Abschluss eine solide Ausbildung und kannst überall eine Anstellung finden. Mit SAP und Microsoft bist Du ganz gut aufgestellt. Das ist doch ein Lichtblick. Andererseits, wenn es Dir schwerfällt, Dich zu motivieren, ist die Frage, ob Du überhaupt bis zum Ende durchhälst ... Was ich zwar verstehen könnte, aber was schade wäre.

Ich hatte auch schon so ein Gespräch im "Irrenhaus". Bin aufgestanden, habe mich bedankt und bin gegangen.

@Flash So war das ja nicht gemeint Obwohl es nicht in jedem Falle schädlich ist, noch ein bisschen mehr RAM zu haben... In dem Fall wäre evtl. zu überlegen, ob Java die richtige Sprache ist. Damit wäre Java vom Tisch. Es geht ja mir ja nicht darum zu sagen, dass Speicherplatz heute kein Problem darstellt, sondern ein für viele Bereiche nicht besonders relevantes Problem darstellt. Und es gilt eben auch die Rechnung zu machen, wie ich eben angedeutet habe, was billiger wird: Entwicklerzeit oder Speicherbausteine. Und wenn ich meinen Tagessatz sehe, dafür kann man eine Menge an RAM-Riegeln kaufen. Btw. gibt's einen netten Vortrag von Herb Sutter, der gleich zu Beginn 3 schlagende Argumente für C++ bringt: C++ ist am besten dort, wo Performance/$ gefragt ist - performance / watt (datacenter), performance/Transistor, Performance/Cycle. C++ and Beyond 2011: Herb Sutter - Why C++? | Channel 9 Im Umkehrschluss heißt das: wo diese Faktoren vernachlässigbar sind, ist auch C++ vernachlässigbar.

Warauf Du hinaus willst mit Deinem Argument verstehe ich zwar, aber a) Ist das gängige Praxis. Programme haben Mindestvoraussetzungen. Von wieviel RAM reden wir hier eigentlich? Im embedded Bereich kann es wirklich speicherkritisch werden. Aber im Desktop-/Serverumfeld glaube ich das kaum. Vorallem wird's easy, wenn man es eh mit VMs zu tun hat, wo man schnell den Speicher hochschrauben kann.

Ich verstehe nicht, warum es als "Wert" per se angesehen wird, wenn man weiß, was Pointer sind und wie sie funktionieren. Genausoweig verstehe ich, warum man sich um den Speicherverbrauch seiner Anwendung kümmert sollte. Es gibt den Fall, dass man für den embedded Bereich coden muss: für diesen Zweck verstehe ich das. Aber frei nach Uncle Bob: Why do you care as a Java developer about Memory, you are using Java ... Wir leben nicht mehr im Jahr 1982. Wenn der RAM nicht reicht, schiebt man noch einen Riegel nach. Das wird billiger als die Entwicklerzeit, speichereffizient zu programmieren, bzw. das Programm noch weiter zu optimieren. Und da die wenigsten im embedded Bereich anfangen, wäre es in meinen Augen verbachlässigbar, mit der "Speicherverwaltung" anzufangen. Dass es sinnvoll ist, sowas zu lernen steht ja ausser Frage. Aber anfangen muss man ja deswegen nicht gleich damit, oder? (Ja. ich habe damit angefangen, würde es heute allerdings nicht mehr tun)

So könnte man das zusammenfassen *g*

Nein. Dazu gibt es Referenzen. Ja. Irgendwie ein Programm zu fabrizieren kann jeder lernen. Spannend wird es, wenn man eine Sprache auf ideomatischer Ebene beherrscht. Und da unterscheiden sich die Sprachen eben extrem. Und die eine Sprache benötigt bestenfalls lediglich mehr Boilerplatecode als die andere; schlimmstenfalls sind gewisse Arten der Programmierung -oder etwas metaphorisch: gewisse Arten, sich auszudrücken- nicht möglich. Was wäre das Äquivaltent zu List Comprehensions aus Python in C++? Kann man in C++ überhaupt ein ähnlich lesbaren Code schreiben? Man könnte auch sagen: wer alle Sprachen beherrschen will, beherrscht letzlich keine. Nur, weil man in der Lage ist, "Hello World" in jeder Sprache mit mehr oder minder dem gleichen Aufwand zu schreiben, heißt das nicht dass man alle Sprachen gleich beherrscht, bzw. dass die Sprachen gleich sind. PHP ist der denkbar schlechteste Einstieg in eine Programmiererkarriere, den ich mir vorstellen kann. Nicht dass PHP per se schlecht sei, das mag jeder für sich entscheiden. Allerdings führt die "Freiheit", die diese Programmiersprache bietet dazu, dass man jede Menge Schrott coded und es nichtmal merkt - merke: Funktionsfähiger Code ist nicht gleich guter Code. Und wieviele, die da das Laufen gelernt haben, neigen zu "Quick&Dirty" zu deutsch "teuer ohne Ende in der Wartung". Wer benötigt im 21ten Jahrhundert etwas anderes als einen Browser?

Wie frei bist Du damit zu tun, was Du willst?

Aber ein "Telefon" hast Du schon?

Wenn ich das kurz aufgreifen darf: Das kannst Du bei einem C64 auch nicht... Und die Hardware war insoweit geschlossen, als das nur der Hersteller selbst in der Regel Hardware geliefert hat, die damit betrieben werden konnte. Ein anderes Floppy-Drive als das Commodore 1541 gab's (meines Wissens nach) nicht.

Naja. Man sollte nicht vergessen, das das "freiheitliche" Modell, wie Du es hier schilderst in der gesamten Historie der (Heim-) Computer eine Sonderstellung einnimmt. Wenn ich mich zurückerinnere zu Beginn der 80er Jahre, als ich meinen ersten Kontakt mit Computern hatte - namentlich aus dem Hause Sinclair den ZX81 bzw. dem Spectrum, sah es im Grunde so aus, wie Du es jetzt schilderst; nur fand man das im Grunde normal. Der eine hatte Gerät ABC der andere eben XYZ...