Indirection Is Not Abstraction

163 点作者 yegor256a超过 6 年前

9 条评论

gregmac超过 6 年前

> The users of this software would be very disappointed if any of these indirections involved adding any number besides 3.What? No, it works great to add numbers beside 3:<pre><code> class Sample { public Sample(IThreeProvider threeProvider) { _threeProvider = threeProvider; } private readonly IThreeProvider _threeProvider; public int AddThree(int val) { return val + _threeProvider.Get().AsInt(); } } public class MyCustomThreeProvider() { public int Get() { return 4; } } </code></pre> Now you can just do:<pre><code> var sample = new Sample(new MyCustomThreeProvider()); sample.AddThree(2); </code></pre> And get 6, as you'd expect. ..So long as you read and fully understood the entire codebase first, anyway.I think this actually highlights one of the bigger problems in adding unnecessary indirections: that it practically begs for strange work-around and hacks and strange layers added on top. It becomes too difficult to change the underlying classes -- eg, changing the AddThree method to handle an arbitrary number means also changing the entire concept of ThreeProviders and everywhere that calls or tests any of the related code -- and as a result it's faster to workaround.

评论 #18356856 未加载

评论 #18357009 未加载

bjpbakker超过 6 年前

Of course the original post about Indirection vs Abstract was by Zed A. Shaw [0].I strongly like to urge authors to give credit where credit is due. IMO this post should have at least mentioned the original article.[0] - <a href="https://zedshaw.com/archive/indirection-is-not-abstraction/" rel="nofollow">https://zedshaw.com/archive/indirection-is-not-abstraction/</a>

评论 #18355230 未加载

评论 #18357178 未加载

taeric超过 6 年前

There is a great margin quote in Concrete Mathematics that overs this general idea, to me:<pre><code> There are two kinds of generalizations. One is cheap and the other is valuable. It is easy to generalize by diluting a little idea with a big terminology. It is much more difficult to prepare a refined and condensed extract from several good ingredients. </code></pre> Attributed to George Pòlya.

评论 #18359705 未加载

layer8超过 6 年前

The use of the word "abstract" in "abstract class" comes from the notion of abstract data types, introduced by Barbara Liskov and Stephen Zilles in 1974 in their paper "Programming with abstract data types" [0], which starts with a section "The Meaninng of Abstraction" (after the introduction). A simplified summary is that this is about having an interface that abstracts from implementation details:> We believe that the above concept captures the fundamental properties of abstract objects. When a programmer makes use of an abstract data object, he is concerned only with the behavior which that object exhibits but not with any details of how that behavior is achieved by means of an implementation.It seems to me that the term "abstract" is justified for abstract classes whose role is to define an interface. (Note that pre-Java "interface" was not a language construct, i.e. the Java equivalent of "interface" is an abstract class in C++.) The article argues that "abstract" should only be used when "details are left out". However, abstract classes leave out the implementation (or at least part of the implementation), so they inherently leave out the respective implementation details.My point is, it is important to understand where the established terms come from, and what is meant by "abstract" in the context of abstract types [1].[0] <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136.3043&rep=rep1&type=pdf" rel="nofollow">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.136...</a>[1] <a href="https://en.wikipedia.org/wiki/Abstract_type" rel="nofollow">https://en.wikipedia.org/wiki/Abstract_type</a>

adrianmonk超过 6 年前

> Languages such as C# and Java have done many a disservice with their keywords abstract and interface. There is a common misconception that by creating an interface one can make an object abstract and improve the design of a system.This doesn't make any sense. In Java, etc., "abstract" is just a technical term relating to the type system. It means these are types which do not have a complete implementation, so instances cannot be created. The word is used as an antonym of concrete, another technical term which describes types that can be instantiated.It doesn't mean any of this stuff about changing the abstraction level or improving the design of the system. The author seems not to understand that a word can have two different meanings even within a single subject area.While I'm griping, if you are looking at the semi-arbitrary choice of programming language keywords and letting that shape the big picture of how you view software design, you're going to have a bad time. "It said 'abstract' so this must be the way of creating abstractions." If that's the type of reasoning you use, the programming language designers aren't the ones doing you a disservice; you are.

评论 #18362299 未加载

ergothus超过 6 年前

> When there are expected dimensions of software change, it can be worth paying the cost to create software with higher flexibility. Flexible software is harder to create, more complex, harder to understand, and harder to maintain.I agree with what is being said, but the way it is coming across doesn't work for me - I had to go back to the first sentence because the "harder to maintain" confused me: What is maintenance if not making changes? If so, flexible (less coupled) software is easier to maintain (over time). But the author's central point feels correct: flexible software is requires more effort to think of writing in that way.What definitions of "maintenance" and "complex" is the author using and how are they different from mine?

评论 #18359468 未加载

jxramos超过 6 年前

> Things which are more concrete are what enables and empowers the abstractions – they make everything work. Without concrete elements, software is nothing more than a beautiful shell of uselessness.That is very profound! I never thought about concrete realities as empowering the notion of an abstraction, its as if an abstraction is a compression of reality/concepts.

yazaddaruvala超过 6 年前

More recently I've started to consider abstraction an optimization of code readability/understandability.Following the rules of optimization, it should only be done when absolutely needed.1. Do not abstract.2. Do not abstract.3. Quantitative measurement of the benefit, then abstract.This has worked out really well for me over the last 3 years.

评论 #18359157 未加载

infinity0超过 6 年前

Instead of developing Guice, Google should have just rewritten their entire codebase in Haskell, which actually has meaningful abstractions, as opposed to the non-abstract indirection crap that is "dependency injection".Fuck Guice.