lilith2k3

Das ist doch nicht ganz schlecht. Aber was die Klammern anbelangt: das ist nur bedingt richtig. Wichtig ist, dass Bestandteile extern generiert worden sind 8)

Da kann ich dem Chief nur recht geben. Wenn Du in der Tat erst Azubi-Lehrjahr 0 bist, sollest Du Dir in der Tat überlegen, ob das die Klitsche ist, bei der Du gerne arbeiten möchtest. Ohne die Details zu kennen, liest sich das so, als suchte eine Firma "billige Arbeitskräfte", die für einen AzuBi-Lohn jobben kommen. Und zur Belohnung dürfen die ab und zu mal in der Berufsschule auflaufen - aber auch nur dann, wenn der Chef gerade keine wichtigere Arbeit für die Leute hat. Gegen die Anforderung ist per se nichts zu sagen. Allerdings gibt der Kontext zu denken. Und der Rat vom Chief ist bestimmt nicht böse gemeint. Hoffen wir, dass Du es nicht bereust dort angefangen zu haben. Aber dann bleibt uns leider nur: Told you so!

Dann frag Ihn doch per PN

Blödes Beispiel zur Aggregation/Komposition: Gugelhupf - Das Loch in der Mitte ist nur solange da, wie der Kuchen drumherum ist (Komposition) Nur ein Softwareentwickler würde behaupten, er habe ein Loch genommen und einen Kuchen drumherumgebaut und würde das Loch anschließend, nachdem der Kuchen gegessen ist, wiederverwenden (Aggregation).

@Tician Tja. Du wirst lachen, aber ich hatte in der Berufsschule genau das gleiche Problem wie Du. Das liegt meist daran, dass die Schulbeispiele herrlich konstruiert sind XD Ich glaube, dass gerade Dein Beispiel ein gutes Beispiel dafür ist, wie man es den Schülern unnötig schwer macht, zu verstehen, was man eigentlich will, weil man irgendwas auf teufelkommraus OOP-artig präsentieren will. Ich versuch das mal irgendwie so umzustricken, dass es halbwegs sinn macht XD Also: Stell Dir vor, Du hast eine Game-Engine-Klasse für Sudoku. Diese Game-Engine enthält das Regelset dafür, welche Felder wie ausgefüllt sein dürfen etc. Diese Game-Engine könntest Du theoretisch so programmieren, dass man sie wie ein Programm auf der Konsole aufrufen könnte. Du könntest quasi eine Eingaberoutine schreiben, die ein CSV bekommt und Dir ausspuckt, ob das ein valides Sudoko Ergebnis ist. In der Zwischenzeit hat sich jemand die Mühe gemacht, einen graphischen Client für Deine Regel-Engine zu basteln. Er bastelt quasi eine Klasse, die als Vermittler zwischen der Anwendung und Deiner Game-Engine steht. Übergabeparameter im Konstruktor ist eben ein Objekt vom Typus Deiner Gameengine. Aus dem Zusammenhang wird klar, dass es sich um eine Aggregation handeln muss. Denn wie wir gesehen haben, funktioniert Deine Engine auch prima, ohne dass man die GUI dazu braucht. Und was noch viel spannender ist: Du könntest - wenn Du schön brav threadsafe code geschrieben hast - diese eine Instanz Deiner Engine auch für einen Multiuser-Client zur Verfügung stellen: Jeder User erhält zwar eine eigene Instanz der GUI; aber Deine Engine existiert noch brav weiter, wenn der Client geschlossen wird. Man könnte den Client auch so umschreiben, dass sich jede Instanz des Clients eine eigene Instanz Deiner Engine mit new () selbst baut. Diese Instanz wäre dann an die Lebenszeit des Clients gebunden. Das wäre dann eine Komposition. Das ist kompliziert. Wenn man das Beispiel »Sudoku« rein realweltlich interpretieren würde, kommt man zu dem Schluss: Ein Sudoku-Spiel besteht aus 81 individuellen Textboxen. Die sind allesamt Teil des Sudoku-Spiels. Zwar kann ein Schlaumeier behaupten: »naja, wenn ich mir das Sudoku wegdenke, kann ich die Kästchen ja immer noch zum rechnen benuzten« - aber das trifft es nicht. Und es würde auch niemand behaupten: »Hey, ich habe gerade aus meinem Matheheft 81 Kästchen ausgeschnitten, die kann ich jetzt zum Sudokuspielen nutzen. Oder wenn ich keine Lust mehr habe, klebe ich sie wieder in mein Matheheft« Die 81 Kästchen verdanken ihr Sudoku-Kästchen-Sein einzig dem Spiel als ganzem. Und wenn Du den Zettel zerknüllst, sind die Kästchen auch im A*****. Also leben die Teile streng genommen nur solange, wie das Spiel als solches lebt. Und ihren Sinn haben die Kästchen nur durch das Spiel. Also sind das 81 Kästchen in Komposition vereint. Andererseits könnte ein kluger Philosoph hingehen und sagen: »Hey, ich male ein Kästchen. Oopsi: hier, noch eins. Und plötzlich waren es 80. Damit könnte ich Rechenaufgaben lösen. Nein, warte: hey! Boah! Ich könnte noch eins malen und habe ein Sudokuraster« In dem Fall waren die Kästchen vor dem Spiel da und hätten das Spiel auch überlebt. Wie gesagt: Das tolle an so Geschichten ist, dass Sie konstruiert sind, um Schülern etwas beizubringen. Letztlich legt man sich, wenn man Pech hat einundrölfzig Fallstricke aus, über die man ständig fällt; und man verwirrt die Schüler mehr als ihnen zu helfen. Aber IMHO kannst Du bei dem realen Sudoku es drehen wie Du willst, Du hast immer Komposition, weil es keinen Sinn macht, von einer Gruppe auszugehen, die Außerhalb des Sudokus existiert. Aber das sagt Dir nur ein alter Mann aus dem Internet Implementieren kannst Du das natürlich wie Du willst: Du könntest Objekte Bauen, die Du der Sudokugruppe "leihst" - analog zur Game-Engine, die Du wiederverwenden kannst - und nach Beendigung des Sudokus hättest Du die Objekte immer noch. Allerdings stellt sich für mich die Frage nach frei flottierenden Textboxen *LOL* Schön wäre es, wenn Dir das Game-Engine-Beispiel helfen kann, das Ganze besser zu verstehen :]

