3

I just wanted to make sure that I understand and can properly articulate the difference between these two concepts.

I've always thought of an implementation detail as being the internal workings of some concrete class behind its exposed public interface.

ie: User:getEmailAddress returns a string. It may fetch this data from one of two private attributes named "email" or "emailAddress".

Whoever is invoking this method doesn't care so long as they receive an email address. This is an implementation detail.

I've noticed that "technical concerns" on the other hand often come up during discussions of Layered Architecture where the Infrastructure layer is responsible for the "How" of our Domain layer which is describing the problem and defining a set of interfaces in order to address that problem.

ie: "How" do I actually send out this email, persist this data, or hash this password as described in the Domain?

One or more classes within the infrastructure layer "may" implement the same interface and these classes which share an interface will by definition address the same technical concern (either sending mail, persisting data, etc).

Would you say that these definitions are accurate?

Thanks.

3

Whenever I describe something as being an "Implementation Detail," I am saying that the user doesn't need to know how it gets done, so long as it gets done.

For example, in C a pointer actually points to a memory address in the computer, but you can't say the same thing about a reference in Java (even though pointers and references both perform essentially the same function), because the manner in which that reference is represented is an implementation detail.

Folks who are not familiar with this characteristic of managed languages sometimes ask questions like "does this value type get created on the heap or the stack?" Again, this is an implementation detail. It's another way of saying, "This is not something you should care about." Implementation details are things that are abstracted away from the user.

"Technical Concern" is a much broader and much more general term. Implementation details are technical concerns, but so is performance, code clarity, scalability, architecture, uptime, storage space and so forth. Pretty much anything that is technical that you might be concerned about is a "technical concern."

  • It's worth noting that the implementation of a pointer is also an implementation detail in C, as is heap vs stack. The Standard does not specify either of those things. – DeadMG May 21 '16 at 18:25
  • 1
    @DeadMG: It seems that you tied "implementation detail" to "specified in the standard." I made no such assertion here; though "it's not in the standard" is a pretty good reason to declare that something is an implementation detail, it's not the only one. – Robert Harvey May 21 '16 at 19:02
  • So if I'm understanding you correctly; Implementation details are a subset of Technical concerns. I'm still unsure how to identify a "technical concern" since your definition appears to encompass literally every conceivable discussion that can be had in the arena of software engineering. The term seems useless on its own for those types of discussions. – user2308097 May 22 '16 at 19:26
  • 1
    Sounds about right. I'd say that "technical concerns" distinguish themselves from other business concerns such as finances, sales performance, time management and so forth, by virtue of the fact that they are "concerns of a technical nature." – Robert Harvey May 22 '16 at 19:40

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.