DEV Community

CodingBlocks

Episode 69 – Clean Architecture – Programming Paradigms

Michael forgets what his favorite part of the show is, Joe makes us wait to learn what his favorite part is, and Allen pronounces it “pair-a-dig-’ems” as we continue our deep dive into Uncle Bob’s latest book: Clean Architecture.

If you’d rather read these show notes on a larger screen instead of your podcast player, head over to http://www.codingblocks.net/episode69.

Sponsors

  • Linode – Use code “CODINGBLOCKS17” for $20 towards hosting (up to four months free!)

Survey says

During this episode, we ask: How often do you replace your phone?

#yop-poll-container-46_yp59f686d4108b4 { width: 1000; background:#fff; padding:10px; color:#555; overflow:hidden; font-size:12px; } #yop-poll-container-46_yp59f686d4108b4 input[type='text'] { margin:0px 0px 5px 0px; padding:2%; width:96%; text-indent:2%; font-size:12px; } .yop-poll-name-46_yp59f686d4108b4 { font-size:14px; font-weight:bold; } #yop-poll-questions-container-46_yp59f686d4108b4 { font-size:14px; margin:5px 0px; } .yop-poll-question-container-46_yp59f686d4108b4 { padding: 2px; } .yop-poll-question-46_yp59f686d4108b4 { font-style: italic; text-align: center; margin-bottom: 21px; margin-top: -10px; width: 100%; } .yop-poll-answers-46_yp59f686d4108b4 { } .yop-poll-answers-46_yp59f686d4108b4 ul { list-style: none outside none; margin: 0; padding: 0; } .yop-poll-li-answer-46_yp59f686d4108b4 { font-style:normal; margin:0px 0px 10px 0px; padding:0px; font-size:12px; margin-bottom:20px; margin-bottom:20px; } .yop-poll-li-answer-46_yp59f686d4108b4 input { margin:0px; float:none; } .yop-poll-li-answer-46_yp59f686d4108b4 label { margin:0px; font-style:normal; font-weight:normal; font-size:12px; float:none; } .yop-poll-results-46_yp59f686d4108b4 { font-size: 12px; font-style: italic; font-weight: normal; margin-left: 15px; } .yop-poll-customs-46_yp59f686d4108b4 { } .yop-poll-customs-46_yp59f686d4108b4 ul { list-style: none outside none; margin: 0; padding: 0; } .yop-poll-li-custom-46_yp59f686d4108b4 { padding:0px; margin:0px; font-size:14px; } /* Start CAPTCHA div style*/ #yop-poll-captcha-input-div-46_yp59f686d4108b4 { margin-top:5px; } #yop-poll-captcha-helpers-div-46_yp59f686d4108b4 { width:30px; float:left; margin-left:5px; height:0px; } #yop-poll-captcha-helpers-div-46_yp59f686d4108b4 img { margin-bottom:2px; } #yop-poll-captcha-image-div-46_yp59f686d4108b4 { margin-bottom:5px; } #yop_poll_captcha_image_46_yp59f686d4108b4 { float:left; } /* End CAPTCHA div style*/ .yop-poll-clear-46_yp59f686d4108b4 { clear:both; } #yop-poll-vote-46_yp59f686d4108b4 { } /* Start Result bar*/ .yop-poll-results-bar-46_yp59f686d4108b4 { background:#f5f5f5; height:10px; } .yop-poll-results-bar-46_yp59f686d4108b4 div { background:#555; height:10px; } /* End Result bar*/ /* Start Vote Button*/ #yop-poll-vote-46_yp59f686d4108b4 div#yop-poll-vote-46_yp59f686d4108b4 button { float:left; } #yop-poll-vote-46_yp59f686d4108b4 div#yop-poll-results-46_yp59f686d4108b4 { float: right; margin-bottom: 20px; margin-top: -20px; width: auto; } #yop-poll-vote-46_yp59f686d4108b4 div#yop-poll-results-46_yp59f686d4108b4 a { color:#555; text-decoration:underline; font-size:12px; } #yop-poll-vote-46_yp59f686d4108b4 div#yop-poll-back-46_yp59f686d4108b4 a { color:#555; text-decoration:underline; font-size:12px; }#yop-poll-vote-46_yp59f686d4108b4 div#yop-poll-archive-46_yp59f686d4108b4 a { color:#555; text-decoration:underline; font-size:12px; } #yop-poll-vote-46_yp59f686d4108b4 div { float:left; width:100%; } /* End Vote Button*/ /* Start Messages*/ #yop-poll-container-error-46_yp59f686d4108b4 { font-size:12px; font-style:italic; color:red; text-transform:lowercase; margin-bottom:20px; text-align:center; } #yop-poll-container-success-46_yp59f686d4108b4 { font-size:12px; font-style:italic; color:green; margin-bottom:20px; text-align:center; } /* End Messages*/ .yop-poll-clear-46_yp59f686d4108b4 { clear: both; }#yop-poll-container-46_yp59f686d4108b4 img { max-width: 1000; } .yop-poll-forms-display{}
How often do you replace your phone?
  • Every year. Gotta have the latest tech.
  • Every other year.
  • Not until it breaks. And maybe not even then.