Naja. Die Zeit als die wesentliche Frage der Industrie »Du kannst doch auch Computer?« bzw. »Internet, schonmal gehört?« lautete, ist wohl vorbei. Seitenensteiger haben es heute schwerer als zu Zeiten vor/in der Dotcom-Blase; aber dennoch finden selbst Seiteneinsteiger Arbeit. Nun bist Du mit Medieninformatik kein Seiteneinsteiger, sondern hast im Gegenteil eine fachliche Qualifikation, insofern solltest Du ein wenig entspannter in die Zukunft blicken. Dass Dir das Präfix "Medien-" als Stigma ausgelegt wird, halte ich für unbegründet. Die (ehemals Fach-) Hochschule in unserer Stadt bildet ausschließlich Medieninformatiker aus. Und von denen, die ich kenne, sitzt aktuell keiner mit seiner Mütze in der Fußgängerzone. Prinzipiell erhälst Du mit Deinem Abschluss einen Zettel, der Dir als Eintrittskarte in die Branche dient. Wenn Dir langweilig ist, stelle Dein Profil bei Xing, LinkedIn, Monster, JobSchleuderDeinerWahl rein und warte ab. Sagen wir mal so. Generell ist "Softwareentwickler" der Blue Collar Job des 21ten Jahrhunderts. Wenn Du Google, Facebook, Amazon etc. meinst, ja. Sonst weiß ich nicht, wovon Du sprichst. Stell Dir vor, das müssen Ärzte auch. So What? Ich habe meine zweite Ausbildung zum Fachinformatiker erst mit 35 abgelegt. Aktuell kann ich mich nicht beschweren, was Jobangebote anbelangt. Die Frage, die sich mir stellt. Warum wolltest Du studieren? Um reich und berühmt zu werden, braucht man kein Studium. Das kann man auch vollkommen frei von Bildung bei RTL erreichen. Wenn Dich die Sache interessiert, warum sich vom Gerede Dritter davon abbringen lassen? Du hast mit dem Studium, die ungezwungene Möglichkeit, Deinen Neigungen nachzugehen. Das solltest Du tun, unabhängig von den Jobaussichten. Wenn Du »Angst um Deine Zukunft hast«, kann ich Dir eine Anekdote aus meinem Leben erzählen: Kurz nach der Ausbildung war ich arbeitslos gemeldet, da mein Arbeitgeber mich auf eigenen Wunsch nicht übernommen hat. Ich habe einen Termin beim Arbeitsberater gehabt. Der hat 10 Minuten gedauert. Ich habe einen Fragebogen ausgefüllt, der hat sich den angeguckt und gesagt: »Sie sind Fachinformatiker? Achso. Ja, dann können Sie gehen. Den nächsten Termin hätten Sie in 6 Wochen gehabt. Aber bis dahin werden Sie nicht mehr arbeitslos sein«. Und es dauerte 5 Tage, danach hatte ich meinen nächsten Job in der Tasche. Achja: mit 35.

