Programmierprinzipien - Versionsgeschichte

Kowa am 6. April 2022 um 15:29 Uhr

2022-04-06T15:29:24Z

Kowa am 6. April 2022 um 15:22 Uhr

2022-04-06T15:22:31Z

← Nächstältere Version		Version vom 6. April 2022, 15:22 Uhr
Zeile 53:		Zeile 53:
	; wartbar (maintainable): Das Softwarepaket sollte leicht an neue Gegebenheiten angepasst werden können. Fehler sollten leicht behoben werden können (da sie sich nie ganz vermeiden lassen).		; wartbar (maintainable): Das Softwarepaket sollte leicht an neue Gegebenheiten angepasst werden können. Fehler sollten leicht behoben werden können (da sie sich nie ganz vermeiden lassen).
	:⇒ geringe Wartungskosten		:⇒ geringe Wartungskosten

			; wiederverwendbar (reusable): Erweiterungen der Spezifikation sollten wiederverwendet werden können.
			:⇒ geringe Wartungskosten und Erweiterungskosten
			:⇒ geringere Kosten bei Folgeprojekten

	Für die Eigenschaft „wartbar“ gibt es drei Spezialfälle, die hier gesondert genannt werden sollen:		Für die Eigenschaft „wartbar“ gibt es drei Spezialfälle, die hier gesondert genannt werden sollen:
Zeile 73:		Zeile 77:
	:→ Überprüfbarkeit (durch Programmierer und nicht nur durch Compiler u.Ä.) (→ Korrektheit, Robustheit)		:→ Überprüfbarkeit (durch Programmierer und nicht nur durch Compiler u.Ä.) (→ Korrektheit, Robustheit)
	:→ Wartbarkeit (da die Programme auch von anderen Programmierern verstanden werden)		:→ Wartbarkeit (da die Programme auch von anderen Programmierern verstanden werden)
	~~:→ Erweiterbarkeit (da die Programme auch von anderen Programmierern verstanden werden)~~

	===[[Schreibbarkeit]], Writability===		===[[Schreibbarkeit]], Writability===
Zeile 84:		Zeile 87:
	* Fehler werden vermieden (wenn beispielsweise Code-Fragmente automatisch generiert werden).		* Fehler werden vermieden (wenn beispielsweise Code-Fragmente automatisch generiert werden).
	:→ Korrektheit		:→ Korrektheit
	:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit)

	===[[Stetigkeit]], Continuity===		===[[Stetigkeit]], Continuity===
	;Schreibe stetigen Code.: Schreibe den Code so, dass kleine Änderungen an der Spezifikation auch nur kleine Änderungen am Code zur Folge haben.		;Schreibe stetigen Code.: Schreibe den Code so, dass kleine Änderungen an der Spezifikation auch nur kleine Änderungen am Code zur Folge haben.
	:→ Wartbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)		:→ Wartbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)
	~~:→ Erweiterbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)~~
	:→ Wiederverwendbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)		:→ Wiederverwendbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)

	===[[Konfigurierbarkeit]], Customizability===		===[[Konfigurierbarkeit]], Customizability===
	;Schreibe konfigurierbaren Code.: Konstante Werte sollten im Allgemeinen nicht direkt in den Code eingefügt werden, sondern als konstante Werte separat definiert werden (Ausnahme: triviale Konstanten, die sich sicher nie ändern werden, wie z.B. Vergleiche mit dem Wert <code>0</code>). Konstanten, die das Programmverhalten beeinflussen, sollten im Allgemeinen beim Programmstart aus einer Konfigurationsdatei ausgelesen werden.		;Schreibe konfigurierbaren Code.: Konstante Werte sollten im Allgemeinen nicht direkt in den Code eingefügt werden, sondern als konstante Werte separat definiert werden (Ausnahme: triviale Konstanten, die sich sicher nie ändern werden, wie z.B. Vergleiche mit dem Wert <code>0</code>). Konstanten, die das Programmverhalten beeinflussen, sollten im Allgemeinen beim Programmstart aus einer Konfigurationsdatei ausgelesen werden.
	:→ Stetigkeit (→ Wartbarkeit~~, Erweiterbarkeit~~, Wiederverwendbarkeit)		:→ Stetigkeit (→ Wartbarkeit, Wiederverwendbarkeit)

	===[[Don't repeat yourself]], DRY<ref>{{Quelle\|Hund, Thomas (2003)}}</ref>===		===[[Don't repeat yourself]], DRY<ref>{{Quelle\|Hund, Thomas (2003)}}</ref>===
	;Wiederhole dich nicht.: Code sollte nicht dupliziert und anschließend aber gar nicht oder nur marginal modifiziert werden.		;Wiederhole dich nicht.: Code sollte nicht dupliziert und anschließend aber gar nicht oder nur marginal modifiziert werden.
	:→ Stetigkeit (→ Wartbarkeit~~, Erweiterbarkeit~~, Wiederverwendbarkeit)		:→ Stetigkeit (→ Wartbarkeit, Wiederverwendbarkeit)
	:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit, Erweiterbarkeit)		:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit, Erweiterbarkeit)
	:→ Robustheit (da keine inkonsistenten Änderungen an mehreren Stellen möglich sind)		:→ Robustheit (da keine inkonsistenten Änderungen an mehreren Stellen möglich sind)

