Abstract
Consider the typical example of corporate malpractice: insider trading. Say a particular trader has been caught red-handed trading on inside information. Who is to blame for this? If management didn’t know, it’s the trader. But maybe the trader’s peers were in on it, in which case the group manager might be the one responsible. Or perhaps the practice is institutional, in which case it’s the CEO who would take the blame.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
In all likelihood, if we’re talking about banking, nobody gets punished. Nobody was punished for the subprime mortgage crisis. In the LIBOR fixing scandal, only one trader got convicted (six bankers were accused in the United Kingdom but later cleared). What does this have to do with design patterns? Absolutely nothing! Just wanted to share.
- 2.
Actually, there’s a bit of confusion here. The concept of Command-Query Separation (CQS) suggests the separation of operations into commands (which mutate state and yield no value) and queries (which do not mutate anything but yield a value). The GoF does not have a concept of a Query, so we let any encapsulated instruction to a component be called a Command.
- 3.
This is precisely what is done in Reactive Extensions. See the “Memento” chapter for more information.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2020 Dmitri Nesteruk
About this chapter
Cite this chapter
Nesteruk, D. (2020). Chain of Responsibility. In: Design Patterns in .NET Core 3. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-6180-4_14
Download citation
DOI: https://doi.org/10.1007/978-1-4842-6180-4_14
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-6179-8
Online ISBN: 978-1-4842-6180-4
eBook Packages: Professional and Applied ComputingApress Access BooksProfessional and Applied Computing (R0)