Join Steven Lott for an in-depth discussion in this video Default values for parameters, part of S.O.L.I.D. Programming Principles.
- View Offline
- [Voiceover] In my evolving design, I have a deck…and a shoe that are collections of cards.…These can be implemented as lists.…Other features are segregated in to builder functions…that initialize those collections.…Here are some fragments of definitions for DeckBuilder…and ShoeBuilder classes.…A deck always has 52 cards,…but a shoe has some cards removed.…The presence of this extra parameter to remove cards…breaks Liskov's substitution.…
It's not possible to simply use the shoe subclass…in place of the deck superclass.…One approach to implementing Liskov's substitution in Python…is to provide default values for parameters.…Optional parameters make it possible…to replace one class with another.…The default case for DeckBuilder will create one full deck,…providing a value for the parameter means DeckBuilder…can create a number of full decks.…The ShoeBuilder class extends the definition…and removes cards from play.…
Introducing a parameter means the two classes…can now be substituted for each other.…Another approach that makes use of the Python 3 feature…
To 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