Kowa: /* Stetigkeit, Continuity */

2022-04-06T15:10:19Z

Stetigkeit, Continuity

← Nächstältere Version		Version vom 6. April 2022, 15:10 Uhr
Zeile 89:		Zeile 89:
	;Schreibe stetigen Code.: Schreibe den Code so, dass kleine Änderungen an der Spezifikation auch nur kleine Änderungen am Code zur Folge haben.		;Schreibe stetigen Code.: Schreibe den Code so, dass kleine Änderungen an der Spezifikation auch nur kleine Änderungen am Code zur Folge haben.
	:→ Wartbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)		:→ Wartbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)
	:→ ~~Erweiterberkeit~~ (der Code kann schnell an neue Gegebenheiten angepasst werden)		:→ Erweiterbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)
	:→ Wiederverwendbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)		:→ Wiederverwendbarkeit (der Code kann schnell an neue Gegebenheiten angepasst werden)

Kowa am 14. Mai 2020 um 07:30 Uhr

2020-05-14T07:30:53Z

← Nächstältere Version		Version vom 14. Mai 2020, 07:30 Uhr
Zeile 69:		Zeile 69:
	Um die vorgenannten Ziele zu erreichen, sollten folgende [[Programmierprinzipien]] beachtet werden:		Um die vorgenannten Ziele zu erreichen, sollten folgende [[Programmierprinzipien]] beachtet werden:

	===[[Verständlichkeit]], ~~Comprehesibility~~, Lesbarkeit, Readability===		===[[Verständlichkeit]], Comprehensibility, Lesbarkeit, Readability===
	;Schreibe lesbaren und verständlichen Code.: Der Programmcode sollte so einfach wie möglich gelesen und verstanden werden können. Das heißt, der Code sollte sauber formatiert werden, es sollten sprechende Bezeichner verwendet werden, es sollten sinnvolle Kommentare eingefügt werden etc. Ein erfahrender Programmierer sollte die Bedeutung der einzelnen Anweisungen, Operationen, Definitionen etc. problemlos erfassen können.		;Schreibe lesbaren und verständlichen Code.: Der Programmcode sollte so einfach wie möglich gelesen und verstanden werden können. Das heißt, der Code sollte sauber formatiert werden, es sollten sprechende Bezeichner verwendet werden, es sollten sinnvolle Kommentare eingefügt werden etc. Ein erfahrender Programmierer sollte die Bedeutung der einzelnen Anweisungen, Operationen, Definitionen etc. problemlos erfassen können.
	:→ Überprüfbarkeit (durch Programmierer und nicht nur durch Compiler u.Ä.) (→ Korrektheit, Robustheit)		:→ Überprüfbarkeit (durch Programmierer und nicht nur durch Compiler u.Ä.) (→ Korrektheit, Robustheit)

Kowa am 14. Mai 2020 um 07:29 Uhr

2020-05-14T07:29:01Z

Kowa am 3. August 2019 um 12:36 Uhr

2019-08-03T12:36:14Z

