The Decision to Use Classes
00:10 If you come from a language like Java where everything must be a class, your first tendency in Python might be very Java-like, but Python enables several different coding styles: procedural, which is script-like coding; functional, which uses things like lambdas and map/reduce; and what all the parts of this course have been about, object-oriented concepts.
00:45 Let’s briefly talk about a couple of other popular languages. If you’re coming from Java—or quite frankly, C++, and although I’ve never used it, I suspect C# falls into this bucket as well—simple programs don’t need classes at all. In Python, you should write classes when writing a class is a natural extension of the data you’re encapsulating.
If you have some data attributes you need to keep together and some operations that are dedicated to them, then you might want a class. For shorter programs, you can often get away with using a dictionary, a tuple, or more specifically a
class keyword, you won’t notice much difference syntactically, but the underlying mechanics of inheritance are different, so you might need to be careful as you dig in.
02:11 Unlike most other object-oriented languages, Python does not strictly enforce the concept of private or protected. All things are accessible. There is a convention that members with a leading underscore are non-public and users of your class shouldn’t rely on those kinds of attributes, but it is just a convention.
02:36 There’s also some weird black magic—okay, gray magic, dirty white, off-beige magic—where double underscores cause a member to be name mangled. That’s a fancy way of saying it is automatically renamed.
To indicate you wanted a new-style class, you inherit from the
object class. To declare a person using the new class, it looks like this, where a
Person inherits from
object. Of course, the new in the phrase new-style is rather dated.
03:50 It’s from very long ago. The compatibility supporting both old and new styles was available all the way up to 2.7. Since the end of life of Python 2.7 was in 2020, that new thing continued to exist for almost two decades.
04:14 The old style from before Python 2.2 no longer works. That made the whole inherit-from-object thing seem a little verbose, so its need was dropped. You can still use that syntax if you’d like, especially if you’re writing code that has to be compatible with Python 2 and 3. Essentially, in Python 3, both of these declarations result in the same thing. This, of course, can cause some confusion.
I get why it’s done. It definitely looks better without the
object, but this is a massive foot gun for folks maintaining older code, so be careful if you’re still straddling the Python 2/Python 3 world.
05:17 If you have a small script that doesn’t have a lot of data structures or you need really speedy code, if the code base you’re maintaining already doesn’t, for example, it’s heavily functional or the code is mostly procedural, your teammates will like you better if you stay consistent with the code that exists already. If you’re writing object-oriented code, you don’t necessarily have to use inheritance to gain the advantage of code reuse. Inheritance can be described as an is-a relationship.
06:08 You can still do duck typing and polymorphic interfaces using this mechanism, and there aren’t any surprises. When someone changes a base class—say, adding a method—that trickles down to the children. With composition, that won’t affect you unless you want to call it on the related object.
06:25 There are some special kinds of composition that have their own names. Delegation is composition with execution handoff. Your object references another object, and the owner has methods within which it calls the delegated object.
It’s a kind of wrapper. If you took part two of this course, the
HexColorContainer example was a list delegate exposing its own interface, but implementing the underlying storage with a reference to a non-public list.
07:08 Each call gets proxied to the injected object. This means you can change the behavior of the wrapping class by passing in—injecting—a different object. This pattern can be useful when you want to perform similar tasks on related objects. For example, if you’ve got a class that abstracts database interactions, injecting an object that implements specific database details allows you to code against the generic interface while someone else worries about how it is done.
07:47 This pattern can be very useful for writing more testable code. Testing your generic database object is hard without actually touching a database, but if you injected a fake database implementation, you could test the wrapper with this delegate.
08:13 I’ve bumped into a couple of coders in my life who thought this approach was a religion and thought you should inject all the things. If the only use of a baseball bat you ever saw was it smacking you in the face, it wouldn’t be a surprise if you flinched watching the New York Yankees.
08:33 Object-oriented coding started to come into its own in the 1980s. At the time, there were different languages out there experimenting with the right way of doing things and plenty of academic papers on the subject.
08:45 The first version of C++ was actually a transpiler converting C++ into C code before calling the C compiler. The work in this space resulted in a bunch of tenets describing the right way to do things.
08:58 SOLID is an acronym that covers five of these governing principles. The principles are single responsibility (it should do only one thing), the open-closed principle (you should be able to extend an object without mucking with its internals),
09:15 Liskov substitution principle (a harder way of saying duck typing), interface segregation principle (don’t put stuff in an object that won’t be used), and the dependency inversion principle (that says interacting objects should use an interface between them).
09:43 SOLID is the work of several people. The concepts in SOLID, along with a bunch of others, were in a paper by a Robert C. Martin in 2000. Martin is better known as Uncle Bob in the programming world and was one of the creators of the Agile Manifesto. A few years later, Michael Feathers munged it together in an easier-to-remember acronym.
Become a Member to join the conversation.