Interfaces All The Way Down: Difference between revisions
From G30 Consultancy
Jump to navigationJump to search
No edit summary Tag: 2017 source edit |
No edit summary Tag: 2017 source edit |
||
| Line 1: | Line 1: | ||
A common habit when coding a new service, or class object with methods is to postpone actually writing the code that does the thing by adding another layer. The initial impetus to this is Good, abstract the detail from the caller, use the interface to be able to flex what the code does and so on. Often though it becomes a kind of procrastination; oh this layer isn't quite right, | A common habit when coding a new service, or class object with methods is to postpone actually writing the code that does the thing by adding another layer. The initial impetus to this is Good, abstract the detail from the caller, use the interface to be able to flex what the code does and so on. Often though it becomes a kind of procrastination; oh this layer isn't quite right, I need to orchestrate some dependency and filter what happens depending upon some logic that really doesn't belong at this level. And one of the ways out of that conundrum is to make another layer (or in some languages have a friend class). | ||
------------------------------------------------------- | ------------------------------------------------------- | ||
Revision as of 12:03, 6 September 2024
A common habit when coding a new service, or class object with methods is to postpone actually writing the code that does the thing by adding another layer. The initial impetus to this is Good, abstract the detail from the caller, use the interface to be able to flex what the code does and so on. Often though it becomes a kind of procrastination; oh this layer isn't quite right, I need to orchestrate some dependency and filter what happens depending upon some logic that really doesn't belong at this level. And one of the ways out of that conundrum is to make another layer (or in some languages have a friend class).
