Я обнаружил, что существуют два типа методов, называемых статическими методами и методами экземпляра и их отличиями. Но все же я не мог понять преимущества одного над другим.Что лучше? Статические методы или методы экземпляра
Иногда я чувствую, что статические методы не ориентированы на объекты на 100%.
Существуют ли различия в производительности между этими двумя.
Может кто-нибудь помочь?
Методы экземпляра требуют передачи неявного параметра (ссылка this), которые делают их несколько медленнее, чем static методов. Но это действительно не должно быть причиной их предпочтения.
Для родственном обсуждения, смотрите на:
Я частично угадывания на основе наследия C#, но я подозреваю, что это то же самое, как и другие языки OO.
Статические методы не требуют, чтобы объект работал. Хорошим примером является:
Double pi = Math.PI.
Методы экземпляров требуют наличия объекта. Примером может служить вдоль линий:
Integer x = 9;
Integer y = x.sqrt();
Не вся информация, принадлежащая к классу должна нужен объект инстанцированный для этого класса, чтобы получить к нему доступ. Все эти константы, которые могут быть использованы для создания объектов (Math.PI, Window.OVERLAPPED и т. Д.), Являются яркими примерами этого.
Если ваш метод использует нестатические элементы данных, не делайте его статическим (вы «не можете»).
Если ваш метод не использует нестатические элементы данных, вы можете сделать его статическим, но в основном это зависит от вашего дизайна, а не от того, использует он или нет, нестатические члены (разница в производительности невелика так или иначе, как сказал Мехрдад).
Если у вас НЕТ нестатических членов данных в вашем классе, иногда рекомендуется сделать все методы статическими (например, в случае группировки вспомогательных функций под одним классом ради хорошего порядка).
В идеальном мире OO, вероятно, не будет необходимости в статических методах (я думаю, что у Eiffel их тоже нет). Но в конце дня важна не OO-чистота вашего кода (у C# есть достаточно понятий, которые не являются строго чистыми OO, например, методами расширения), а скорее то, что вы делаете.
Вы можете использовать статические методы для общих вспомогательных методов (которые не нужны вообще вспомогательному классу или состоянию сами по себе) или такие вещи, как Color.FromARGB(), которые ведут себя немного contructor-like для типов значений.
В общем, любой метод, который не касается состояния объектов (и, следовательно, более специфичен для конкретного объекта, чем объект), может быть сделан статическим. Различия в производительности не должны возникать. В любом случае это не очень измеримо. В замечательной статье Яна Грея Writing faster managed code: Know what things cost есть некоторые жесткие данные по этому вопросу, хотя и с осторожностью.
Даже в «чистом мире ОО» я не вижу, как сделать метод экземпляра Math.Cos «более OO». Для таких методов полезности, как, например, нет концептуальных различий между наличием статического метода с параметрами N или наличием метода экземпляра с параметром N-1, где «это» понимается как первый параметр («Math.Cos (double)» VS "double.Cos()"). – Trillian
Полезность статического метода в первую очередь возникает, когда вам нужно вызвать метод без создания экземпляра объекта. Например, возможно, статический метод действительно ищет существующий экземпляр и возвращает его (пример является экземпляром singleton).
Как уже было сказано, вы можете сделать любой метод статическим, если он не имеет доступа к состоянию, и вы получите небольшое улучшение производительности.
Если вы действительно хотите, чтобы иметь возможность вызвать метод в конкретном экземпляре, и получить преимущества полиморфизма (т. Е. Производный класс может переопределить поведение метода), то вы должны сделать его методом экземпляра ,
Если ваши классы реализуют интерфейсы, то методы, принадлежащие этим интерфейсам, также должны быть объявлены как методы экземпляра.
Методы экземпляра являются жесткими к экземпляру. Таким образом, вы можете видеть, что одно преимущество статических методов не связано с экземпляром. Статические методы могут (если они видны) использоваться другими объектами для решения их проблем. Иногда это хорошо и нужно. Затем вам нужно подумать о том, как хранить свои статические методы в одном классе или начинать строить классы утилиты для более широкого использования. Я бы не стал использовать статические методы «меньше OO». Статические методы - один из способов обойти недостатки OO (особенно в языках с одним наследованием). Вы можете назвать это более функциональным подходом (я знаю, что это не так).
Принимая во внимание все эти вопросы, вы должны задать свой код, и это должно определить, лучше ли это метод экземпляра, статический метод того же класса или статический метод другого класса.
Я бы даже не подумал о проблемах с производительностью. Это ослабит ваш дизайн, и разница не такая уж большая. Производительность важна, если у вас есть проблемы с производительностью.
Никто не лучше другого. Это действительно зависит от вашего требования. Методы класса вызывается, когда вы хотите применить изменение к классу в целом. В то время как методы экземпляра вызываются, когда вы не применяете изменения к классу, а к уникальному экземпляру (объекту) этого класса.
Так что я не вижу причины, по которой человек должен быть лучше, чем другой.
Пожалуйста, аргумент скорости следует учитывать только в том случае, если вы пытаетесь сделать что-то на очень медленной платформе или сотнях тысяч раз за одну секунду. Я предполагаю, что вы работаете с двухъядерным процессором> 2 ГГц. Разница в скорости между вызовом функции-члена и вызовом статической функции не должна быть конструктивным критерием. –
Да, даже на гораздо более медленных платформах, это не должно быть вопросом дизайна (как я сказал в ответе). Я просто отметил разницу в производительности, потому что это специально спрошено. –