← Nächstältere Version		Version vom 3. August 2019, 12:36 Uhr
Zeile 270:		Zeile 270:
	{{TBD\|Principle of Least Surprise}}		{{TBD\|Principle of Least Surprise}}
	[[Kategorie:Programmierprinzip]]		[[Kategorie:Programmierprinzip]]
	~~[[Kategorie:Programmierung]]~~
	[[Kategorie:HowTo]]		[[Kategorie:HowTo]]
	[[en:Programing principles]]		[[en:Programing principles]]

Kowa: /* Repeat yourself, RY{{Quelle|Kowarschick (MMProg)}} */

2018-12-19T12:24:42Z

Repeat yourself, RY{{Quelle|Kowarschick (MMProg)}}

← Nächstältere Version		Version vom 19. Dezember 2018, 12:24 Uhr
Zeile 104:		Zeile 104:
	===[[Repeat yourself]], RY<ref>{{Quelle\|Kowarschick (MMProg)}}</ref>===		===[[Repeat yourself]], RY<ref>{{Quelle\|Kowarschick (MMProg)}}</ref>===
	;Wiederhole dich.: In Benutzerschnittstellen sollten gleiche oder vergleichbare Aufgaben immer auf dieselbe Weise vom Benutzer durchgeführt werden können. Es sollten dieselben Bezeichner, dieselben bzw. gleichartige Bedienelemente, dasselbe Design etc. verwendet werden.		;Wiederhole dich.: In Benutzerschnittstellen sollten gleiche oder vergleichbare Aufgaben immer auf dieselbe Weise vom Benutzer durchgeführt werden können. Es sollten dieselben Bezeichner, dieselben bzw. gleichartige Bedienelemente, dasselbe Design etc. verwendet werden.
	:→ Wiederverwendbarkeit (da gleichartige Elemente nicht mehrfach implementiert werden müssen)		:→ Wiederverwendbarkeit (da gleichartige Elemente nicht mehrfach implementiert werden müssen; DRY)
	:→ Stetigkeit (→ Wartbarkeit, Erweiterbarkeit, Wiederverwendbarkeit)		:→ Stetigkeit (→ Wartbarkeit, Erweiterbarkeit, Wiederverwendbarkeit)
	:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit, Erweiterbarkeit)		:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit, Erweiterbarkeit)

Kowa: /* Software-Eigenschaften zur Erfüllung der beiden Ziele */

2018-12-19T12:22:35Z

Software-Eigenschaften zur Erfüllung der beiden Ziele

← Nächstältere Version		Version vom 19. Dezember 2018, 12:22 Uhr
Zeile 27:		Zeile 27:
	Um die beiden vorgenannten Ziele zu erreichen, sollte ein Softwarepaket folgende Eigenschaften haben:		Um die beiden vorgenannten Ziele zu erreichen, sollte ein Softwarepaket folgende Eigenschaften haben:

	; spezifiziert (specified): Um die Nützlichkeit und die Korrektheit des Softwarepakets beurteilen zu können, sollte eine Spezifikation vorliegen, die detailliert die Aufgaben und Eigenschaften des Paketes beschreibt.		; spezifiziert (specified): Um die Nützlichkeit und die Korrektheit des Softwarepakets beurteilen zu können, bevor es eingesetzt wird, sollte eine Spezifikation vorliegen, die detailliert die Aufgaben und Eigenschaften des Paketes beschreibt.
	:⇒ Nützlichkeit (ist abschätzbar)		:⇒ Nützlichkeit (ist abschätzbar)

Kowa: /* Siehe auch */

2018-12-19T12:21:29Z

Siehe auch

← Nächstältere Version		Version vom 19. Dezember 2018, 12:21 Uhr
Zeile 265:		Zeile 265:
	#{{Vgl\|Wikipedia (EN): DRY}}		#{{Vgl\|Wikipedia (EN): DRY}}
	#[[WikipediaEn:Category:Programmingprinciples]]		#[[WikipediaEn:Category:Programmingprinciples]]
	#[[Wikipedia:Prinzipien ~~Objektorientierten~~ Designs]]		#[[Wikipedia:Prinzipien objektorientierten Designs]]
	#[[WikipediaEn:Code smell]]		#[[WikipediaEn:Code smell]]

