Цитата:
Сообщение от Denis_ex
не очень охота создавать отдельный класс и его экземпляр внутри ObjectManager.
Обычно статикой делаются функции типа Math, т.е. набор функций (с передачей параметров) выполняющих свое локальное дело. ParserTools схож, т.к. функция/набор разбитых функций принимает один параметр извне и делает свою локальную задачу.
|
Тут 2 направления:
1. Это ты сейчас думаешь, что у тебя одна функция будет в классе, а потом появится настройка парсинга и код этой настройки не будет засорять "божественный" класс менеджера.
Или потребуется использвать несколько видов парсингов.
2. Ну сделай статическим классом, коли сейчас не видишь путей расширения. Потребуется что-то большее - отрефакторишь к обычному классу.
Пример:
1. Есть кнопка с текстом. Как расположить текст внутри этой кнопки?
а) делаем перечисление "ПоложениеТекста" и добавляем туда константы "LEFT", "LEFT_TOP", ...,"Чуть правее снизу",...
а внутрь кнопки вставляем веселый switch.
На реализации 3-го элемента в свитче наступает понимание, что ты убьеш на это день, а челу который будет использовать кнопку потребуется "ПоложениеТекста" "По правому краю если не вылазиет за пределы кнопки, по середине - если вылазиет"
Всё, приплыли!
Решение:
сделать один класс, реализующий ITextLayout, и написать там положение, которое нужно сейчас
А тот, кому потребовалось "По правому краю если ..." - пусть сам ITextLayout реализует - это быстрее, чем разбираться в коде кнопки.
2. Есть фукнция, проверяющая корректность email'a. Куда ее вопхнуть?
Каждый раз создавать класс, чтобы проверить корректность почты? Пока в нашей программе не требуется особая валидация емела с настройками - впихнем ее в статичный метод.