{CodingBlocks}.NET

iTunes Spotify PlayerFM Overcast Podchaser Pocket Casts iHeartRadio YouTube feed LinkedIn Twitter Facebook Reddit

Navigation

Clean Architecture – Programming Paradigms

By 27 Comments

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

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 https://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?

How often do you replace your phone?
vote
×

 

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 https://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

Share the joy