SRP - принцип единой ответственности

Описание
Класс имеет свою ответственность и он не должен брать на себя другие ответственности
Пример
Создадим класс реестр для возможности сохранения действий на компьютере.

Описание класса реестр
:
- добавление записей в реестр
- удаление записей в реестре
- вывод записей всего реестра 

from dataclasses import dataclass
from typing import ClassVar

@dataclass
class Register:
    entries: ClassVar = []
    count: ClassVar = 0

    def __str__(self) -> str:
        '''Вывод всех записей'''
        return '\n'.join(self.entries) 
    
    def add_entry(self, entry: str) -> None:
        '''Добавление записей'''
        self.count += 1
        self.entries.append(f'{self.count} - {entry}')
    
    def remove_entry(self, pos: int) -> None:
        '''Удаление записей'''
        del self.entries[pos]
Объявление объекта класса Register 

reg = Register()
reg.add_entry('Добавление файла hello')
reg.add_entry('Изменение файла hello')
print(reg)
Пример избыточной ответственности
Изменение класса и добавление в него избыточной ответственности. Например, сохранение реестра в файл и загрузка реестра из файла.

Это избыточная ответственность и при расширении способов сохранения и загрузки реестра необходимо будет каждый раз изменять класс и расширять его ответственность. Также добавляются смежные методы проверок прав доступа для записи и загрузки.
пример метода сохранения

def save(self, filename: str) -> None:
        file = open(filename,'w')
        file.write((str(self)))
        file.close()
разрешение проблемы
Для разграничения ответственности необходимо создать отдельные классы, которые будут решать задачи своей ответственности. Например создадим класс сохранения
пример изменения ответственности

class SaveManager:
    @staticmethod
    def save_to_file(register, filename) -> None:
       file = open(filename,'w')
       file.write((str(register)))
       file.close()
Антипаттерн "Всемогущий объект"
Антепаттерн "Всемогущий объект" гласит о невозможности добавления всей функциональности в один класс.
Необходимо следить за изменениями ответсвтенности класса. Таких изменений не должно быть много.
Вывод
При добавлении ответственности необходимо описывать ее через добавления новых классов ответственности, а не расширять старый класс. При расширении класса, он теряет свою гибкость и начинает нести избыточную функциональность, также необходимо будет следить за совместимостью нового и старого кода.