Kowa: /* Modularität, Modularity, Teile und herrsche, Divide et impera */

2018-11-29T09:18:22Z

Modularität, Modularity, Teile und herrsche, Divide et impera

← Nächstältere Version		Version vom 29. November 2018, 09:18 Uhr
Zeile 145:		Zeile 145:

	===Modularität, Modularity, Teile und herrsche, Divide et impera===		===Modularität, Modularity, Teile und herrsche, Divide et impera===
	;Teile und herrsche: Ein komplexes Problem (Vorhaben, Projekt, ...) kann man nur dadurch in den Griff bekommen, dass man es solange in kleinere, möglichst unabhängige Teilprobleme (Teilvorhaben, Phasen, Vorgänge, ...) zerlegt, bis diese lösbar (= beherrschbar) sind. Ein Programm sollte daher '''modularisiert''', d.h. in einzelne '''Module''' unterteilt werden.		;Teile und herrsche: Ein komplexes Problem (Vorhaben, Projekt, ...) kann man nur dadurch in den Griff bekommen, dass man es solange in kleinere, möglichst unabhängige Teilprobleme (Teilvorhaben, Phasen, Vorgänge, ...) zerlegt, bis diese lösbar (= beherrschbar) sind. Ein Programm sollte daher '''modularisiert''', d.h. in einzelne '''Module''' unterteilt werden. Jedes Modul sollte nur für eine Aufgabe zuständig sein und diese korrekt und robust erfüllen.

	====Fünf Anforderungen von Bertrand Meyer====		====Fünf Anforderungen von Bertrand Meyer====

← Nächstältere Version		Version vom 6. April 2022, 15:29 Uhr
Zeile 101:		Zeile 101:
	;Wiederhole dich nicht.: Code sollte nicht dupliziert und anschließend aber gar nicht oder nur marginal modifiziert werden.		;Wiederhole dich nicht.: Code sollte nicht dupliziert und anschließend aber gar nicht oder nur marginal modifiziert werden.
	:→ Stetigkeit (→ Wartbarkeit, Wiederverwendbarkeit)		:→ Stetigkeit (→ Wartbarkeit, Wiederverwendbarkeit)
	:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit)
	:→ Robustheit (da keine inkonsistenten Änderungen an mehreren Stellen möglich sind)		:→ Robustheit (da keine inkonsistenten Änderungen an mehreren Stellen möglich sind)

Zeile 107:		Zeile 107:
	;Wiederhole dich.: In Benutzerschnittstellen sollten gleiche oder vergleichbare Aufgaben immer auf dieselbe Weise vom Benutzer durchgeführt werden können. Es sollten dieselben Bezeichner, dieselben bzw. gleichartige Bedienelemente, dasselbe Design etc. verwendet werden.		;Wiederhole dich.: In Benutzerschnittstellen sollten gleiche oder vergleichbare Aufgaben immer auf dieselbe Weise vom Benutzer durchgeführt werden können. Es sollten dieselben Bezeichner, dieselben bzw. gleichartige Bedienelemente, dasselbe Design etc. verwendet werden.
	:→ Wiederverwendbarkeit (da gleichartige Elemente nicht mehrfach implementiert werden müssen; DRY)		:→ Wiederverwendbarkeit (da gleichartige Elemente nicht mehrfach implementiert werden müssen; DRY)
	:→ Stetigkeit (→ Wartbarkeit~~, Erweiterbarkeit~~, Wiederverwendbarkeit)		:→ Stetigkeit (→ Wartbarkeit, Wiederverwendbarkeit)
	:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit)

	===[[Gesetz von Demeter]]<ref>{{Quelle\|Lieberherr, Holland (1989)}}</ref>, Law of Demeter, LoD===		===[[Gesetz von Demeter]]<ref>{{Quelle\|Lieberherr, Holland (1989)}}</ref>, Law of Demeter, LoD===
