Bob Martin SOLID Principles of Object Oriented and Agile Design
People careerCited 3× on HN, 2017–2017
talk · intermediate · evergreen · 2017–2017 on HN
Robert C. Martin (Uncle Bob) gives a talk on the SOLID principles of object-oriented and agile design, in the context of encapsulation and clean code.
Cited in discussions of OO design, access modifiers and private fields, and why writing messy code slows you down.
Up next
15 mo on HNRailsConf 2014 - All the Little Things by Sandi Metz
Confreaks
15 HN recommender · 2015–2025
14 mo on HN"Simple Made Easy" - Rich Hickey (2011)
Strange Loop Conference
14 HN recommender · 2022–2026
13 mo on HN"Making Impossible States Impossible" by Richard Feldman
elm-conf
9 HN recommender · 2017–2026
12 mo on HNHow To Design A Good API and Why it Matters
Google TechTalks
12 HN recommender · 2011–2025
11 mo on HNThe Value of Values with Rich Hickey
InfoQ
10 HN recommender · 2014–2023
10 mo on HNOverwatch Gameplay Architecture and Netcode
GDC Festival of Gaming
16 HN recommender · 2019–2025
11 mo on HNSolving Problems the Clojure Way - Rafal Dittwald
Clojure/north
10 HN recommender · 2019–2025
10 mo on HNLecture 1A: Overview and Introduction to Lisp
MIT OpenCourseWare
10 HN recommender · 2019–2026
11 mo on HNAlan Kay - Normal Considered Harmful
powerfuloutlet
10 HN recommender · 2012–2026
10 mo on HNA Philosophy of Software Design | John Ousterhout | Talks at Google
Talks at Google
11 HN recommender · 2018–2026
10 mo on HN"Uncle" Bob Martin - "The Future of Programming"
Paul Stringer's Mobile Tech
10 HN recommender · 2016–2022
10 mo on HNEffective Programs - 10 Years of Clojure - Rich Hickey
ClojureTV
10 HN recommender · 2017–2026
3 comments from Hacker News
Do they care if a year down the road your maintenance costs increase fivefold? Have they seen the analysis which shows that initial development cost just makes a small fraction of the total cost and that fraction get smaller the longer software is in use? Do they care if a year down the road your TTM times increase tenfold? We know that the bad code slows us down. Why do we write it? Why do we write the code that slows us down? How much does it slow us down? It slows us down a lot. And every time we touch the modules we get slowed down again. Every time we touch bad code it slows us down, what do we write this stuff what slows us down? And the answer to that is: well we have to go fast. I'll let you to deal with the logical inconsistency there, my message to you today is—you don't go fast by writing crap. ▶ this video
The keywords were reserved in the latest spec for just this purpose. I don't think the rationale for their inclusion is a good one. The inclusion of such keywords in languages like C++, Java, etc was well-meaning but a mistake in retrospect. In the presence of global variables and direct assignment these keywords are the PHB approach to information hiding. They require ceremony and diligence to achieve true encapsulation. It's a murky situation at best. See Bob Martin ▶ this video and Bertrand Meyer on Eiffel: link (Bertrand Meyer coined the Open/Closed Principle and is the developer behind Eiffel). At this point though I see their inclusion in JS being almost inevitable. Just another feature to ignore. It'd be nicer if they would look to add syntax for higher-order operators like compose to the language instead of this.
> Except that languages which try to provide facilities for this principle have bolted it on in the wrong way and we as an industry have come to accept some other feature ("public/final/private" keyword languages) to mean we have, "encapsulation," in our language. Actually, there's an interesting talk from Uncle Bob saying exactly that: ▶ this video The idea is that public/private/protected is an attempt to restore some of the "perfect" encapsulation we had with C; and that we lost this encapsulation with OO langages.