с точки зрения ООП, как плохо иметь объекты с фиксированными состояниями?

Question

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

В основном я пишу программу, которая много читает и пишет в текстовых файлах.Я думал, что ни один из объектов, которые у меня есть, не должен иметь дело с этими операциями, и у меня должен быть класс fileIO, который выполняет эти операции для них.Тем не менее, я немного волнуюсь, что это может быть то же самое, что иметь служебный класс.

Имеет ли класс, чьи поля никогда не меняются (или даже не нужно инициализироваться), то же самое, что и служебный класс?Это плохая практика с точки зрения ООП?Имеет ли смысл иметь объект fileIO?Если нет, следует ли разрешать объектам читать и записывать в файлы?

class fileIO:
    __processFilePath = None
    __trackFilePath = None

    def __init__(self, iProcessFilePath, iTrackFilePath):

    def getProcesses(self):

    #checks if appString is in file
    def isAppRunning(self,appString):

    #reads all
    def getAllTrackedLines(self):

    #appends
    def addNewOnTracked(self,toBeAdded):

    #overwrites
    def overWriteTrackedLines(self,fullData):

в данном конкретном случае я фактически инициализирую поля в методе init.Но для целей моей программы мне это не нужно, потому что есть только два файла, которые я читаю и записываю.

Answer 1

Чтение и запись данных из файла могут быть помещены в некоторый класс, который обрабатывает состояние данных, чтобы гарантировать завершение транзакции.Под этим я подразумеваю, что ресурс должен быть правильно распределен, предпочтительно в одной транзакции, независимо от результата операции.Если вы рассматриваете распределение и перераспределение ресурсов как состояние, то ваш класс не является точно не имеющим состояния.В функциональном программировании ресурсы обработки функций будут считаться нечистыми, поскольку они не являются лицами без состояния.Состояние просто внешнее.

Наличие класса без состояния не является плохим классом.Это правда, что классы Utility являются антишаблоном, но если ваш класс делает одну маленькую вещь и делает это хорошо, то это не проблема.Проблема возникает, когда у вас есть куча связанных методов, и код начинает гнить.Это то, что вы хотите избежать.Класс, который имеет четко определенную цель и выполняет только эту функцию, будет сопротивляться гниению.

Удостоверьтесь, что вы также пишете множество тестов для своего класса, так как это является ключевым фактором для долгосрочной ремонтопригодности.

Пожалуйста, дайте мне знать, если есть что-то, что я могу уточнить.