Balancing Coupling in Software Design

(olano.dev)

5 points | by todsacerdoti 12 hours ago ago

1 comments

  • fuzzfactor 3 hours ago

    I'm no software pro because my code was never intended as wares for sale.

    I made a living by using my own code my damn self, so it was just computer programs, not software proper.

    Not very easy for others to use since there was no need for that, but I start out focused on UI before anything else anyway because it either has to be right to begin with, or capable of making it right under the most non-ideal circumstances later.

    For things I do, UI is about the most unlikely thing to be right to begin with, so then that's where I'm going to shower the most neglect after the UI's achievable ideal concept is written in stone, and nothing more. So I can concentrate on the "rest of the story" that the user may or may not have to interface with under the hood.

    If the UI is going to be absolutely, completely modular for that "easy-replacement later" reason alone, why not everything else?

    I think for modular things to work the best, you have to pay more attention to "coupling" as I understand it. How else is any anticipated "uncoupling" process supposed to follow as logically?

    One thing about inheritance, it can couple things you didn't want coupled if you're not careful :\