Zeile 116:		Zeile 116:
	*Objekte, die mittels Parametern beim Methodenaufruf übergeben wurden		*Objekte, die mittels Parametern beim Methodenaufruf übergeben wurden
	*Objekte, die das aktuelle Objekt selbst erzeugt hat		*Objekte, die das aktuelle Objekt selbst erzeugt hat
	:→ Stetigkeit (→ Wartbarkeit~~, Erweiterbarkeit~~, Wiederverwendbarkeit)		:→ Stetigkeit (→ Wartbarkeit, Wiederverwendbarkeit)
	:→ Verständlichkeit (da die Anzahl der Kommunikationspartner geringer ist) (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (da die Anzahl der Kommunikationspartner geringer ist) (→ Korrektheit, Robustheit, Wartbarkeit)

	===[[Überprüfbarkeit]], Verifiability===		===[[Überprüfbarkeit]], Verifiability===
Zeile 128:		Zeile 128:
	;Benutze Schnittstellen zur Kommunikation mit Objekten, Modulen etc.: Die Verwendung von Schnittstellen zum Zugriff auf und zur Modifikation von Daten/Informationen (an Stelle eines direkten Zugriffes) ermöglicht es, Code lokal zu ändern, ohne dass dies Auswirkungen auf andere Objekte, Module etc. hat (solange sich die Schnittstellen nicht ändern).		;Benutze Schnittstellen zur Kommunikation mit Objekten, Modulen etc.: Die Verwendung von Schnittstellen zum Zugriff auf und zur Modifikation von Daten/Informationen (an Stelle eines direkten Zugriffes) ermöglicht es, Code lokal zu ändern, ohne dass dies Auswirkungen auf andere Objekte, Module etc. hat (solange sich die Schnittstellen nicht ändern).
	:→ Spezifikation		:→ Spezifikation
	:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit)
	:→ Stetigkeit (→ Wartbarkeit~~, Erweiterbarkeit~~, Wiederverwendbarkeit)		:→ Stetigkeit (→ Wartbarkeit, Wiederverwendbarkeit)
	:→ Überprüfbarkeit (→ Korrektheit, Robustheit, Portierbarkeit)		:→ Überprüfbarkeit (→ Korrektheit, Robustheit, Portierbarkeit)
	:→ Modularität		:→ Modularität
