Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03423.jsonl.gz/164

326 Objektorientiert entwerfen und implementieren
- 10 Dez. 2018
-
15:55
Entwurfsmuster Das Kompositum & Factory-Pattern und und und ...Das Kompositum (englisch composite oder whole-part) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung, das zur Kategorie der Strukturmuster (englisch structural patterns) gehört.
Mehr lesen...
Das Composite-Pattern
Das Factory-PatternFactory-Design-Pattern sind die am häufigsten verwendeten Muster in einer Objekt-orientierten Umgebung. Da die Objekterstellung manchmal sehr komplex ist, kommt man bei der Implementierung häufig nicht an einer Abstraktion vorbei.
Mehr lesen...
Factory Method Pattern - Kurzerklärung der Struktur (German / Deutsch)
Design-Pattern [German] - Singleton
- 10 Dez. 201814:25
Java Threads und SocketWas ist Socket ?
Mehr lesen...
Socket Programming in Java
Threads in JavaEin Thread in Java kann aus verschiedenen Sichten charakterisiert werden. Inhaltlich sind einzelne Threads eine in sich sequenzielle Abfolge von Anweisungen, als Ganzes gesehen laufen sie jedoch parallel zu anderen Threads.
Mehr lesen...
Java Queue Tutorial
- 10 Dez. 201812:25
Entwurfsmuster QueueIn der Informatik bezeichnet eine Warteschlange (englisch queue [kju]) eine häufig eingesetzte Datenstruktur. Sie dient zur Zwischenspeicherung von Objekten in einer Reihenfolge, bevor diese weiterverarbeitet werden.
Mehr lesen...
Java Queue Tutorial
- 10 Dez. 201811:15
Entwurfsmuster Abhängigkeits-Umkehr-PrinzipDas Dependency Inversion Principle (DIP) besagt, dass in der objektorientierten Programmierung die Basis eines Entwurfs nicht die speziellen Eigenschaften von Modulen sind, sondern deren gemeinsame Merkmale sollen in einer gemeinsamen Schnittstelle abstrahiert werden. Durch die Abstraktion werden die nicht mehr relevanten Details eines Moduls ausgeblendet. Mit Modul werden abgegrenzte und eigenständige Teile einer Software bezeichnet - dabei kann es sich um Objekte oder Klassen handeln. Die Umkehr der Abhängigkeiten ist nicht zu verwechseln mit dem in objektorientierten Programmierung gleichermaßen bekannten Prinzip von der Umkehr des Kontrollflusses, der Inversion of Control (IoC).
Mehr lesen...
OOP Design Principles: Dependency Inversion Principle
- 10 Dez. 201811:05
Entwurfsmuster AdapterDas Entwurfsmuster "Adapter", dient, wie der Name bereits andeutet, dazu, eine Schnittstelle einer anderen, inkompatiblen Schnittstelle anzupassen. Damit können Klassen zusammenarbeiten, die sonst aufgrund ihrer Schnittstellen nicht dazu in der Lage wären.
Mehr lesen...
Passt schon: Adapter [Entwurfsmuster]
- 10 Dez. 201810:05
Entwerfen Single Responsibility PrincipleIn der objektorientierten Programmierung sagt das SRP aus, dass jede Klasse nur eine fest definierte Aufgabe zu erfüllen hat. In einer Klasse sollten lediglich Funktionen vorhanden sein, die direkt zur Erfüllung dieser Aufgabe beitragen.
Mehr lesen...
Understanding the Single Responsibility Principle
- 08 Sep. 201820:05
Grobarchitektur EntwerfenWas bedeutet der Begriff Architektur in der Softwareentwicklung?
GrobarchitekturBei grösseren Systemen wird die Architektur hierarchisch beschrieben. Auf den oberen Ebenen werden als Bausteine Pakete, Komponenten und Schnittstellen (Interfaces), verwendet. Dies entspricht der Grobarchitektur. Ganz grosse Systeme werden zuerst in Subsysteme aufgeteilt. Für jedes Subsystem existiert dann wieder eine eigene Architektur.
DetailarchitekturDie Detailarchitektur befasst sich mit den einzlnen Teilkomponenten eines Systems. Hier kommen Klassen als Bausteine hinzu. Der Übergang zum Software-Entwurf ist fliessend.
Physische Architektur
UML-DeploymentdiagrammDie physische Architektur eines Systems kann mit dem UML-Deploymentdiagramm beschrieben werden. Darin wird die Hardware als Knoten und die Verbindungen zwischen der Hardware als Kommunikationspfade (Assoziationen) dargestellt. Das nachfolgende Diagramm zeigt eine Client-Server-Architektur.
Verteilte Systeme: Peer-to-PeerBei Peer-to-Peer-Systemen haben alle beteiligten Rechner die gleiche Rolle.Auf jedem Rechner läuft die gleiche Applikation, welche alle Aufgaben von der Benutzerschnittstelle über die Applikationslogik bis zur Datenhaltung wahrnimmt. Alle Rechner des Systems sind (mindestens logisch) untereinander vernetzt. Dies entspricht im Extremfall einer vollvermaschten Topologie. Peer-To-Peer-Systeme können sehr robust sein, da der Ausfall eines einzelnen Rechners vom Gesamtsystem kompensiert werden kann (im Gegensatz zu einem Serverausfall, welcher das ganze System lahmlegen kann). Allerdings bringen Peer-to-Peer-Systeme einen hohen Aufwand für die Synchronisation untereinander. Dieser wächst mit zunehmender Anzahl Peers sogar im Quadrat.
Mehr Lesen ...
Verteilte Systeme: Client-ServerClient-Server-Systeme haben eine Sterntopologie. Die gesamte Kommunikation läuft immer über den Server. Ganz grob gilt: Der Server ist für die Applikationslogik und die Datenhaltung verantwortlich. Die Clients enthalten die Benutzerschnittstelle. Ein solcher Client wird dann als Thin-Client bezeichnet. Wenn die Clients auch die Applikationslogik enthalten spricht man von einem Fat-Client. Allerdings ist die Welt nicht nur schwarz/weiss und so gibt es auch hier Nuancen.
Mehr Lesen ...
Thin-ClientEin Thin-Client kann auf einer limitierten Hardware betrieben werden. Für die Realisierung der Benutzerschnittstelle reicht ein Browser. Entsprechend ist die Systemarchitektur hier durch die verschiedenen Technologien der Web-Applikationen geprägt.
Mehr Lesen ...
Fat-ClientEin Fat-Client benötigt einen vollwertigen Rechner, da er auch die Applikationslogik ausführt, oder wenigstens Teile davon. Der Server ist dann im Extremfall nur noch für die Datenhaltung zuständig. Für die Kommunikation zum Server können verschiedene Protokolle zur Anwendung kommen.
Mehr Lesen ...
Logische Architektur
Kriterien für guten Entwurf
Hohe KohäsionKohäsion bedeutet "innerer Zusammenhalt". Mit hoher Kohäsion ist gemeint, dass alle Bestandteile eines Blocks (aber auch einer Komponente, eines Paketes, eines Moduls, einer Klasse) einen engen Bezug zueinander haben.
Gutes Beispiel: Der Block Sitzplatzverwaltung enthält die Liste aller Sitzplätze, sowie die nötigen Funktionen zur Suche von freien Sitzplätzen, zur Reservation und zur Freigabe von reservierten Sitzplätzen.
Schlechtes Beispiel: Der Block Sitzplatzverwaltung enthält auch die Kundendaten der Abonnementskunden (Kunden, welche einen festen Sitzplatz abonniert haben).
Schwache KopplungKopplung entsteht dann, wenn ein Block von einem anderen abhängt. Abhängigkeiten entstehen, wenn ein Block
die Schnittstelle eines anderen Blockes braucht
Daten aus einem anderen Block braucht oder
Strukturelemente (z.B. Klassen) aus einem anderen Block braucht.
Die Kopplung zwischen den Blöcken soll so gering wie möglich sein (allerdings wird sie nie null sein). Dadurch steigt die Wartbarkeit und die Stabilität eines Systems. Wenn an einem Block etwas geändert wird, sollen die Auswirkungen auf das Gesamtsystem so klein wie möglich sein. Wichtig ist vor allem, dass gegenseitige Abhängigkeiten zwischen Blöcken möglichst vermieden werden.
Elemente für die Beschreibung der logischen Architektur
BlockDie allgemeinste Form eines Elementes. Blöcke eignen sich für eine erste Skizze der Architektur. Siehe auch "Logische Architektur". Werden Blöcke verschachtelt, so spricht man oft auch von Subsystemen. Der äusserste Block bildet dann das Gesamtsystem. Blöcke können später durch Komponenten und Klassen ersetzt werden.
ModulDas Modul wurde mit der modularen Programmierung eingeführt. Es ist ein Kapsel für Daten und bietet nach aussen eine definierte Schnittstelle an. Diese besteht aus Prozeduren und Funktionen, welche auf den gekapselten Daten arbeiten. Heute werden Module in Form von Komponenten oder Klassen realisiert.
KomponenteIm engeren Sinn ist eine Komponente eine für sich ausführbare Einheit. Gleich wie beim Modul, kaspelt eine Komponente Daten und bietet eine Schnittstelle nach aussen an. Komponenten können von anderen Komponenten abhängen und sie können veschachtelt werden. Komponenten sind ersetzbar, d.h. eine Komponente kann durch eine beliebige andere Komponente ersetzt werden , welche die gleiche Schittstelle hat. Der Begriff wird oft in einem weiteren Sinn als Synonym für Modul oder gar Block verwendet.
InterfaceDer Begriff Interface hat mehrer Bedeutungen. Hier steht er für eine Sammlung von Methodendeklarationen (deshalb wird der englische Begriff verwendet). Interfaces können eingesetzt werden, um die Schnittstelle von Komponenten zu definieren.
KlasseDie Klasse ist das unterste Element der logischen Architektur.
PaketPakete dienen dazu Elemente zu gruppieren und um einen eigenen Namensraum für diese Elemente zu definieren. Pakete können verwendet werden, um die Zerlegeung eines Gesamtsystems in kleinere Einheiten darzustellen. So gesehen eignen sich Pakete als Ersatz für Blöcke.
Diagramme
BlockdiagrammDas Blockdiagramm ist ein freies Diagramm und gehört nicht zur UML. Es zeigt Blöcke und Schnittstellen.
UML-PaketdiagrammZeigt die Aufteilung eines Systems in Pakete. Zwischen den Paketen können <
- 14 Aug. 201820:05
Einfürung Use-Case-Diagramme & FachklassenUse-Case-Diagramme sind Verhaltensdiagramme: Sie beschreiben bestimmte Aspekte, wie sich ein System verhält. Wie Sie nun gesehen haben, können im Use-Case-Diagramm wesentliche Funktionen des Systems hervorgehoben und zueinander in Beziehung gesetzt werden. Diesen Diagrammen fehlt jedoch eine Möglichkeit, die Reihenfolge der Ausführung festzulegen.
Mehr lesen...
Use Cases.mp4
Fachklassen.mp4Fachklassen haben einen Wert für ein vertieftes Verständnis der fachlichen Domäne. Sie sind eine nützliche Ergänzung zum Glossar mit dem Ziel, Fachbegriffe gut und genau zu erklären. Es ist sehr wichtig, dass die Namen der Fachklassen für die Bezeichner von Klassen, Methoden oder Attribute im Code verwendet werden. Dadurch erhalten wir lesbaren Code. Fachklassen lassen sich nicht mehr direkt für die Implementierung verwenden. Eine Generierung von Code ist faktisch ausgeschlossen bzw. ist nicht sinnvoll. Aufgrund der Reduktion auf das für das Verständnis Notwendige sind die Fachklassen auch robust bei Änderungen am Code. Denn Entwickler ändern gerne und oft an den Details, aber wichtige Begriffe ändern auch Entwicklern nicht ohne triftigen Grund.
Mehr lesen...