Diese Diskussion bringt dem TO nichts. Ich sehe nicht ein, dass Du hier den Thread kaperst.

Ja. So wie UML ein graphisches Verfahren ist, Software zu modellieren. Ich verstehe nicht, worin der Nachteil bestehen sollte. Das Zusammenspiel von Objekten, die durch Komposition zusammengesteckt werden kann ich schlechter testen als durch Aggregation. Die von Dir Angeführten Mocks bieten Dir Möglichkeiten, die du ohne nicht hast: bspw. sicherstellen, dass gewissen Methode keinmal, einmal, mindestens einmal aufgerufen worden sind. Möchte ich das nicht testen, benötige ich auch keine Mocks. Das heißt, Du hast im Vergleich zur Komposition keine Nachteile. Da sind die Objekte genauso opak in der Benutzung. Seine Software in der Art zu strukturieren bietet Dir die Möglichkeit, testgesteuert (ich vermeide explizit »testdriven«) Deine Software zu entwickeln. Man kann sein Smartphone nutzen, um ulkige Katzenvideos zu gucken - aber es ist noch mehr drin. Es ist natürlich von den Ansprüchen, die man an sein Produkt hat, abhängig. Das tolle an der Softwarentwicklung ist ja, dass Du als Entwickler bestimmen kannst, mit welchen Wegen Du zum Ziel kommst. Ich bin aus dem Alter raus, wo ich den Leuten erzählen will, was sich wie richtiger anfühlt. Es zählt, dass mit der Software Geld verdient werden kann. Ob das objektorientiert, funktional, prozedural, strukturiert passiert interessiert keinen Kunden/Arbeitgeber. Am Ende des Budgets muss das Problem gelöst sein, sonst taugt der Ansatz nicht.

Hach, die schöne Schulzeit Aggregation und Komposition sind zwei Konzepte, die Beziehungen von Objekten untereinander darstellen. Ein Objekt, dessen Lebenszyklus innerhalb eines anderen startet wird durch die "Komposition" beschrieben. Typischerweise werden diese dann in Instanzvariablen referenziert. Sinnvollerweise sind es Objekte, die einen sehr eingeschränkten Funktionsbereich haben. In der Praxis sehe ich keinen Grund etwas anderes als Containerobjekte durch Komposition in einem Objekt zu nutzen. Containerobjekte sind Datenstrukturen wie Listen, Tupel, Dictionaries, etc. Deren Lebenszeit beginnt im Objekt und endet dort. Andere Objekte, die bspw. gebraucht werden, um die Funktionalität des sie beherbergenden Objekts zu erweitern, werden durch Aggregation "injeziert". Beispiel: Motor. Motoren werden natürlich in Autos eingebaut - Autos gebären keine Motoren unter der Motorhaube. Und mancher Motor überlebt auch das Auto, in welches er eingebaut worden ist. Entsprechend sinnvoll ist es, innerhalb der Klasse Auto nicht "new Motor()" aufzurufen, sondern man übergibt den Motor bspw. im Konstruktor (Faustregel: Notwendige Objekte im Konstruktor übergeben und optionale per "Setter" reinreichen). Das Tolle an der Aggregation ist die Austauschbarkeit der Komponenten, die benötigt werden. Wenn man bspw. den Blinker am Auto testen will, kann man einfach auch einen "Pseudomotor" einbauen. Und wenn jemand versehentlich Gas gibt, passiert halt nix - man will ja in aller Ruhe den Blinker testen. Umgekehrt muss man davon ausgehen, dass man an alle Objekte, deren Lebenszyklus in anderen beginnt (und endet) in der Regel nicht rankommt; geschweige denn, kann man sie austauschen. Deshalb will man möglichst Abstand halten von der Komposition.