Zeile 155:		Zeile 155:
	=====Modulare Zerlegbarkeit, modular decomposability=====		=====Modulare Zerlegbarkeit, modular decomposability=====
	;Zerlege ein Problem in unterschiedliche, seperat lösbare Teilprobleme.		;Zerlege ein Problem in unterschiedliche, seperat lösbare Teilprobleme.
	:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit)
	:→ Wiederverwendbarkeit (wenn die Module weitgehend unabhängig voneinander sind)		:→ Wiederverwendbarkeit (wenn die Module weitgehend unabhängig voneinander sind)
	~~:→ Erweiterbarkeit~~

	=====Modulare Zusammenfügbarkeit, modular composability=====		=====Modulare Zusammenfügbarkeit, modular composability=====
	;Module sollten in möglichst vielen (unterschiedlichen) Situationen/Anwendungen eingesetzt werden können.		;Module sollten in möglichst vielen (unterschiedlichen) Situationen/Anwendungen eingesetzt werden können.
	:Das heißt, Module sollten auf unterschiedliche Art und Weise zu neuen Funktionseinheiten zusammengefügt werden können.		:Das heißt, Module sollten auf unterschiedliche Art und Weise zu neuen Funktionseinheiten zusammengefügt werden können.
			:→ Wartbarkeit
	:→ Wiederverwendbarkeit		:→ Wiederverwendbarkeit
	~~:→ Erweiterbarkeit~~
	~~:→ Wartbarkeit~~
	:→ Überprüfbarkeit (→ Korrektheit, Robustheit, Portierbarkeit)		:→ Überprüfbarkeit (→ Korrektheit, Robustheit, Portierbarkeit)

	=====Modulare Verständlichkeit, modular understandability=====		=====Modulare Verständlichkeit, modular understandability=====
	;Die Aufgaben eines Moduls sollten verstanden werden, ohne dass man viele andere Module kennen muss.		;Die Aufgaben eines Moduls sollten verstanden werden, ohne dass man viele andere Module kennen muss.
	:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit)

	''Dies ist ein Spezialfall des Prinzips „[[#Verst.C3.A4ndlichkeit.2C_Comprehesibility.2C_Lesbarkeit.2C_Readability\|Verständlichkeit]]“.''		''Dies ist ein Spezialfall des Prinzips „[[#Verst.C3.A4ndlichkeit.2C_Comprehesibility.2C_Lesbarkeit.2C_Readability\|Verständlichkeit]]“.''
Zeile 176:		Zeile 174:
	;Kleine Änderungen an den Anforderungen sollten nur Änderungen an einer geringen Zahl von Modulen zur Folgen haben.		;Kleine Änderungen an den Anforderungen sollten nur Änderungen an einer geringen Zahl von Modulen zur Folgen haben.
	:Im besten Fall ist nur ein einziges Modul betroffen.		:Im besten Fall ist nur ein einziges Modul betroffen.
	:→ Stetigkeit (→ Wartbarkeit~~, Erweiterbarkeit~~, Wiederverwendbarkeit)		:→ Stetigkeit (→ Wartbarkeit, Wiederverwendbarkeit)

	''Dies ist ein Spezialfall des Prinzips „[[#Stetigkeit.2C_Continuity\|Stetigkeit]]“.''		''Dies ist ein Spezialfall des Prinzips „[[#Stetigkeit.2C_Continuity\|Stetigkeit]]“.''
Zeile 203:		Zeile 201:
	; Module sollten wenige Schnittstellen haben.: Module sollten mit so wenig anderen Modulen kommunizieren wie möglich.		; Module sollten wenige Schnittstellen haben.: Module sollten mit so wenig anderen Modulen kommunizieren wie möglich.
	:→ Wiederverwendbarkeit		:→ Wiederverwendbarkeit
	:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit)

	=====Schlanke Interfaces, Small Interfaces=====		=====Schlanke Interfaces, Small Interfaces=====
Zeile 212:		Zeile 210:
	=====Explizite Schnittstellen, Explicit Interfaces=====		=====Explizite Schnittstellen, Explicit Interfaces=====
	; Module sollten über explizite Schnittstellen kommunizieren.: Ein Modul sollte nicht über globale Variablen oder andere implizite Kommunikationswege mit anderen Modulen kommunizieren, sondern über explizite Schnittstellen.		; Module sollten über explizite Schnittstellen kommunizieren.: Ein Modul sollte nicht über globale Variablen oder andere implizite Kommunikationswege mit anderen Modulen kommunizieren, sondern über explizite Schnittstellen.
	:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit)

	=====(Daten-)[[Kapselung]], Geheimnisprinzip, Encapsulation, Information Hiding=====		=====(Daten-)[[Kapselung]], Geheimnisprinzip, Encapsulation, Information Hiding=====
Zeile 220:		Zeile 218:
	:→ Überprüfbarkeit (→ Korrektheit, Robustheit, Portierbarkeit)		:→ Überprüfbarkeit (→ Korrektheit, Robustheit, Portierbarkeit)
	:→ Wiederverwendbarkeit		:→ Wiederverwendbarkeit
	:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit)

	=====Offen-geschlossen-Prinzip, Open-Closed Principle=====		=====Offen-geschlossen-Prinzip, Open-Closed Principle=====
Zeile 238:		Zeile 236:
	:→ Korrektheit		:→ Korrektheit
	:→ Robustheit		:→ Robustheit
	:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit~~, Erweiterbarkeit~~)		:→ Verständlichkeit (→ Korrektheit, Robustheit, Wartbarkeit)

	=====[[Separation of Concerns]]<ref>{{Quelle\|Wikipedia (EN): Separation of concerns}}</ref>=====		=====[[Separation of Concerns]]<ref>{{Quelle\|Wikipedia (EN): Separation of concerns}}</ref>=====

← Nächstältere Version		Version vom 14. Mai 2020, 07:29 Uhr
Zeile 7:		Zeile 7:
	}}		}}

	'''Anmerkung''': In diesem Artikel haben die beiden ~~Folgenrungspfeile~~ „→“ und „⇒“ folgende Bedeutungen:		'''Anmerkung''': In diesem Artikel haben die beiden Folgerungspfeile „→“ und „⇒“ folgende Bedeutungen:
	:⇒: „hat zur Folge“		:⇒: „hat zur Folge“
	:→: „trägt bei zu“, „verbessert“, „erhöht“		:→: „trägt bei zu“, „verbessert“, „erhöht“
