During my work as a software engineer, I've discovered that certain computer science modules have remained invaluable. These modules have played a significant role in both grasping new concepts and tackling everyday problems at work. Here are a few that frequently come to mind.
This post is inspired by the content from Brandon Rhodes on The Composition Over Inheritance Principle, which I found particularly intriguing. My aim in this post is to review and rewrite the code examples from my perspective.
This article reflects on the blog posts, The Prebound Method Pattern and The Sentinel Object Pattern, by Brandon Rhodes. I'll briefly summarize the patterns and discuss my thoughts on them.
This pattern can be observed when using built-in functions such as random and logging. Instead of needing to create a new instance of the class, we can simply call the function directly. This is possible because a default instance is created within the module, and the instance method is assigned to the module's global namespace.
For example, a logger could be created as follows:
class Logger:
def __init__(self, name):
self.name = name
def log(self, message):
print(f"{self.name}: {message}")
_default_logger = Logger("default")
log = _default_logger.log
The log method is assigned to the module's global namespace, allowing it to be called directly. This is a simple example, but it's useful when you want to create and use a default instance of a class without needing to create a new one.
This supports the usage of the logger as follows:
import logger
logger.log("Hello World")
This pattern isn't super common, but it's a neat trick to know about. It feels a bit like the singleton pattern. However, since we don't restrict the number of instances that can be created, it's not truly a singleton.
This pattern highlights that, despite Python's support for None, we can sometimes provide a more meaningful value to represent a missing value. This is particularly useful when we need to differentiate between a missing value and a valid one.
To illustrate with a similar example from the original article, consider the context of open-source software, where we might want to specify the type of license. We could use None to represent an unspecified license type. However, a valid alternative could be to assign it to a License object that clearly indicates the type of license (e.g., "not specified" or "unlicensed", which may mean different things).
To give a similar example provided in the original article, suppose in the context of open source software, we want to provide a value of the license type. We can use None to represent the case where the license type is not specified. However, a valid alternative could be assigning it to a License object that clearly indicates the type of license (whether it is "not specified" or "unlicensed", they may mean different things).
Here's an example of the pattern in action:
class License:
def __init__(self, name):
self.name = name
def get_name(self):
return self.name
class Package:
def __init__(self, name, license):
self.name = name
self.license = license
# INSTEAD OF
packages = [
Package("dummy1", None),
Package("dummy2", License("BSD")),
]
for package in packages:
if package.license is None:
print("not specified")
else:
print(package.license.get_name())
# WE CAN USE
UNLICENSED = License("unlicensed")
NOT_SPECIFIED = License("not specified")
packages = [
Package("dummy1", UNLICENSED),
Package("dummy2", NOT_SPECIFIED),
Package("dummy3", License("BSD")),
]
for package in packages:
print(package.license.get_name())
The advantage here is replacing None with more explicit values, which documents the intent more clearly. This may also reduce the need for None checks in the code.
The two patterns are subtle but can be quite useful in certain cases. It's good to be aware of them and use them when appropriate. The original articles are also worth reading for more detailed explanations.