Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I wrote a blog post on that topic a while ago: <a href="http://codebetter.com/patricksmacchia/2009/02/01/understanding-code-static-vs-dynamic-dependencies/" rel="nofollow">Understanding Code: Static vs Dynamic Dependencies</a>. Basically you need to make a difference between <i>static dependencies</i>, those that are resolved by the compiler at compile-time, and <i>dynamic dependencies</i>, those that are resolved by the runtime (JVM or CLR) at run-time.</p> <p><i>static dependencies</i> are typically provoked by calls to static/final methods, read/write to a field, in the definition of the class C the implementation of the interface I by C ... all these associations between code elements that can be found explicitly in the bytecode and source code.</p> <p><i>dynamic dependencies</i> are typically provoked by everything that abstracts a method call at compile time, like calls to abstract/virtual methods (polymorphism), variables or parameters typed with an interface (the implementation class is abstracted at compile-time), but also <i>delegates</i> (.NET) or pointers to function (C++).</p> <p>Most of the time, when you'll read about dependencies in the literature, they are talking about <i>static dependencies</i>.</p> <p>A <i>static dependencies</i> is direct (meaning not transitive). A tool like <a href="http://www.NDepend.com" rel="nofollow">NDepend</a> that I mention in the blog post, can also infer <i>indirect (or call it transitive) static dependencies</i> from the set of <i>direct static dependencies</i>.</p> <p>The idea I defend in the blog post is that <b>when it comes to understand and maintain a program, one needs to focus mostly on the static dependencies, the ones found in the source code.</b>. Indeed, abstractions facilities are used to, well ... abstract, implementation for callers. This makes source code much more easy to develop and maintain. There are however situations, typically at debugging time, where one needs to know what's really behind an abstraction at run-time.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload