Last active
July 30, 2018 14:11
-
-
Save ralfw/bc9fafd1d80f4d96e3d1357c4455f932 to your computer and use it in GitHub Desktop.
IOSP Example
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
void Classify(string number, Action<int> onArabic, Action<string> onRoman) { | |
if (int.TryParse(number, out var arabicNumber)) | |
onArabic(arabicNumber); | |
else | |
onRoman(number); | |
} | |
/* | |
* Note how all details about how classification works are hidden in the function Classify(). | |
* It's not visible to the outside wheter an "if" is used or a table lookup or whatever. | |
* In additon the classification also passes on an arabic number as an integer. If you're picky about the SRP | |
* this might be too much of a responsibility for Classify(). | |
*/ | |
var number = AskUserForNumberToConvert(); | |
Classify(number, | |
onArabic: ProcessArabic, | |
onRoman: ProcessRoman); | |
//--- Alternative without IOSP | |
var number = AskUserForNumberToConvert(); | |
if (NumberIsArabic(number)) | |
ProcessArabic(int.Parse(number)); | |
else | |
ProcessRoman(number); | |
/* | |
* This still is easy to understand. The process flow is straightforward. The condition details are hidden in NumberIsArabic(). | |
* However, the mere decision that an "if" is sufficient for classification is visible. What, if more number classes have to | |
* be recognized? Then the whole approach would change to maybe a "switch" or some other means. This would have ramifications on | |
* the calling code. | |
* If the same happened in the IOSP solution then only more continuations would need to be passed to Classify(). | |
* | |
* Also, the non-IOSP version is in violation of the SLA. Calling functions is on a higher level of abstraction than | |
* the "if" control statement - even here where the condition is wrapped in its own function. | |
* Behaviour creating language features are by definition lower level than integrations of behaviour creating | |
* language features (aka functions). | |
*/ | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
An extreme simple example, but interesting to analyze. A trifle should be noted. IMHO side effects (process) should handled in a higher integration layer.
business domain operation(s)
framework/technical domain operation(s)
integration
...