News

  • Big thanks to everyone that left us a review!
    • iTunes: aantes, dnl.pozzobon, droptablestar, Andreno, AustinWebre, Digital Analogue 9, CynthiaScott, IsThisEasyEnoughToRead?, SquiffyBlarg, Capn’ Barbosa, Burgerman835, Kasprs
    • Stitcher: FabioSchmidberger, KenDickinson, crazycoder, TheRecursiveBaseCase, WorstMilk, CheesyProgrammer, fudge4231, TDSrock, bioprogrammer, gamekid, proofbyinduction, Kaspars Riņķevičs
    • Podchaser: kritner, ArleneAndrews, Medardas, jzack2000
  • What gear do you have that’s ancient that you still use?
  • Friend of the show, Zac Braddy recently got a course released in the MEAP (early access) program, React in Motion: https://www.manning.com/livevideo/react-in-motion
  • Joe and Zac just released a collaborative pair-programming video series pair programming through a React app based on the Marvel Comics API (YouTube)
  • Joe got a review copy of Steve Smith’s (aka @ardalis) course on http://deviq.com. (We referenced his Pluralsight/SOLID course heavily, and recently recommended his new podcast Weekly Dev Tips)
  • Gordian asks “…if there is a room full of programmers working on a project, and if there is another room with just a couple of programmers, which room gets more work done and why?”
  • Allen did some PHP…and….
  • Want some Coding Blocks swag? Check out http://www.codingblocks.net/swag/

Programming Paradigms

Structured Programming bought us Functional Decomposition

  • Programming is hard, and programmers aren’t very good at it
  • Structured programming brought in concepts of mathmatics (proofs, theorems)
  • Subdividing programmers into smaller and smaller pieces until the individual pieces were provably correct (functional decomposition)
  • GOTO became a dirty word, the direct transfer of control broke decomposition and was error prone..and it eventually died
  • The rise of structured programing also made for better modularity
  • Tests show the presence, not the absence of bugs – you can prove something is incorrect, but not correct
  • Math is the discipline of proving provable statements true.
  • Science is the discipline of proving provable statements false.
  • Regarding tests, software is like a science … our tests show correctness by failing to prove incorrectness

Object Oriented Programming bought us…Polymorphism?

  • Some of the main benefits of OO are incrementally better than what we have
    • Modeled after the “real” world
    • Encapsulation is weaker in someways (compared to C header files – can no longer split declaration and implementation into separate files )
    • Inheritance is incrementally better – it’s more formalized and safer now…but it’s not so good anyway
  • The main benefit is trivial Polymorphism
    • Interfaces make things formalized, and safer
    • Allows for safe and reliable indirection
    • Allows us to be device/module independent
    • Enable plugin architectures
    • OO buys you the ability to control the direction of dependencies (typically via dependency inversion)
      • Allows for independent deployability
      • This in turn allows for independent develop-ability!

