Interfaces All The Way Down: Difference between revisions
From G30 Consultancy
Jump to navigationJump to search
Created page with "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..." |
No edit summary Tag: 2017 source edit |
||
| (4 intermediate revisions by the same user not shown) | |||
| 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). | ||
------------------------------------------------------- | |||
* [[Why The Walled Garden and Prairie]] | |||
* [[Walls and Trust Nothing]] | |||
* [[G30 Consultants]] | |||
[[Category:Structure]][[Category:Software Structure]][[Category:Walled Garden]] | |||
Latest revision as of 10:35, 17 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).
