Почему статические методы не считаются хорошей практикой OO?

Ответ 1

Одна из причин того, что статические методы не очень OO, о которых до сих пор не упоминалось, заключается в том, что интерфейсы и абстрактные классы определяют нестатические методы. Таким образом, статические методы не очень хорошо вписываются в наследование.

Обратите также внимание на то, что статические методы не имеют доступа к "super", что означает, что статические методы не могут быть переопределены в каком-либо реальном смысле. На самом деле они не могут быть переопределены вообще, только скрыты. Попробуйте следующее:

public class Test {
    public static int returnValue() {
        return 0;
    }

    public static void main(String[] arg) {
        System.out.println(Test.returnValue());
        System.out.println(Test2.returnValue());
        Test x = new Test2();
        System.out.println(x.returnValue());
    }
}


public class Test2 extends Test {
    public static int returnValue() {
        return 1;
    }
}

Когда вы запустите это, вы не получите то, что ожидаете. Test.returnValue() дает то, что вы ожидаете. Test2.returnValue() скрывает метод с тем же именем в суперклассе (он не переопределяет его), и он дает то, что вы ожидаете.

Можно наивно ожидать, что "нестатически" вызывает статический метод для использования полиморфизма. Это не так. Независимо от того, какой класс объявляется как переменная, используется тот, который использовался для поиска метода. Это плохая форма, потому что кто-то может ожидать, что код сделает что-то отличное от того, что он на самом деле делает.

Это не означает: "Не используйте статические методы!" Это означает, что вы должны зарезервировать использование статических методов для тех экземпляров, где вы действительно хотите, чтобы объект класса владел этим методом, а не просто как ленивый способ сделать одноэлемент.

Ответ 2

Объектная ориентация - это три вещи:

• сообщениями
• локальное сохранение и защита и скрытие процесса состояния, а
• крайняя поздняя привязка всех вещей.

Из этих трех наиболее важным является обмен сообщениями.

Статические методы нарушают, по меньшей мере, обмен сообщениями и позднюю привязку.

Идея обмена сообщениями означает, что в OO вычисление выполняется сетями автономных объектов, которые отправляют сообщения друг другу. Отправка сообщения является единственным способом связи/вычисления.

Статические методы этого не делают. Они не связаны ни с каким объектом. По сути, они действительно не методы, в соответствии с обычным определением. Они действительно просто процедуры. Там практически нет разницы между статическим методом Java Foo.bar и подпрограммой BASIC FOO_BAR.

Что касается позднего связывания: более современное имя для этого - динамическая отправка. Статические методы также нарушают это, на самом деле, даже сами по себе: статические методы.

Статические методы ломают некоторые очень приятные свойства объектной ориентации. Например, объектно-ориентированные системы автоматически могут быть безопасными с объектами, действующими как возможности. Статические методы (или действительно любая статика, будь то статическое состояние или статические методы) разрушают это свойство.

Вы также можете выполнять каждый объект параллельно в своем собственном процессе, поскольку они обмениваются сообщениями только через обмен сообщениями, тем самым предоставляя несколько тривиальных concurrency. (Как и актеры, в принципе, это не должно быть слишком неожиданным, поскольку Карл Хьюитт создал модель актера на основе Smalltalk-71, а Алан Кей создал Smalltalk-71 частично на основе PLANNER, который, в свою очередь, был создан Карлом Хьюиттом. отношения между субъектами и объектами далеки от случайных, по сути, они по существу одно и то же.) Опять же, статика (как статические методы, так и особенно статическое состояние) ломает это приятное свойство.

Ответ 3

Не путайте "не-так-чистые концепции ОО" с "плохой практикой". Быть "чистым ОО" - это не какая-то панацея, которую вы должны пытаться достичь. Просто потому, что статические методы не принимают переменную экземпляра в качестве параметра, это не значит, что они не являются полезными. Некоторые вещи просто не поддаются объектам, и их нельзя вводить в эту форму только ради "чистоты".

Некоторые люди думают, что вещи должны быть "чистыми", и, следовательно, что-либо "нечистое" - это плохая практика. На самом деле, плохая практика просто делает вещи, которые запутывают, трудно поддерживать, трудны в использовании и т.д. Создание статических методов, которые принимают экземпляр, является плохой практикой, потому что любой метод, который принимает экземпляр, вероятно, должен быть методом экземпляра. С другой стороны, такие функции, как утилита и factory, обычно не принимают экземпляр, поэтому они должны быть статическими.

Если вам интересно, почему они не являются "чистым ОО", это потому, что они не являются методами экземпляра. "Чистый" язык OO имел бы все, что является объектом, а все функции - экземплярами. Конечно, это не очень полезно все время. Например, рассмотрим метод Math.atan2. Он принимает два номера и не требует никакого состояния. На каком объекте вы могли бы сделать это методом? В "чистом" языке OO Math сам может быть объектом (возможно, одним синглом), а atan2 будет методом экземпляра, но поскольку функция фактически не использует какое-либо состояние в объекте Math, это также не концепция "чистого ОО".

Ответ 4

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

Кроме того, статические методы трудно проверить из-за этих тесно связанных зависимостей, которые часто приводят к сторонней инфраструктуре, от которой зависит код - как база данных, и это очень затрудняет изменение поведения без фактического перехода и изменение кода.

Ответ 5

Статические методы не считаются хорошей практикой OO из-за следующих причин:

1) Предотвращает повторное использование:

Статические методы нельзя переоценить. Его нельзя использовать в интерфейсе.

2) Срок службы объекта очень длинный:

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

3) Кроме того, некоторые другие моменты:

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

Ответ 6

Статические методы не являются настолько чистыми концепциями ОО, потому что они могут быть вызваны без связанного с ними объекта. Вы используете сам класс. Вы вызываете их так: Classname.method(...);

Ответ 7

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

- Приветствия