Альтернатива статическому классу для объектов без состояния

Question

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

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

В качестве примера я недавно создал класс FileRepository, который реализует шаблон хранилища для нашего собственного класса File (например, файлы импорта). Этот класс не является статичным, и объект хранилища должен быть сначала создан, прежде чем к нему можно будет получить доступ.

Моя проблема с этим, все мои старые статические вызовы, теперь состоят из 2 строк (если я не могу повторно использовать объект в локальной области видимости). У объекта репозитория (пока что) нет состояния, поскольку он использует доступ к базе данных через статическую переменную потока.

Мой вопрос: каково мнение людей о наличии у класса статического свойства потока в классе, где метод доступа get инициализирует объект при первом вызове? Насколько я понимаю, это по-прежнему позволит избежать ловушек статических классов, таких как невозможность реализации универсальной функциональности через интерфейсы, но все же обеспечит простоту однострочных обращений к объекту хранилища?

Просто пытаюсь скорректировать мои практики и образ мыслей к лучшему.

Answer 1

Статика, как правило, ухудшает тестируемость.

В частности, вам будет довольно сложно протестировать все, что использует репозиторий. Вместо создания нового репозитория для каждого вызова, он должен быть частью состояния всего, что требует этого. Используйте внедрение зависимостей для предоставления репозитория, который реализует соответствующий интерфейс. Затем вы можете протестировать все, что использует репозиторий, смоделировав его.

Конечно, это идеалистическое решение, которое, возможно, не является прагматическим решением для вашего случая, но в целом это объектно-ориентированное решение.

Вы могли бы иметь «текущий» репозиторий и все еще быть достаточно тестируемым, но для этого все еще требуется статическое состояние, которое обычно вызывает недовольство. Это небольшой запах кода, но он, по крайней мере, лучше, чем статические методы.

Answer 2

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

Answer 3

Вам нужно объяснить, о каком снижении производительности вы говорите. Мы говорим о микросекундах?

Довольно часто производительность приложения можно улучшить, запустив профилировщик и найдя код, вызывающий сбой. Взгляните на профилировщик ANTS в качестве примера.

Все чаще и чаще я нахожу доступ к базе данных в 70% случаев.