Hook
When two classes share the same fields and the same boilerplate methods, copying code between them isn't a design decision — it's a debt that compounds every time something changes.
Why It Matters
Without inheritance, identical logic like from_json, set_attribute, and to_json lives in multiple classes simultaneously. That means bug fixes applied to one class silently leave the other broken, and adding a shared field requires touching every subclass by hand. Pulling shared behavior into a base class makes the hierarchy self-documenting: any attribute or method on the parent is guaranteed to exist on every child, so you can write against the contract instead of the implementation.
What You'll Learn
- Identify which attributes and methods belong on a base class versus a subclass
- Write a parent
from_jsonmethod that handles shared field extraction withpop, then let subclasses extend it - Use
set_attributeandto_jsonon a base class so all variants inherit serialization behavior automatically - Apply the DRY principle to class hierarchies without losing the flexibility each subclass needs
Refactoring Two Config Classes Into One Hierarchy
The video walks through a real-world example: OIDCConfig and SAMLConfig both represent flavors of SSO configuration. Before the refactor, each class independently defined enforce_allow_list and idp_certificate as attributes, and each had its own nearly-identical from_json implementation that used pop to extract those fields from an API response dictionary before constructing an instance.
The fix is to push those shared fields — and eventually is_enabled as well — up to the SSOConfig base class. More importantly, a parent from_json classmethod is added to SSOConfig that handles the common pop extractions. Subclass from_json methods call into the parent first, then handle only the fields unique to their variant. This means the shared extraction logic exists in exactly one place.
The same logic applies to set_attribute, update, and to_json: because every SSO config variant must support these operations identically, they belong on the parent. Subclasses inherit them for free without any additional code.
A key detail worth noting: pop is used intentionally here rather than direct key access. After the shared fields are extracted into named variables, the remaining dictionary is unpacked directly into the constructor — so pop serves double duty as both an extraction and a cleanup step. Understanding that pattern makes the from_json refactor much easier to follow and replicate.
The result is a hierarchy where adding a new SSO variant means defining only what is genuinely different, not reproducing the entire field contract again.
