Что оборотные стороны к статическим методам?
Обратите внимание, что, как правило, вы можете cout << static_cast<const void*>(my_pointer) напечатать его адрес. Если вы попытаетесь напечатать адрес char*, вы обнаружите, что << перегружен.
Другой вариант - printf( "%p\n", my_pointer ); из <stdio.h>.
5 ответов
Различия в производительности будут незначительны.
Оборотная сторона использования статического метода - то, что это становится менее тестируемым. Когда зависимости выражаются в вызовах статического метода, Вы не можете заменить те зависимости насмешками/тупиками. Если все зависимости выражаются как интерфейсы, куда реализация передается в компонент, то можно использовать ложную/тупиковую версию компонента для модульных тестов и затем реальную реализацию (возможно поднятый трубку с контейнером МОК) для реального развертывания.
Jon Skeet прав - различие в производительности было бы незначительно...
Однако если бы Вы создаете корпоративное приложение, я предложил бы использовать традиционный многоуровневый подход, поддержанный Microsoft и многими другими компаниями-разработчиками программного обеспечения. Позвольте мне кратко объяснить:
Я собираюсь использовать ASP.NET, потому что я являюсь самым знакомым с ним, но это должно легко перевести в любую другую технологию, которую можно использовать.
Уровень представления Вашего приложения состоял бы из ASP.NET aspx страницы для дисплея и код-behinds ASP.NET для "управления процессом". Это - необычный способ говорить о том, что происходит, когда я нажимаю, отправляют. Я перехожу к другой странице? Есть ли проверка? Я должен сохранить информацию к базе данных? Где я следую за этим?
Управление процессом является связью между уровнем представления и бизнес-слоем. Этот слой разбит в две части (и это - то, где Ваш вопрос входит). Самый гибкий способ создать этот слой состоит в том, чтобы иметь ряд занятий по бизнес-логике (например, PaymentProcessing, CustomerManagement, и т.д.), которые имеют методы как ProcessPayment, DeleteCustomer, CreateAccount, и т.д. Они были бы статическими методами.
Когда вышеупомянутые методы называют от слоя управления процессом, они обработали бы все инстанцирование бизнес-объектов (например, Клиент, Счет, Оплата, и т.д.) и применили бы соответствующие бизнес-правила.
Ваши бизнес-объекты - то, что обработало бы все взаимодействие базы данных с Вашим слоем данных. Таким образом, они знают, как сохранить данные, которые они содержат..., это подобно шаблону MVC.
Таким образом - каково преимущество этого? Ну, Вы все еще получаете тестируемость на нескольких уровнях. Можно протестировать UI, можно протестировать бизнес-процесс (путем вызова занятий по бизнес-логике с соответствующими данными), и можно протестировать бизнес-объекты (путем ручного инстанцирования их и тестирования их методов. Вы также знаете, что, если Ваша модель данных или изменение объектов, на Ваш UI не повлияют, и только Ваши занятия по бизнес-логике должны будут измениться. Кроме того, если бизнес-логика изменяется, можно изменить те классы, не влияя на объекты.
Надежда это помогает немного.
Производительность мудрые, использующие статические методы избегает издержек создания объекта / разрушение. Это обычно не значительно.
Они должны использоваться только там, где действие взятия метода не связано с состоянием, например, для методов фабрики. Не имело бы никакого смысла создавать экземпляр объекта только для инстанцирования другого экземпляра объекта :-)
Строка. Формат (), TryParse () и Синтаксический анализ () методы являются всеми хорошими примерами того, когда статический метод имеет смысл. Они всегда выполняют то же самое, не должны указывать и довольно распространены настолько инстанцирующие, имеет меньше смысла.
С другой стороны, использование их, когда это не имеет смысла (например, имея необходимость передать все состояние в метод, скажем, с 10 аргументами), делает все более сложным, менее удобным в сопровождении, менее читаемым и менее тестируемым, как говорит Jon. Я думаю, что не необходимо, если это о бизнес-слое или где-нибудь еще в коде, только используйте их экономно и когда ситуация выравнивает по ширине их.
Если метод будет использовать статические данные, то это будет на самом деле совместно использовано среди всех пользователей Вашего веб-приложения.
Только для кода, никакие настоящие проблемы вне обычных проблем со статическими методами во всех системах.
- Тестируемость: статические зависимости являются менее тестируемыми
- Поточная обработка: у Вас могут быть проблемы параллелизма
- Дизайн: статические переменные похожи на глобальные переменные