„Command-Query-Separation“ – Versionsunterschied
| [gesichtete Version] | [gesichtete Version] |
Aka (Diskussion | Beiträge) K https |
tk k |
||
| Zeile 1: | Zeile 1: | ||
'''{{lang|en|Command-Query-Separation}}''' ('''CQS''',<ref>{{Internetquelle|url=https://martinfowler.com/bliki/CommandQuerySeparation.html|titel=CommandQuerySeparation |
'''{{lang|en|Command-Query-Separation}}''' ('''CQS''',<ref>{{Internetquelle |autor=Martin Fowler |url=https://martinfowler.com/bliki/CommandQuerySeparation.html |titel=CommandQuerySeparation |datum=2005-12-05 |sprache=en |abruf=2014-05-18}}</ref> {{enS}} für etwa ''Kommando-Abfrage-Trennung'') ist ein Prinzip des [[Softwareentwurf]]s. Das CQS-Prinzip wurde von [[Bertrand Meyer]] im Zuge seiner Arbeit an der [[Programmiersprache]] [[Eiffel (Programmiersprache)|Eiffel]] erdacht. |
||
Das CQS-Prinzip besagt, dass eine Methode entweder als ''Abfrage'' (''{{lang|en|query}}'') oder als ''Kommando'' (''{{lang|en|command}}'', ''{{lang|en|modifier}}'' oder ''{{lang|en|mutator}}'') implementiert werden soll. Eine Abfrage muss hierbei [[Daten]] zurückliefern und darf keine [[Wirkung (Informatik)| |
Das CQS-Prinzip besagt, dass eine Methode entweder als ''Abfrage'' (''{{lang|en|query}}'') oder als ''Kommando'' (''{{lang|en|command}}'', ''{{lang|en|modifier}}'' oder ''{{lang|en|mutator}}'') implementiert werden soll. Eine Abfrage muss hierbei [[Daten]] zurückliefern und darf keine [[Wirkung (Informatik)|Seiteneffekte]] auf dem beobachtbaren Zustand des Systems aufweisen, während ein Kommando beobachtbare Nebeneffekte aufweist und keine Daten zurückliefert. |
||
{{Zitat |
{{Zitat |
||
|Text=Functions should not produce abstract side effects |
|Text=Functions should not produce abstract side effects … only commands (procedures) will be permitted to produce side effects. |
||
|Sprache= |
|Sprache=en |
||
|Autor=Bertrand Meyer |
|Autor=Bertrand Meyer |
||
|Quelle=Object Oriented Software Construction |
|Quelle=Object Oriented Software Construction |
||
|Übersetzung=Funktionen sollten keine Seiteneffekte haben |
|Übersetzung=Funktionen sollten keine Seiteneffekte haben … nur Kommandos (Prozeduren) dürfen Seiteneffekte haben. |
||
|ref=<ref>{{Literatur |Autor=Bertrand Meyer |Titel=Object Oriented Software Construction |Verlag=Prentice Hall |Datum=1988 |ISBN=978-0-13-629155-8 |Seiten=751}}</ref>}} |
|ref=<ref>{{Literatur |Autor=Bertrand Meyer |Titel=Object Oriented Software Construction |Verlag=Prentice Hall |Datum=1988 |ISBN=978-0-13-629155-8 |Seiten=751}}</ref>}} |
||
| Zeile 18: | Zeile 18: | ||
* [[Command-Query-Responsibility-Segregation]] (CQRS) |
* [[Command-Query-Responsibility-Segregation]] (CQRS) |
||
== |
== Einzelnachweise == |
||
<references /> |
<references /> |
||
Version vom 12. November 2021, 16:08 Uhr
Command-Query-Separation (CQS,[1] englisch für etwa Kommando-Abfrage-Trennung) ist ein Prinzip des Softwareentwurfs. Das CQS-Prinzip wurde von Bertrand Meyer im Zuge seiner Arbeit an der Programmiersprache Eiffel erdacht.
Das CQS-Prinzip besagt, dass eine Methode entweder als Abfrage (query) oder als Kommando (command, modifier oder mutator) implementiert werden soll. Eine Abfrage muss hierbei Daten zurückliefern und darf keine Seiteneffekte auf dem beobachtbaren Zustand des Systems aufweisen, während ein Kommando beobachtbare Nebeneffekte aufweist und keine Daten zurückliefert.
“Functions should not produce abstract side effects … only commands (procedures) will be permitted to produce side effects.”
„Funktionen sollten keine Seiteneffekte haben … nur Kommandos (Prozeduren) dürfen Seiteneffekte haben.“
Das Prinzip verbietet nur abstrakte Seiteneffekte für Kommandos. Bertrand Meyer unterscheidet davon zwei Arten harmloser Seiteneffekte, die oft sogar für Kommandos notwendig sind:
- Seiteneffekte, die am Ende des Kommandos wieder zurückgenommen werden.
- Seiteneffekte, die nur den privaten State des Objektes betreffen, also von außen nicht wahrnehmbar sind.
Siehe auch
Einzelnachweise
- ↑ Martin Fowler: CommandQuerySeparation. 5. Dezember 2005, abgerufen am 18. Mai 2014 (englisch).
- ↑ Bertrand Meyer: Object Oriented Software Construction. Prentice Hall, 1988, ISBN 978-0-13-629155-8, S. 751.