Zeile 14:		Zeile 14:
	Um nützliche und dennoch preiswerte [[Programm]]e und [[Anwendung]]en erstellen zu können, sollte man eine Reihe von [[Programmierprinzipien]] beachten.		Um nützliche und dennoch preiswerte [[Programm]]e und [[Anwendung]]en erstellen zu können, sollte man eine Reihe von [[Programmierprinzipien]] beachten.

	Bevor die ~~Programmierprinzipen~~ näher beschrieben werden können, werden zunächst die Ziele genauer spezifiziert, die mit diesen Prinzipien erreicht werden sollen.		Bevor die Programmierprinzipien näher beschrieben werden können, werden zunächst die Ziele genauer spezifiziert, die mit diesen Prinzipien erreicht werden sollen.

	==Ziele==		==Ziele==

	Ziel eines jeden Softwareentwicklungs-~~Vorhaben~~ sollte die Erstellung von Software sein, die zwei Eigenschaften aufweist:		Ziel eines jeden Softwareentwicklungs-Vorhabens sollte die Erstellung von Software sein, die zwei Eigenschaften aufweist:

	; nützlich (useful): Die Software sollte für den Benutzer nützlich sein.		; nützlich (useful): Die Software sollte für den Benutzer nützlich sein.
Zeile 42:		Zeile 42:
	:⇒ geringe Schulungskosten		:⇒ geringe Schulungskosten
	:⇒ fehlerhafte Nutzung kommt nur selten vor und hat daher nur selten Kosten zu Folge		:⇒ fehlerhafte Nutzung kommt nur selten vor und hat daher nur selten Kosten zu Folge
	:⇒ keine Kosten durch ~~frustierte~~ Benutzer		:⇒ keine Kosten durch frustrierte Benutzer

	;sicher (secure): Unautorisierter Zugriff auf Daten oder Programme sollte unmöglich sein.		;sicher (secure): Unautorisierter Zugriff auf Daten oder Programme sollte unmöglich sein.
Zeile 56:		Zeile 56:
	Für die Eigenschaft „wartbar“ gibt es drei Spezialfälle, die hier gesondert genannt werden sollen:		Für die Eigenschaft „wartbar“ gibt es drei Spezialfälle, die hier gesondert genannt werden sollen:

	; kompatibel (compatible): Das Softwarepaket sollte ~~komaptibel~~ zu bestehenden Systemen sein, es sollte also standardisierte Schnittstellen unterstützen.		; kompatibel (compatible): Das Softwarepaket sollte kompatibel zu bestehenden Systemen sein, es sollte also standardisierte Schnittstellen unterstützen.
	:⇒ geringe Intergrations- und Anpassungskosten		:⇒ geringe Intergrations- und Anpassungskosten

Zeile 70:		Zeile 70:

	===[[Verständlichkeit]], Comprehesibility, Lesbarkeit, Readability===		===[[Verständlichkeit]], Comprehesibility, Lesbarkeit, Readability===
	;Schreibe lesbaren und verständlichen Code.: Der Programmcode sollte so einfach wie möglich gelesen und verstanden werden können. Das heißt, der Code sollte sauber ~~formartiert~~ werden, es sollten sprechende Bezeichner verwendet werden, es sollten sinnvolle Kommentare eingefügt werden etc. Ein erfahrender Programmierer sollte die Bedeutung der einzelnen Anweisungen, Operationen, ~~Defintionen~~ etc. problemlos erfassen können.		;Schreibe lesbaren und verständlichen Code.: Der Programmcode sollte so einfach wie möglich gelesen und verstanden werden können. Das heißt, der Code sollte sauber formatiert werden, es sollten sprechende Bezeichner verwendet werden, es sollten sinnvolle Kommentare eingefügt werden etc. Ein erfahrender Programmierer sollte die Bedeutung der einzelnen Anweisungen, Operationen, Definitionen etc. problemlos erfassen können.
	:→ Überprüfbarkeit (durch Programmierer und nicht nur durch Compiler u.Ä.) (→ Korrektheit, Robustheit)		:→ Überprüfbarkeit (durch Programmierer und nicht nur durch Compiler u.Ä.) (→ Korrektheit, Robustheit)
	:→ Wartbarkeit (da die Programme auch von anderen Programmierern verstanden werden)		:→ Wartbarkeit (da die Programme auch von anderen Programmierern verstanden werden)