Dem stimme ich zu. Wobei ich die Gewichtung eher darauf legte, warum es in Deinem Interesse ist, Dich bei diesem Unternehmen zu bewerben. Ich finde es sollte immer klar sein, warum Du etwas tun willst. Ob das dann zum Unternehmen passt, resp. ob Du qualifizierter als andere -der "Richtige" - bist, müssen andere entscheiden. Es muss klar sein, was Du vom Unternehmen willst und was sie dafür bekommen, wenn Sie Dich nehmen. Das sehe ich anders: Im Lebenslauf kann man sehen, was Du bist, welche Qualifikation Du mitbringst. Wer Du letztlich bist, wie Du tickst, kannst Du im Anschreiben zeigen. Es besteht ja durchaus die Möglichkeit, dass Deine fachliche Qualifikation komplett verschieden ist, von dem, was Du willst und wie Du gestrickt bist. Beispielsweise habe ich eine Ausbildung in einem Microsoft Systemhaus gemacht. Derzeit arbeite ich bei einer 100%igen Linux Butze, wo alles Open Source ist. Dass ich mich sehr wohl für Open Source interessiere, in meiner Freizeit hobbymäßig mit FreeBSD herumspiele etc. sind alles Sachen, die erwähne ich nicht im Lebenslauf ( ich bin gegen die »Hobby-Sektion«). Dafür ist IMHO das Anschreiben gedacht. Anschreiben und Lebenslauf sollten nicht divergieren, können aber durchaus komplementär sein. Desweiteren bin ich dafür, so einen "Quatsch" wie »Teamplayer« weder im Lebenslauf noch im Anschreiben unterzubringen. Es ist eine Sache, für was Du Dich hälst; eine andere Sache, für was Dich jemand anderes hält und beides ist nicht wirklich falsifizierbar. Das kann man dem Arbeitszeugnis entnehmen, was Dein letzter Arbeitgeber glaubt, wie Deine Leistung aussieht. Was ich vorallen an Bewerbungen schätze: 1) Kürze Maximal 10 Sätze. Gerne auch mal mit https://www.psychometrica.de/lix.html testen, ob das, was man schreibt "verständlich" ist (mit obigem Anschreiben 47.4 ist okay!) 2) Nachvollziehbarkeit Und zwar in der Reihenfolge. Siehe oben.

Zu der eigentlichen Frage, zum Thema: Objektorientierung. Nein. Das ist keine Objektorientierung. Das ist Programmieren mit "Klassen". Was per se erstmal nicht schlimm ist. Das Problem ist, dass Deine "Objekte" zwar alle Funktionalität zusammen mit irgendwelchen Daten vereinen - was in Richtung OOP geht - aber die eigentliche Kern-Idee von "Objekten" als eigenständigen Funktionseinheiten ist nicht umgesetzt. Du behandelst Deine Objekte eher wie "Sklaven" - um es mal so auszudrücken. Du definierst eine Klasse »Settings«, die eigentlich dazu dienen sollen, Dir Informationen (von wo auch immer) bereitzustellen. Dabei gehst Du zunächst hin und rufst die Methode »ReadFile« von extern auf. Das ist aus zweierlei Gründen "schlecht": 1) Du "leakst" nach außen die Information, dass Du die Settings aus einem File liest. Das ließe sich besser kapseln, indem Du bspw. den Filenamen über einen Konstruktorparameter übergibst. Dann ist zwar immer noch offensichtlich, dass es sich um ein File handelt, aber schon mal ein Schritt in die richtige Richtung. Desweiteren würde ich den "String" irgendwie kapseln wollen, da es sich um keinen String im herkömmlichen Sinn, sondern um einen Pfad handelt; also sowas wie https://msdn.microsoft.com/en-us/library/system.io.fileinfo(v=vs.110).aspx oder so. Aber mein C# ist schon 5 Jahre alt 2) Und wesentlich "problematischer" finde ich, dass Du dem Objekt von außen erzählen musst, was es wann zu tun hat: * Lese Ini. * Hole diesen Wert * Hole jenen Wert Das ist per se nicht schlimm - nur nicht objektorientiert. Objektorientiert würde es dadurch, dass Du dem Objekt die Aufforderung zukommen lässt, diesen oder jeden Konfigurationswert zurückzugeben. Das gleiche gilt für Deinen "Changer". Im Grunde sollte alles soweit in die Objekte gekapselt werden, dass Du in der Main nur noch folgende Sachen machst: a ) Initialisieren der Settings b ) Initialisieren Deines "Changers" mit den "Settings" im Konstruktor c) aufrufen der Methode, die den "Job" ausführt. Wenn es weiterhilft: Es gibt die weitverbreitete Metapher, dass Methodenaufrufe als "Nachrichten" an ein Objekt zu verstehen sind. So, wie Du in die Kneipe gehst und ein Bier bestellst (»Bitte ein Bier«) und nicht: »Also. Erstmal gehst Du zum Tresen. Dann suchst Du mir ein Glas aus. Wenn's schmutzig ist, spüle es. Dann gehst Du zum Zapfhahn ...« Ich denke, es wird klar, was ich meine. Ansonsten: Viel Spaß beim Coden

