Сделать это больше ООПей? - хорошая структура?

Question

Мне просто нужен совет, можно ли улучшить структуру вокруг определенного класса, который обрабатывает все функции доступа к диску

Структура моей программы такова, что у меня есть класс Disk, который получает данные из плоских файлов и баз данных на, как вы уже догадались, жестком диске. У меня есть такие функции, как

LoadTextFileToStringList, WriteStringToTextFile, DeleteLineInTextFile и т.д.

которые являются своего рода "универсальными методами"

В том же классе у меня также есть некоторые более конкретные методы, такие как GetXFromDisk, где X может быть определенным полем в таблице / запросе базы данных.

Должен ли я отделить общие методы от специализированных. Должен ли я сделать другой класс, который наследует общие методы. На данный момент мой класс статичен, так как нет необходимости иметь внутреннее состояние класса.

Я на самом деле не ООП, не так ли?

Спасибо Томас

Answer 1

Если вы используете только статические статические функции, вы на самом деле не работаете, как вы сказали.Это написание процедурного кода на языке OO.

Вы должны создать классы, которые представляют объекты в вашей проблемной области, такие как File и TextFile.Эти классы должны иметь такие операции, как DeleteLine, WriteLIne, Load и т. Д.

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

Answer 2

Хорошо, в вашем коде есть класс Utilities, в который вы объединяете все методы файла.
Это может указывать на некоторую проблему проектирования, но ИМХО это нормально, поскольку в проектах ООП обычно есть служебные классы. Преимущество заключается в возможности простого добавления дополнительных методов или изменения существующих, поскольку у вас не будет никаких производных классов, расширяющих класс Utility, которые будут затронуты.
Например, в Java везде есть статические методы. Например. Collection класс.
Я бы предложил, чтобы конструктор класса был private и имел такое именование, чтобы было очевидно, что это класс Utilities.