Book Image

Getting Started with Python

By : Fabrizio Romano, Benjamin Baka, Dusty Phillips
Book Image

Getting Started with Python

By: Fabrizio Romano, Benjamin Baka, Dusty Phillips

Overview of this book

This Learning Path helps you get comfortable with the world of Python. It starts with a thorough and practical introduction to Python. You’ll quickly start writing programs, building websites, and working with data by harnessing Python's renowned data science libraries. With the power of linked lists, binary searches, and sorting algorithms, you'll easily create complex data structures, such as graphs, stacks, and queues. After understanding cooperative inheritance, you'll expertly raise, handle, and manipulate exceptions. You will effortlessly integrate the object-oriented and not-so-object-oriented aspects of Python, and create maintainable applications using higher level design patterns. Once you’ve covered core topics, you’ll understand the joy of unit testing and just how easy it is to create unit tests. By the end of this Learning Path, you will have built components that are easy to understand, debug, and can be used across different applications. This Learning Path includes content from the following Packt products: • Learn Python Programming - Second Edition by Fabrizio Romano • Python Data Structures and Algorithms by Benjamin Baka • Python 3 Object-Oriented Programming by Dusty Phillips
Table of Contents (31 chapters)
Title Page
Copyright and Credits
About Packt
Stacks and Queues
Hashing and Symbol Tables

The facade pattern

The facade pattern is designed to provide a simple interface to a complex system of components. For complex tasks, we may need to interact with these objects directly, but there is often a typical usage for the system for which these complicated interactions aren't necessary. The facade pattern allows us to define a new object that encapsulates this typical usage of the system. Any time we want access to common functionality, we can use the single object's simplified interface. If another part of the project needs access to more complicated functionality, it is still able to interact with the system directly. The UML diagram for the facade pattern is really dependent on the subsystem, but in a cloudy way, it looks like this:

A facade is, in many ways, like an adapter. The primary difference is that a facade tries to abstract a simpler interface out of a complex one, while an adapter only tries to map one existing interface to another.

Let's write a simple facade for an email...