Functional Programming buys us correctness (at the cost of performance, in some cases)

  • Immutability
    • All race conditions, deadlocks, and concurrent update problems are due to mutable variables
  • Event Sourcing

Recap

  • Structured Programming gave us good direct transfer of control
  • OO gave us indirect transfer of control
  • Functional gave us discipline of assignment
  • Each of these takes something away and restricts us.
  • Software isn’t advancing as fast as we think…take that JavaScript
    • The rules of software haven’t changed since they were originally documented

Design Principles

  • SOLID
  • mid-level software structures that can…
    • Tolerate change
    • Easy to understand
    • Basis of components that can be used in many software systems
  • Can still make a mess even with these mid-level components
  • Common Static Analysis Tools:

S: Single responsibility principle

  • One and only one reason to change
  • Architecture: module should be responsible to one and only one Actor
    • CTO, CFO, COO – calculatePay, calculateOvertime, etc.
    • Changes to one calculatePay would impact all the others
      • Make the data dependency independent of the methods
      • Break out the calculatePay to their own classes
      • Use a facade pattern around the methods
  • Even though you could have done this in your modules, it’s important to think about the change sets in your overall architecture – therefore the actor
  • When applied to the components, it’s the Common Closure Principle
  • When applied to the architecture, it’s the Axis of Change that creates the Architectural Boundaries

O: Open-Closed Principle

  • The system can be changed by adding new code, not modifying existing code
  • Architecturally you want to separate functionality based on hierarchies of how, why and when things change
    • Most core / central should be at the top, most protected from change from lower level components (business rules)
      • Components like the view are lower level components that may get changed (added to as in plugins) more frequently

L: Liskov Substitution Principle

  • Software systems should be created with interchangeable parts that adhere to contracts.
  • In short: “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program” (Thanks Josh Skeen https://www.bignerdranch.com/blog/what-is-the-liskov-substitution-principle/)
  • The ol’ Square / Rectangle problem is a famous violation of the LSP
  • In short, you should build software systems from interchangeable parts which adhere to a contract
  • What about LSP in languages that don’t support interfaces?
    • Still there, just not as good because the “well-defined interfaces” aren’t enforced
    • Interfaces come in many forms these days …
      • C#/Java style classes/interfaces
      • REST interfaces
  • Interesting “real world” example in the book…but how does “L” apply?
  • You’ve got a system that aggregates in feeds
  • One of the feeds is not like the others
  • It can be tempting to “if” it, but Uncle Bob recommends having a feed configuration lookup instead
    • LSP should be applied to the architecture
      • Inability to substitute parts of the architecture can pollute the overall architecture with extra mechanics to overcome it

I: Interface Segregation Principle

  • Don’t make classes depend on other classes/interfaces they don’t need
  • Only take in what you might need
  • Prevents you from taking on dependencies you don’t need, and muddies your interface
  • It’s the difference between saying “requires a boarding pass” and “requires a QR code”
    • Is ISP a language issue, rather than an architecture issue?
      • C-like languages use includes/using/imports that create dependencies
      • Dynamically typed languages don’t have this concept.
        • This is why they create systems that are more flexible and less tightly coupled

D: Dependency Inversion Principle

  • Code that depends on the high level policies should not depend on the code that implements the lower level details.
  • The…DIP?
  • Nothing concrete should be depended on
  • But “nothing” is kinda nuts, so it’s generally acceptable to forget about strings and built-ins
  • Really it’s the volatie concrete elements you want to insulate yourself from
  • Interfaces are less volatile than implentations (every change to the interface requires a change to implimentations, but not the reverse)
  • The coding practices:
    • Don’t refer to volatile concrete classes
    • Don’t derive from volatile concrete classes (What else is there? Abstract)
    • Don’t override concrete functions
    • Never mention the name of anything concrete and volatile
    • DIP violations can’t be removed entirely
  • Notice:  Uncle Bob didn’t use the word “framework” anywhere, it isn’t necessary
  • Factories help
  • You’ll never fully remove your volatiles, but you can consolidate and minimize them
  • It will be the most visible organizing principle in our architecture diagrams

Resources We Like

Tip of the Week

Episode source