0

Question:

Does the term "readability" refer also to the transparency of code functionality?

For Example:

I read that a downside of Dependency Injection is a sacrifice to readability. The idea being that to follow all of the strict syntax of a DI library, one has to write much more code than would be required to write the functionality without DI involved. So I quickly imagined up an example DI syntax which would be simpler (and in my mind more readable) than a strict implementation of DI. Something like this.

Note, this code isn't particularly amazing or perfect syntax in any sense, it's just to get the abstraction in my question across:

fooBar
    .focusGroup('Menu')
    .addComponent('menuConfig')
    .addType('service')
    .addInterface('data', 'value');
fooBar
    .focusGroup('Menu')
    .addComponent('subMenuHandler')
    .addType('service')
    .addInterface('handle', 'function');
fooBar
    .focusGroup('Menu')
    .addComponent('menuHandler')
    .addType('client')
    .injectDependency('menuConfig', 'subMenuHandler');

But then it occurred to me that while the functionality of those methods and syntax appears obvious, it might actually be considered less readable because the things that are actually happening have been abstracted behind a simple syntax representing a complex library.

J.Todd
  • 3,833
  • 5
  • 22
  • 27
  • 3
    ...see also [What is the value in hiding the details through abstractions? Isn't there value in transparency?](http://programmers.stackexchange.com/questions/132019/what-is-the-value-in-hiding-the-details-through-abstractions-isnt-there-value) – gnat Sep 27 '15 at 19:54
  • To read this code snippet, one has to know what kind of objects the different member functions return. This is information that has to be looked up and cannot be easily guessed (especially for the `addType()` method, which I would expect to return nothing). So, at the very least, this code fails to be self-explaining. – cmaster - reinstate monica Sep 27 '15 at 19:56
  • You should look into the [builder pattern](https://sourcemaking.com/design_patterns/builder). It looks a lot like the code you have posted, and provides a solution for a similar problem to yours. – cbojar Sep 27 '15 at 20:50
  • @cbojar thanks for that info. The pattern above is actually inspired by the syntax used by JQuery, the most popular JavaScript library. The pattern you linked may very well be what is used by JQuery. It's an especially syntactically convenient strategy in JavaScript. – J.Todd Sep 27 '15 at 20:54
  • 3
    The whole point of abstraction is that I don't want to care about how things get until until/unless it's important that I know. 80% of what we do is hiding complexity. Abstraction, (when done right) improves readability, not decrease it. – RubberDuck Sep 27 '15 at 21:36
  • @cmaster since I wanted even my services to have dependencies, I decided to structure the DI syntax implementation shown there so as to allow each `component` to be a `client` and/or a `service`. `addType()` was a simple idea on how to do that. Besides, it's just like JQuery, every function in the chain returns either a new or mutated version of the selected object. This is commonly understood if you've worked with JQuery in JavaScript. – J.Todd Sep 27 '15 at 22:01
  • 1
    [Intention-revealing names](http://c2.com/cgi/wiki?IntentionRevealingNames) seems to be the answer. Abstraction hides implementation detail, so what remains visible is the name of things, and the way they are used together (in the client's code). The audience (e.g. a programmer recently introduced to the framework) will need to correctly guess the purpose of those things, after minimal training. The only way to find out is to try that - in the way of code reviews by junior, not senior, programmers. – rwong Sep 28 '15 at 01:14

0 Answers0