Summary

Conclusion

Up till now, we’ve seen a total of four ways to address object-oriented design and implementation.

• In previous chapters, we looked at creating objects from scratch, writing all the method definitions ourselves. We’ve emphasized inheritance among the classes in the Sample class hierarchy.
• In this chapter, we’ve seen a stateful class definition using @dataclass. This supports inheritance among the classes in the Sample class hierarchy.
• We’ve also seen a stateless (or immutable) definition using @dataclass(frozen=True). This tends to discourage some aspects of inheritance and favor composition.
• Finally, we’ve looked at stateless (or immutable) definitions using NamedTuple. This must be designed using composition. This preliminary overview of these classes makes the design seem quite simple.

We have a lot of flexibility in Python. It’s important to look at the choices from the viewpoint of our future self, trying to add or alter features. It helps to follow the SOLID design principles and focus on Single Responsibility and Interface Segregation to isolate and encapsulate our class definitions.

Recall

We’ve explored a variety of built-in Python data structures in this chapter. Python lets us do a great deal of object-oriented programming without the overheads of numerous, potentially confusing, class definitions. We can rely on a number of built-in classes where they fit our problem.

In this chapter, we looked at the following:

• Tuples and named tuples let us leverage a simple collection of attributes. We can extend the NamedTuple definition to add methods when those are necessary.
• Dataclasses provide sophisticated collections of attributes. A variety of methods can be provided for us, simplifying the code we need to write.
• Dictionaries are an essential feature, used widely in Python. There are many places where keys are associated with values. The syntax for using the built- in dictionary class makes it easy to use.
• Lists and sets are also first-class parts of Python; our applications can make use of these.
• We also looked at three types of queues. These are more specialized structures with more focused patterns of access than a generic list object. The idea of specialization and narrowing the domain of features can lead to performance improvements, also making the concept widely applicable.

Additionally, in the case study, we looked at ways to use these built-in classes to define the data samples used for testing and training.

Synopsis

We’ve covered several built-in data structures and attempted to understand how to choose one for specific applications. Sometimes, the best thing we can do is create a new class of objects, but often, one of the built-ins provides exactly what we need. When it doesn’t, we can always use inheritance or composition to adapt them to our use cases. We can even override special methods to completely change the behavior of built-in syntaxes.