Aug 14, 20244 min read

Base Classes: The Unsung Heroes of Your Code

Updated: Aug 20, 2024

Imagine you’re constructing a skyscraper without a blueprint. You lay down a foundation and start building vertically, only to see your structure lose stability and come crashing down.

That’s what coding without a base class is like. They are an essential first step, ensuring consistency and saving time in the long run.

I’ve reviewed countless codebases - nearly all use third-party base classes without wrapping them in their custom base classes.

Is your code clean and efficient? You might need to include a trick.

Here are some tips for developers working on their code base to keep them clean and efficient.

General benefits of using a Base Class

Code reusability - common attributes and methods can be defined once in the base class, reducing code duplication.
Maintainability - changes to shared logic can be made in one place, improving code maintainability.
Extensibility - new models can be easily created by inheriting from the base class, ensuring consistency.
Polymorphism - enables the uniform treatment of objects of different derived classes, leading to more flexible code.
Future-Proofing - Provides a structure for potential future features, such as caching, error handling, or soft delete mechanisms.

Let's talk Python.

Think of SQLAlchemy's db.Model as a fantastic base class. It gives your models a solid foundation with automatic table creation and querying.

But why stop there? Let's add bake-in our own superpowers:

Built-in timestamps - Automatically track creation and update times for all your models.
Customizable behavior - Create hooks for common operations like updating data.
Soft deletes - Instead of removing data, mark it as deleted for easier recovery.

The Base Class as a Blueprint

Let’s create a MyAppModel class inheriting from SQLAlchemy's db.Model.

We’ll start by adding two columns to all our models -

1) Built-in timestamps - Adding createdAt. and updatedAt fields to all models

Here, MyAppModel appends two columns to every table we created and establishes a common structure with expected fields of createdAt and updatedAt.

Creating a sequence ‘id’ field for all models is also a good practice.

This can be easily applied with a base class by creating a default sequence field for ‘id’ for all models and positioning it as the first field of the model so it is better represented in our database -

Creating a sequence ‘id’ field as the first field of the model

And here’s the actual table created -

2) Customizable behavior - Update your update (timestamp)

Now, we can add default functionality so that every time a record is updated, it’ll automatically stamp the current time into the updatedAt column. Add the below to MyAppModel -

By defining the update method within the MyAppModel, we ensure that all child models inherit this functionality. Call the update() method instead of scattered updates in your codebase whenever a model instance needs to be updated.

Example usage -

Calling update() created in our base class

3) Soft-delete - Keeping history alive

Sometimes, deleting data entirely could be better. You may need to keep track of historical information or allow for potential recovery. That's where "soft deletes" come in.

Instead of saying goodbye forever, we can mark a record as "deleted" with a timestamp. This tells the application to ignore it while keeping the data readily available.

In this case, many use the isDeleted boolean column, which allows us to ‘True’ or ‘False’ values. I’d instead use a date field, so if it’s not Null, we’ll have extra data on when this record was deleted.

Here's the magic MyAppModel allows us -

Benefits -

Peace of mind - No accidental data loss
Historical insights - Track deleted records for auditing or analysis
Potential recovery - Easily bring back "deleted" data if needed

Now, fetching active records becomes a breeze -

Important note

This is still prone to bugs. What if the programmer forgets to add the ‘deletedAt = None’ condition? You guessed it: You can and MUST enforce this condition as part of the base class to ensure all queries for active records automatically exclude soft-deleted entries, promoting data integrity and preventing potential errors.

I will cover this in a future post, exploring how to leverage this soft delete power even further.

Conclusion

Base classes are the unsung heroes of code organization.

While creating a base class initially might seem unnecessary, it's often a wise investment in the long term. Establishing a solid foundation will better equip you to handle future requirements and maintain a clean, scalable codebase.

At WiziWill, we believe in crafting code that stands the test of time. Base classes are a cornerstone of our development philosophy, helping us deliver exceptional software solutions that meet our customers' evolving needs.

Want to support our quest at WiziWill to protect our digital legacy?

Here's how -

Head over to WiziWill.com and check us out! You can join the waitlist as we work hard to make things awesome.
Give this post a thunderous round of applause (50 times is the magic number). We developers thrive on validation (and maybe a little caffeine).
Leave a comment below and tell us your thoughts! Did you learn something new? Highlight your favorite part of the post. Do you have a burning question about base classes? I’m all ears.
Sharing is caring, and it helps others find the juicy bits.

By taking these simple steps, you'll be helping WiziWill (and me, your friendly neighborhood code enthusiast) on our journey to make the digital world a more organized and stress-free place.