Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Thursday August 25 2016, @05:43AM   Printer-friendly
from the weighing-different-approaches dept.

Professional programming is hard: dealing with large amounts of data, network requests which can fail in umpteen bizarro ways, and Gordian Knot style interdependencies. And then, to top it all off, there's all those different programming paradigms to choose from.

For example, in passive programming, communication between program modules happens through public function/method calls.

In reactive programming, communication occurs through publishing events to which subscribers react.

Both styles of programming differ in how they manage state [responsibility]. Both styles differ in how dependencies are expressed. And both styles differ in the strains put on you, the put-upon, well-paid programmer, trying to construct a mental model of the code and its interactions.

In the July/August issue of acmqueue, Andre Medeiros proposes that modules employ both approaches in Dynamics of Change: Why Reactivity Matters — Tame the dynamics of change by centralizing each concern in its own module (open, DOI: 10.1145/2956641.2971330) (DX). He provides an introduction to the two approaches — their advantages and shortcomings — and then illustrates how combining the two provides a clearer presentation of state for the developer.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Thursday August 25 2016, @03:58PM

    by Anonymous Coward on Thursday August 25 2016, @03:58PM (#393078)

    Neither coupling or cohesion are well-defined. And in practice, things naturally intertwine in the domain. Intertwining is both the power and Tums of software.

  • (Score: 3, Informative) by meustrus on Thursday August 25 2016, @04:21PM

    by meustrus (4961) on Thursday August 25 2016, @04:21PM (#393084)

    Coupling is a measure of how much two separate components depend on each other to function. This is a proxy for how many quirks a component has to maintain exactly as-is because other components depend on it working that way.

    Cohesion is a measure of how often code within a single component is reused. This is a proxy for whether that code actually belongs in the same place, which itself is a proxy for whether the component is prone to too much coupling. It's easier to measure cohesion than coupling, however.

    They are basically the same measurement, but coupling refers to the integration between components and cohesion refers to the integration inside a component. The only things that remain to be defined are what a "component" is (should be self-explanatory most of the time) and how to measure the two metrics.

    --
    If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
    • (Score: -1, Redundant) by Anonymous Coward on Thursday August 25 2016, @07:00PM

      by Anonymous Coward on Thursday August 25 2016, @07:00PM (#393142)

      How exactly does one measure dependency? What is the unit of measure?

      • (Score: 0) by Anonymous Coward on Friday August 26 2016, @06:33PM

        by Anonymous Coward on Friday August 26 2016, @06:33PM (#393626)

        I'd like to see some actual examples against code