Zeile 100:		Zeile 100:
	:→ Stetigkeit (→ Wartbarkeit, Erweiterbarkeit, Wiederverwendbarkeit)		:→ Stetigkeit (→ Wartbarkeit, Erweiterbarkeit, Wiederverwendbarkeit)
	:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit, Erweiterbarkeit)		:→ Verständlichkeit (da weniger Code existiert) (→ Korrektheit, Robustheit, Wartbarkeit, Erweiterbarkeit)
	:→ Robustheit (da keine ~~inkonsitenten~~ Änderungen an mehreren Stellen möglich sind)		:→ Robustheit (da keine inkonsistenten Änderungen an mehreren Stellen möglich sind)

	===[[Repeat yourself]], RY<ref>{{Quelle\|Kowarschick (MMProg)}}</ref>===		===[[Repeat yourself]], RY<ref>{{Quelle\|Kowarschick (MMProg)}}</ref>===
Zeile 118:		Zeile 118:

	===[[Überprüfbarkeit]], Verifiability===		===[[Überprüfbarkeit]], Verifiability===
	;Schreibe überprüfbaren Code.: Die Korrektheit eines Softwarepakets sollte plattformunabhängig sein und automatisch überprüft werden können. Viele Programmierparadigmen und auch Projekttechniken verlangen zu diesem Zweck, dass gleichzeitig mit der Software auch passende Softwaretests implementiert werden ([[Modultest]]s, [[Unittest]]s). Noch besser ist es, wenn die Semantik des ~~Programmes~~ formal ~~spezifiert~~ und überprüft werden kann ([[Abstrakter Datentyp\|Abstrakte Datentypen]], [[Integritätsbedingung]]en, ...)		;Schreibe überprüfbaren Code.: Die Korrektheit eines Softwarepakets sollte plattformunabhängig sein und automatisch überprüft werden können. Viele Programmierparadigmen und auch Projekttechniken verlangen zu diesem Zweck, dass gleichzeitig mit der Software auch passende Softwaretests implementiert werden ([[Modultest]]s, [[Unittest]]s). Noch besser ist es, wenn die Semantik des Programms formal spezifiziert und überprüft werden kann ([[Abstrakter Datentyp\|Abstrakte Datentypen]], [[Integritätsbedingung]]en, ...)
	:→ Korrektheit (insbesondere, wenn die Erfüllung der Spezifikation [[Verifikation\|verifiziert]], d.h. formal ~~nachgewisen~~ wird)		:→ Korrektheit (insbesondere, wenn die Erfüllung der Spezifikation [[Verifikation\|verifiziert]], d.h. formal nachgewiesen wird)
	:→ Robustheit (wenn die Überprüfungen auch durchgeführt werden)		:→ Robustheit (wenn die Überprüfungen auch durchgeführt werden)
	:→ Portierbarkeit (wegen der Plattformunabhängigkeit)		:→ Portierbarkeit (wegen der Plattformunabhängigkeit)
Zeile 225:		Zeile 225:
	:→ Erweiterbar (wenn Module offen sind)		:→ Erweiterbar (wenn Module offen sind)
	:→ Robustheit (wenn getestete Module geschlossen sind)		:→ Robustheit (wenn getestete Module geschlossen sind)
	:→ Wartbarkeit (wenn ~~funtionierende~~ Module geschlossen sind; jede Änderung an einem Modul hat eventuell weitere Änderungen zu Folgen → dies soll nach Möglichkeit vermieden werden)		:→ Wartbarkeit (wenn funktionierende Module geschlossen sind; jede Änderung an einem Modul hat eventuell weitere Änderungen zu Folgen → dies soll nach Möglichkeit vermieden werden)

	====Weitere Modul-Prinzipien====		====Weitere Modul-Prinzipien====