Willkommen in #Neuland Meine Berufsschulerfahrung in Kürze: Ich so: »Wann lernen wir Design Patterns« Lehrer so: »Was?« Ich habe fast alles, was ich in der Berufsschule gelernt habe, erfolgreich nicht anwenden können. P.S.: Hashtags werden nicht ohne Magie unterstützt?

Nicht böse gemeint, aber: Wer um alles in der Welt will das denn alles lesen? Für ein Anschreiben sind mir das zu viele Details, die ich gar nicht alles wissen will. Das erste, was mir in den Sinn kommt: »Wall of Text« => Ablage P Was mir fehlt: 1) Mit welchem Schlagwort kann man Dich und Deine Fähigkeiten am besten beschreiben? Momentan ist das ein bisschen von allem... 2) Was motiviert Dich, Deine bisherige Arbeit aufzugeben? So wie es ausschaut, hast Du ja noch welche. Du tauscht also die Sicherheit einer bestehenden Arbeit gegen das Wagnis einer neuen Arbeit. Das tun Menschen nicht ohne Grund. 3) Was glaubst Du, zeichnet Deinen zukünftigen Arbeitgeber besonders aus? Schaffst Du es, das Unternehmen korrekt am Markt einzusortieren? 4) Was motiviert Dich, dieses Unternehmen, was Du in (3) korrekt eingeordnet hast, als neuen Arbeitgeber zu wählen. Was hast Du davon? Was hat das Unternehmen davon, Dich einzustellen. Desweiteren: Dein komplettes Anschreiben ist voll von nichtssagenden Floskeln. Höhepunkt ist der letzte Absatz Besser etwas unverbindliches, schlichtes: Für Rückfragen stehe ich Ihnen gerne zur Verfügung.

Sag mal, was schätzt Du, wieviel Zeit ein Personaler im Schnitt mit dem Lesen von Bewerbungen verbringt? Etwa 50 Sekunden. Wenn Du Dein Anschreiben nochmal unter dem Gesichtspunkt liest - schaffst Du Dir anhand des Textes eine Meinung zu bilden? Dein Text ist a) viel zu lang (zuviel Geschwafel) und b ) bist Du zu zurückhaltend. Du bist eine ausgebildete Fachkraft, also solltest Du das auch ausstrahlen! Was der Bewerbung komplett abgeht ist zum einen das persönliche, also das, was Dich auszeichnet und zum anderen das besondere an der Firma, bei der Du Dich bewirbst. Alternative: Nach einem Praktikum bei $Firma habe ich nach der anschließend 3 jährigen Ausbildung meinen Abschluss am $Datum als FIAE gemacht. Bei $Firma habe ich im Bereich $Schwerpunkt gearbeitet und dort $Dinge getan. Um mein Wissen über $Bereich zu vertiefen habe ich 2013 eine Schulung bei $Anbieter gemacht. In meiner Freizeit beschäftigt mich $AnderesThemainteressantfürneueStelle. Da Ihr Unternehmen $Besonders im Bereich $Bereich2 ist, bewerbe ich mich bei Ihnen, um $Ziel zu erreichen. Für Rückfragen stehe ich Ihnen in einem persönlichen Gespräch zur Verfügung. ------------------------------------- Damit signalisierst Du rund heraus, wer Du bist und was Du willst. Und musst nicht ständig etwas »unter Beweis stellen zu können«. Du bist Fachkraft. Dafür hat man Dir einen blöden Zettel gegeben, wo genau das drauf steht. Dass Du arbeiten kannst, wird vorausgesetzt. Sollte sich die Annahme als falsch herausstellen, wird man es Dir schon sagen. Wenn man Deine Bewerbung liest, so wird einem signalisiert: »Ich kann was: wirklich und in echt. Ich beweis Dir das, wenn Du mir nicht glaubst. Doch, tue ich« Das ist das Gegenteil von dem, was Du eigentlich vermitteln willst.

Sofern das Format "sauber" ist und Du keine Fehlertoleranz brauchst, bzw. Du genug Hauptspeicher hast versuchs mit diesem Hüftschuss: String = Lies Datei Teilstücke = String.SplitteBei('\n') For i=0; i<Teilstücke.length-2; i+=3 Schreibe Teilstücke+Teilstücke[i+1]+Teilstücke[i+2] in Datei Ende.