1

I'am the only one in my team who advocates for adding a little implicitness in favor of codebase reduction and decreasing repetition. Yet I don't want to be a biased 'Bad apple' playing against working design which was created prior my arrival at this job. Attempts to change the approach can be taken too personal by some teammates and just saying 'mine is better than yours' promisses the opposite result.

Trials to find cons of the proposed and pros of existing solution are the best way to fight against biases - so called 'devil's advocate' game. Unfortunately, it's quite diffcult sometimes.

The broad question sounds like this:

Are there any clear (measurable?) guidelines (besides "it depends") for setting the degree of explicitness/inderection.

The narrow question is quite local, nonetheless I dare to ask for the list of pros and cons of both approaches.

Our server application has several layers: Service, Business Logic, DAL.
For any data modification (create+update, no deletes) we also save authenticated user stamp thus havig the history who did what.

Current implementation gets user name from framework MVC/WCF and passes it across the layers as an additional argument to the methods just to pass the value to the next layer until it reaches the session object which manages the transaction. (DAL)

I offer to use AmbientContext approach: Userstamp is set once at the very beginning of the request processing pipeline and then implicitly flows with execution workflow (respecting async) and is accessible by any layer if required. Very similar to Thread.CurrentPrincipal.

  • 1
    Is it possible to easily mock the userstamp in unit tests with ambient context approach? If not, this may be a very strong argument against the approach. – Arseni Mourzenko Dec 15 '14 at 20:49
  • @MainMa Yes, it is easily mocked. – Pavel Voronin Dec 15 '14 at 20:51
  • To me it seems you have a problem with the additional parameter - not with its explicitness. As you say "additional", can you provide (some of) the other parameters also? The chance might be high that the username parameter should be encapsulated in one of the other parameters, so you don't have to deal with it visually all the time. – valenterry Dec 16 '14 at 8:04
2

Are there any clear (measurable?) guidelines (besides "it depends") for setting the degree of explicitness/inderection.

Not many.

The first is the Law of Demeter, which focuses on how many "steps" it takes to get to what you want, which directly relates to your question about indirection.

Another is Tell, don't Ask. If you have some implicit state being carried throughout the program, objects necessarily need to ask about the state rather than being told about it.

Otherwise, it depends...

It is generally accepted that explicitness is better than implicitness. And your example question brings up other soft metrics: code coverage, bug count/severity, and team velocity.

If by making things implicit, you make it difficult/impossible to unit test your code, that is a fairly clear cut downside.

If by making things implicit, you cause there to be more bugs or more severe bugs (possibly due to worse/fewer unit tests? concurrency/reentrancy issues with the implicit state?) then that's a fairly clear cut downside.

If by making things implicit, you make the team produce code slower (harder to write unit tests? Harder to read? More time spent fixing bugs?) then that's a fairly clear cut downside.

And of course the opposite can be true - if implicitness allows you to make more code, with fewer bugs, then the positives are there. Like all other program design, it's a matter of trade-offs.

1

You are asking two very different questions. The former one is not a generalization of the latter, because answering the first won't answer the second.

There are many other things that might influence the second question, like how you would tackle transactions with multiple users and such.

As for the first question, everybody agrees that a shorter solution to the same problem is preferable, provided it can also be understood. There is no absolute guideline for that, since understanding is subjective. Use code reviews to find a sweet spot that works for your particular team.

  • ...also understood just as easily? ...also understood just as reliably by the team? "Also be understood" is a broad qualification. – Telastyn Dec 15 '14 at 20:51
  • @Telastyn You are picking apart a paragraph that when read as a whole makes a very specific qualification in the context of a particular team. So I guess thanks for underlining my point ;) – back2dos Dec 15 '14 at 23:28
  • Thank for pointing to ifs :-) They are applicable to the current design likewise. – Pavel Voronin Dec 16 '14 at 7:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.