Whiz-zarD

Mitglieder
  • Gesamte Inhalte

    312
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    5

Whiz-zarD hat zuletzt am 15. Januar gewonnen

Whiz-zarD hat die beliebtesten Inhalte erstellt!

1 Benutzer folgt diesem Benutzer

Über Whiz-zarD

Letzte Besucher des Profils

1.164 Profilaufrufe
  1. Wie man ein Link in HTML setzt, findest du nicht selbst heraus? Eine Quelle, wo du es finden kannst: https://www.w3schools.com
  2. Zu 1) Klingt danach, als gäbe es ein Drop-Down-Menü, in der die Nutzer aufgelistet werden. Zu 2) Die Datenbank soll selber erstellt werden. Siehe den anderen Thread vom TE: Zu 3) Das Wort "Verlinkung" verwendet nur der TE. In der Aufgabenstellung steht, dass es Links geben soll, die zu einer weiteren Webseite führt. Zu 4) Da fehlt wohl noch ein ` am Ende der Query. Ich muss aber auch sagen, dass so eine Aufgabe für jemanden, der eine Ausbildung anfangen möchte, einfach zu viel ist. So etwas stellt man vielleicht Junior Entwickler, um deren Wissen zu überprüfen aber keinen potenziellen Anwärter für eine Ausbildung. Entweder hat der Betrieb kein Plan oder die suchen wirklich eine billige Arbeitskraft.
  3. An welches Gerät willst du den stick überhaupt anstecken?
  4. Eher, dass auf Teufelkommraus unbedingt alles eine grafische Oberfläche haben muss und in der sich alles abspielt und den Azubis OOP gar nicht beibringt.
  5. Hier mal ein Zitat aus Wikipedia (https://de.wikipedia.org/wiki/Aggregation_(Informatik)): Bei einer Aggregation können die Objekte auch ohne die Aggregation leben. Dies wäre z.B. beim "Dependency Injection" der Fall, wenn wir die Abhängigkeiten in eine Klasse reinreichen: public class Ehe { Person Mann; Person Frau; public Ehe(Person mann, Person frau) { this.Mann = mann; this.Frau = frau; } } Es müssen also zuerst die Personen erzeugt werden, bevor wir die Ehe erzeugen können. Die Personen können also ohne die Ehe leben. Bei einer Komposition hingegen könnte ein Objekt nicht alleine leben, was ein anderes Objekt erzeugt hat. Es ist dann also so, dass in einem Objekt (z.B. Haus) ein weiteres Objekt (z.B. Stockwerk) erzeugt wird und wenn das Haus-Objekt löscht wird, werden auch die Stockwerk-Objekte gelöscht. Beispiel public class Haus { private Stockwerk erdgeschoss; public Haus() { this.erdgeschoss = new Stockwerk(); } }
  6. Ist zwar schön und gut und trotzdem wird keine Firma jemanden einstellen, der nur Erfahrung mit RPG hat, wenn sie einen Java-Entwickler suchen, weil dieser erst mal in Java geschult werden muss. Kannst ja mal @MarcoDrost fragen, wie viele Java-Entwickler er an die Firmen vermittelt hat. Mit Sicherheit werden das nur sehr wenige gewesen sein, wenn überhaupt. Das Werkzeug sollte man also schon beherrschen, wenn man sich anderweitig bewirbt.
  7. Noch mal: Wozu braucht man Mocks? Mocks sind nichts weiter als ein Hilfskonstrukt und ein eher Zeichen, dass mit der Softwarearchitektur irgendwas nicht stimmt. Wenn man Mocks benötigt, hat man Abhängigkeiten. Sei es auch nur Abhängigkeiten zu Interfaces. Die Abhängigkeit ist aber da. Ohne ein Objekt, was ein bestimmtes Interface implementiert, kann ein anderes Objekt nicht leben. Die Frage ich aber, sind diese Abhängigkeiten überhaupt notwendig? Die reale Welt zeigt es doch deutlich: Nein. Als Beispiel hast doch der Blinker genannt. Wozu brauche ich dann nun ein Pseudo-Auto mit einem Pseudo-Motor, wenn ich nur den Blinker testen will? Stell dir eine Werkbank vor und auf dieser Werkbank liegt ein Blinker. Aus welchen Bauteilen besteht ein Blinker? Aus einem Blink-Relais, aus Kabeln und einem Leuchtmittel. Ich kann den Blinker also in seine Einzelteile zerlegen und einzeln testen. Ans Blink-Relais lege ich eine Spannung an und prüfe, ob das Relais auf und zu geht. Dem Leuchtmittel lege ich auch eine Spannung an und prüfe, ob sie leuchtet. Dann verbinde ich beide Teile mit einem Kabel (unsere Komposition) und lege wieder eine Spannung ans Relais an und siehe: Das Leuchtmittel blinkt. Wunderbar! Blinker getestet. Nächstes Bauteil... Das mache ich solange, bis ich alle Bauteile eines Autos getestet habe und kann nun die Teile ins Auto stecken und das Auto testen (wieder eine Komposition). Man sieht also, dass ein Mock-Objekt gar nicht von Nöten ist. Das Testen von Kompositionen wären dann die Integrationstests und das Testen einzelner, elementarer Bauteile wären unsere Unittests. Und hier noch mal zum Thema Inversion of Control und Dependecy Injection: Wann wird das mal wirklich benötigt? Beispiel Auto: Wenn ich sowieso nur ein Auto baue und das immer mit den selben Komponenten, wozu brauche ich dann Dependency Injection? Dependency Injection wird doch häufig nur des SOLID wegens implementiert aber oftmals wird das gar nicht benötigt. Man bläht also seine Anwendung nur unnötig auf. Dependecy Injection wird doch häufig nur verwendet, um tatsächlich Mock-Objekte in sein zu testendes Objekt stecken zu können aber überträgt man dies in die reale Welt, kommt doch was völlig absurdes raus: Man spricht immer davon, dass Softwareentwicklung ein Handwerk sei also wieso seinen Code nicht so entwickeln und testen, wie ein Handwerker seine Arbeit verrichtet? Ein Kfz-Mechatroniker braucht doch auch kein Motor aus Pappmaché, wenn er den Blinker testen will. Die Austauschbarkeit wird also nur häufig nur des Testen-Willens vorgeschoben. Im Produktionscode ist aber die Austauschbarkeit gar nicht gefordert. Vielleicht hat man nur eine Art von Blinkern. Man baut also in den Produktionscode ein Hilfskonstrukt nur für den Test ein. Für mich persönlich klingt das einfach völlig absurd. Dependency Injection bzw. Inversion of Control lässt sich auch durch Kompositionen realiseren, indem ich ein Interface und eine abstrakte Klasse für die Komposition erschaffe und für meine unterschiedlichen Konfigurationen in Klassen auslagere. Beispiel: public interface IKomposition { void TuEtwas(); } public abstract class KompositionBase : IKomposition { protected IAbhängigkeitA AbhängigkeitA { get; private set; } protected IAbhängigkeitB AbhängigkeitB { get; private set; } public KompositionBase(IAbhängigkeitA abhängigkeitA, IAbhängigkeitB abhängigkeitB) { this.AbhängigkeitA = abhängigkeitA; this.AbhängigkeitB = AbhängigkeitB; } public abstract void TuEtwas(); } public class KompositionA : KompositionBase { public KompositionA() : base(new AbhängigkeitA1Impl(), new AbhängigkeitB1Impl()) { } public override void TuEtwas() { /// Code } } public class KompositionB : KompositionBase { public KompositionB() : base(new AbhängigkeitA2Impl(), new AbhängigkeitB2Impl()) { } public override void TuEtwas() { /// Code } } Also kann ich doch die Klassen AbhängigkeitA1Impl, AbhängigkeitA2Impl, AbhängigkeitB1Impl und AbhängigkeitB2Impl einzeln testen und dann im Integrationstest KompositionA und KompositionB. Und siehe da, ich brauche nicht mal ein DI-Framework oder Mock-Objekte. Ein DI-Framework macht wirklich nur dann Sinn, wenn ich Kompositionen(!) über eine Konfiguration zusammenstecken möchte. Beispielsweise ich habe mehrere Kunden und Kunde A möchte, dass die Logs in die Datenbank geschrieben werden und Kunde B Logs in eine Datei oder Kunde A verwendet MSSQL und Kunde B OracleDB und ich möchte nicht für den Kunden ein eigenes Kompilat ausliefern. Diese Art von Konfiguration wird aber in vielen Fällen im Code gar nicht benötigt. Wer z.B. eine App ausliefert, die bei allen Kunden sowieso gleich funktioniert, braucht so etwas eigentlich gar nicht. Dann gehörst du leider zu den Personen der Ignoranten, die nicht mal neue Wege ausprobieren und ihre Erfahrungen teilen. Sorry. Leider besteht die Softwarentwicklung hauptsächlich nur aus Versuch-und-Irrtum und es geht darum, immer wieder neue Wege zu finden, wie man sich die Arbeit erleichtern kann. Gäbe es z.B. Robert C. Martin und andere, die das Clean Code voranbringen, nicht, würde man heute immer noch seitenlangen Spaghetti-Code in Excel und Access schreiben und lehren. Auch ein Softwareentwickler sollte sich weiterbilden und schauen, ob seine es inzwischen nicht andere Wege gibt, wie man Software entwickelt. Solche Sturköpfe habe ich auch in der Firma, wo ich arbeite und was produzieren sie? Unwartbaren und unleserlichen Spaghetti-Code, der in Regions und Kommentar-Blöcken geclustert wird und dann steht man dort vor einer 15.000 zeiligen Klasse, wo ReSharper schon schlapp macht, diese zu analysieren.
  8. Der Thread kann auch geschlossen werden, da sie hier nicht mehr aktiv ist.
  9. Das ist das sog. Inversion of Control bzw. das Dependecy Injection. Beides sind aber im Grunde nur Patterns, um Klassen zu strukturieren. Allerdings birgt dieses Pattern weitere Probleme, weil man Mock-Objekte benötigt, um solche Klassen testen zu können, da eine Klasse die Funktionalität einer anderen Klasse aufruft. Inzwischen bin ich bei einem Punkt angelangt, wo ich von Dependecy Injection wieder weggehe und den Code in einen funktionalen- und integralen-Teil zerlege und die Integration die Funktionen zusammenstöpselt. Ich bin da zwar noch dabei Erfahrungen zu sammeln, weil das echt ein Umdenken erfordert aber so fühlt sich Objektorientierung irgendwie richtiger an. Man braucht einfach keine großen Dependency Injection- und Mocking-Frameworks, um überleben zu können, sondern einfach nur die Sprachfeatures. Wenn ich einen Blinker testen will, wozu brauche ich da ein Pseudomotor? Baust du auch ein Motor aus Pappmaché, um einen Blinker zu testen? Nein. Du testest die Glühlampe und dann das Blinker-Relais. Und genau das ist doch das Problem vom Dependecy Injection: Teile, die ich gar nicht testen will, muss ich erst mal nachbauen, weil trotzdem die Funktionalität benötigt wird.
  10. Ich mag UML zwar überhaupt nicht und habe mich schon seit Jahren nicht mehr damit befasst aber ich denke, dass die Komposition will eher darauf hinaus, wie die Objektorientierung tatsächlich mal gedacht war und nicht, wie sie gelebt wird. Oft sieht man ja folgendes Konstrukt: public Class A { public void Foo(int i) { int x = i * 3; B b = new B(); b.Bar(x); } } Es sind aber drei Dinge, die in der Methode Foo() stattfinden: Berechnung von x Instanzierung von B der Aufruf von Bar() Dies verstößt aber eigentlich gegen die Definition der Objektorientierung von Alan Kay. Aus meiner Sicht kommt dann hier die Komposition ins Spiel. Die Komposition würde die einzelnen Logikschritte teilen und sie stattdessen in eine Komposition zusammenführen: public class Komposition { private A a; private B b; ... public void DoSomething(int i) { b.Bar(a.Foo(i)); } } public class A { public int Foo(int i) { return i * 3; } } public class B { public void Bar(int x) { ... } } Bei der Analogie des Menschens könnte die Komposition so aussehen: public class Mensch { private Herz herz; private Aorta aorta; ... public PumpeBlutInDieAorta() { this.aorta.Blut = this.Herz.PumpeBlut(); } } Somit wird deutlich, dass der Mensch ein Herz braucht. Ohne die Aorta oder ohne das Herz gäbe es eine NullReferenceException. Der Mensch wäre also nicht lebensfähig. Das Herz oder die Aorta lassen sich aber einzeln instanziieren und gezielt testen. So kann man ja auch im wirklichen Leben einem Menschen das Herz entfernen und per elektrische Impulse zum Schlagen bringen. Übertragen auf die Softwareentwicklung wären die elektrischen Impulse der Unittest. Wir schicken ein Signal ins Herz rein und erwarten eine Antwort. Wenn man diese Art- und Weise der Entwicklung durchzieht, braucht man fürs Testen nicht mal Mock-Objekte oder Dependency Injection, weil man die Anwendung in einen Integralen-, und Logik-Teil trennen würde. Den Logik-Teil kann man dann sehr leicht mit Unittests testen und der Integrale-Teil wäre ein Teil des Integrationstests. So ist also denkbar, dass das Herz auch nur eine Komposition ist und aus weiteren Teilen besteht, die dann wiederrum einzeln getestet werden können. Die Aggregation war für mich immer ein optionaler Teil, der auch fehlen kann. Bei der Analogie eines Menschens würde mir da spontan nur die Haare einfallen, die wachsen: public class Mensch { IList<Haar> haare; ... public void LasseHaareWachsen() { foreach(Haar haar in this.haare) haar.Wachse(); } } Somit kann der Mensch keine Haare haben aber der Mensch würde trotzdem leben.
  11. Was zum Geier? Das using hat hier überhaupt nichts zu suchen ... Das using ist für das IDisposable-Interface und dieses Interface dient fürs Aufräumen vom Speicher von unmanaged Code. Wenn du das Haus nur innerhalb eines Blockes haben willst, dann setze es doch ein ein Block: { var house = new House( new List<Room> { new Room(windowCount: 1), new Room(windowCount: 3) { Name = "dining" } }); house.Garage = garage; Console.WriteLine("house in a using statement"); Console.WriteLine(house.ToString()); Console.WriteLine("leaving using statement"); } @ Topic: Eine Aggregation assoziiert "ein Besitz". z.B. ein Forum besitzt Mitglieder. Das Forum kann aber auch ohne Mitglieder bestehen. Oder eine Garage besitzt ein Fahrzeug. Die Garage besteht aber auch, wenn kein Fahrzeug drinnensteht. Eine Komposition assoziert "ein Teil". z.B. das Herz ist ein Teil des Menschens. Ohne ein Herz kann ein Mensch nicht leben. Oder ein Raum ist ein Teil eines Gebäudes. Ohne ein Raum existiert auch kein Gebäude.
  12. Ich hab ein Netzteil mit 1,5A Ausgangsseitig. Besser wäre aber 2A oder mehr. Ich hab das Problem, wenn ich mal eine Festplatte ranhänge, dann startet der Raspberry neu, weil das Netzteil beim Anfahren der Festplatte in die Knie geht. Kann aber auch vielleicht daran liegen, dass das Netzteil schlecht verarbeitet ist und die verbauten Kondensatoren nichts taugen.
  13. Der einzige, der nicht rechnen kann, bist du.
  14. Dein Fehler ist wohl, dass du entweder nicht richtig schreiben oder lesen kannst.;) Also nochmal: Ich habe zwei Kredite: Kredit 1 Nomineller Betrag: 77.000 € Abtrag 272,21 € Tilgungsrate: 1% Kredit 2 Nomineller Betrag: 50.000 € Abtrag: 188,77 Tilgungsrate: 1% Also eine Gesamtsumme von 127.000 €. Die Summe beider Abträge beträgt 460,98 €. Bei Kredit 1 habe ich die Möglichkeit jährlich eine Sondertilgung von max. 5% des nominellen Betrags zu leisten. Im klartext ich kann ein mal im Jahr 3.850 € bezahlen (77.000 * 0,05 = 3.850 €). Ich habe vor (und bin auch gut dabei) jedes Jahr die Sondertilgung in Anspruch zu nehmen. Die Laufzeit beträgt 15 Jahre. D.h. 3.850 * 15 = 57.750 €. Also in diesen 15 Jahren habe ich im Idealfall 57.750 € an Sondertilgungen bezahlt. Während dieser Zeit tilge ich aber jeden Monat weiterhin den Kredit, sodass nach diesen 15 Jahren die Summe sehr geschrumpft sein wird. Ich habe gerade den Zins- und Tilgungsplan nicht im Kopf aber ich meine mich zu erinnern, dass dann der Kredit vollständig abbezahlt sein wird. Dann bleibt der KfW-Kredit. Diesen betrachte ich aber erst mal zweitrangig. Die Investitionsbank steht eh auf Rang 2 und steht unter behördlicher Regulation.
  15. Wenn, du es nicht kapierst, dann kann ich auch nichts für ... Natürlich ist das niedrig. Mein Finanzberater hat auch dazu geraten, erst mal mit 1% Tilgung anzufangen und später auf 1,5% aufzustocken, was ich auch noch vorhabe und außerdem die Sondertilgung in Anspruch nehmen. Dann wird von den 77.000 € nach 15 Jahren nicht mehr viel übrig bleiben. Den KfW-Kredit betrachte ich erst mal zweitrangig. Einen Abtrag muss ich so oder so bezahlen. Entweder an die Bank oder an den Vermieter und derzeit bezahle ich deutlich weniger als an einen Vermieter und ich sehe nicht, wieso das plötzlich anders sein sollte. Selbst nach 15 Jahren sehe ich das noch nicht so und ja, die Wohnung liegt auch demografisch sehr gut und hat auch in den letzten Jahren an Wert gewonnen.