After trying to understand the AbstractionInversion antipattern, I wonder if this pattern is really a unique pattern and not actually more like a combination of other, more abstract AntiPatterns.
Is AbstractionInversion a special case of code duplication, where a dependend class not only duplicates effort, but also escapes its level in a stack of abstracness layers inside an application?
It seems to be common to most examples I have read so far, that AbstractionInversion occurs in conjunction with code/concept duplication in two dependent modules with diffrent levels of abstraction. To explain my thought I will rely on the ADA RendezVous example mentioned here.
If i.e. a mutex is implemented by using the RendezVous concept, a mutex concept is actually implemented by using something at least as complex as a mutex, and code is likely duplicated.
Furthermore the one-class-one responsibility rule seems violated in the above example, as the abstraction to the gory details of the model relate to the concepts used in order implement the level of abstraction used by a dependend class, that itselfs tries to escape its level of abstraction by using concepts with a much lower level of abstractness that would actually be appropriate for the position of the dependent class in the hierachy of abstractions.
Does AOP solve the problem?
Another observation in the ADA example is, that abstraction invsersion stems from some backdraws of object oriented desing, wich lacks efficient and clear modeling of cross cutting concerns(like Mutexes), and therefore confuses unexperienced developers, by creating the temptation to include certain aspects into strict hierachies of abstractions, aka class hierachies, even if this is not required by the application domain, but merely by technical issues.
Is AbstractionInversion a special case of code duplication, where a dependend class not only duplicates effort, but also escapes its level in a stack of abstracness layers inside an application?
It seems to be common to most examples I have read so far, that AbstractionInversion occurs in conjunction with code/concept duplication in two dependent modules with diffrent levels of abstraction. To explain my thought I will rely on the ADA RendezVous example mentioned here.
If i.e. a mutex is implemented by using the RendezVous concept, a mutex concept is actually implemented by using something at least as complex as a mutex, and code is likely duplicated.
Furthermore the one-class-one responsibility rule seems violated in the above example, as the abstraction to the gory details of the model relate to the concepts used in order implement the level of abstraction used by a dependend class, that itselfs tries to escape its level of abstraction by using concepts with a much lower level of abstractness that would actually be appropriate for the position of the dependent class in the hierachy of abstractions.
Does AOP solve the problem?
Another observation in the ADA example is, that abstraction invsersion stems from some backdraws of object oriented desing, wich lacks efficient and clear modeling of cross cutting concerns(like Mutexes), and therefore confuses unexperienced developers, by creating the temptation to include certain aspects into strict hierachies of abstractions, aka class hierachies, even if this is not required by the application domain, but merely by technical issues.
Comments