Join Steven Lott for an in-depth discussion in this video What could go wrong?, part of Learning S.O.L.I.D. Programming Principles.
- [Voiceover] I'd like to introduce…the SOLID design principles.…There are five principles that I wanna share with you.…First though, I need to share…why these ideas are so important.…Software is always in a state of flux.…It's essential to ask what could go wrong…when making a change to our software.…The state of flux is like tossing pebbles into water.…Each change has ripples.…Ideally, the changes are isolated.…This confines the ripples…so there are no adverse consequences.…
Ripples might be destructive or constructive.…Ideally, programmers can create little dams…so that the ripples are confined to a narrow space…and have no real adverse consequences.…In an OO language, the classes…in principle confine the ripples of change.…Class definitions allow programmers to have…a good separation of concerns.…Algorithms and data structures can be disentangled…for operating system details, for example.…
But pragmatically, the problem is that…separation of concerns is a pretty broad, vague statement.…What does it really mean?…
Author
Steven Lott
Released
6/10/2016To incorporate SOLID into your own development workflow, Steven Lott has prepared a series of lessons that break down the principles one by one, with real-world examples. Learn how to use these principles in the design process, and to test the strength of your code along the way. Steven uses Python to demonstrate the concepts, but they're useful for any object-oriented programming language.
- An overview of SOLID principles
- Segregating code into client-specific modules
- Testing code by substituting subtypes for base classes
- Keeping software open for extension but closed to modification
- Eliminating dependencies on details
- Assigning one responsibility to each class
- Using SOLID principles in the design process
Skill Level Intermediate
Duration
Views
-
Introduction
-
Welcome1m 5s
-
-
1. Introduction to S.O.L.I.D. Programming
-
What could go wrong?3m 26s
-
-
2. Interface Segregation Principle
-
The wrap vs. extend decision4m 48s
-
Extend alternatives4m 49s
-
3. Liskov Substitution Principle
-
Interface variations4m 36s
-
Avoiding isinstance()4m 24s
-
4. The Open/Closed Design Principle
-
Modify a class and fix bugs3m 39s
-
5. Dependency Inversion Principle
-
Testing consequences5m 31s
-
6. Single Responsibility Principle
-
GRASP patterns5m 20s
-
7. A Design Process
-
CRC Cards1m 57s
-
Test-driven design3m 13s
-
-
Conclusion
-
Next steps30s
-
Take notes with your new membership!
Type in the entry box, then click Enter to save your note.
Press on any video thumbnail to jump immediately to the timecode shown.
Notes are saved with you account but can also be exported as plain text, MS Word, PDF, Google Doc, or Evernote.
Share this video
Embed this video
Video: What could go wrong?