Когда использовать static метода?

Question

[deniska_kuzmenko]

Не могу до конца понять когда использовать static методы а когда обычные. Можете посоветовать когда нужно объявлять метод static а когда обычным? Сразу говорю что я знаю чем они отличаются и как работают, проблема в том что я не знаю когда надо что применять.

Comments

[matperez]

Скорее всего, вы все же не понимаете в чем разница. Приведите пример конкретного метода, который у вас вызывает затруднения, а вам уже напишут стоит ли его делать статическим и почему.

[deniska_kuzmenko]

matperez: ну смотрите у меня есть model_news - там находятся все методы касающиеся новостей, эти методы делаю обычными, также у меня есть model_common - там находятся общие методы, которые везде вызываются, считаю что эти методы должны быть статическими, я правильно рассуждаю? )

[matperez]

deniska_kuzmenko: ну вот вы пример класса приводите, а не метода. приведите пример конкретного метода.

Answer 1

[Дмитрий Ковальский]

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

Comments

[deniska_kuzmenko]

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

[Дмитрий Ковальский]

deniska_kuzmenko: Потому что это уже не ооп. Потому что объект хранит свое состояние,а значит можно вызывать метод не передавая входных параметров, а лишь оперировать состоянием объекта. Потому что писать вызов метода, передавая туда десяток параметров - адовый ад. Прошу коллег добавить если что-то упустил.

[CAMOKPYT]

Дмитрий Ковальский: а если передать массив одним параметром?)

[Макс]

CAMOKPYT: А если параметры разного типа

[Дмитрий Ковальский]

CAMOKPYT: передавайте, я вас благославляю. массив объектов базового типа.

Answer 2

[matperez]

К примеру есть такой класс "Человечество". У человечества есть характеристика "средний рост", она не применима к отдельному человеку. Метод рассчитывающий средний рост и саму переменную которая его хранит нужно сделать статической.

Экземпляром класса "Человечество", является отдельный человек. Отдельный человек можно иметь свой конкретный рост, вес, цвет волос и так далее, он может ходить, есть, разговаривать - вот эти методы и переменные должны быть динамическими.

Answer 3

[Данила Риджи]

Статические методы следует использовать в случае когда у сущности нет состояния, либо оно глобально.

Comments

[Дмитрий]

И чем это будет выигрышнее свободного метода в namespace-е ?

[Данила Риджи]

А я не сказал что это будет выигрышнее.

[Данила Риджи]

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

[deniska_kuzmenko]

Данила Риджи: а использование статических методов тратиться больше или меньше ресурсов или все равно?

[Данила Риджи]

deniska_kuzmenko: В сравнении с чем ?

[deniska_kuzmenko]

Данила Риджи: с динамическими методами)

[Данила Риджи]

deniska_kuzmenko: Простите, а что вы имеете в виду под динамическими методами ?

[deniska_kuzmenko]

Данила Риджи: наверно не правильно выразился, короче не статические методы)

[Данила Риджи]

deniska_kuzmenko: Понятно. Я не в курсе.

Answer 4

[Ilya Bobkov]

При частом использовании функции. Static, насколько я помню это постоянное хранение в памяти, вплоть до завершения программы.

Comments

[Ilya Bobkov]

habrahabr.ru/post/259627

Answer 5

[Stalker_RED]

Представим сайт с заказом пиццы. Объект-корзина, в нее добавлено несколько разных объектов-пицц с разной ценой и объект-кола. Нужно посчитать сумму заказа, мы вызываем метод корзина->получитьСумму(). Этот метод пробегается по всем товарам корзины и считает сумму.

Теперь представим что метод получитьСумму() мы ради эксперимента делаем статическим. Где ему брать данные для расчета?

Теперь представим объект "Конфиг" и его метод "конфиг::получитьЗначение('ключ')"
Такой конфиг можно сделать синглетоном или вообще сделать статическим.

Comments

[deniska_kuzmenko]

спасибо) хороший пример) просто у меня получается в основном так корзина->получитьСумму($data) или корзина->получитьСумму($param1, $param2) значит я не правильно программирую? (

[Stalker_RED]

deniska_kuzmenko: Значит у вас не ООП. Объектов нет, а класс используется только как хранилище/неймспейс/какая-то обертка для функций.

[deniska_kuzmenko]

Stalker_RED: вы правы, наверно так и есть( это сильно плохо? такой метод неправильный и лучше прикратить так писать код?

[Stalker_RED]

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

[deniska_kuzmenko]

Stalker_RED: ну вот смотрите например страница site.ru/news - я создаю сразу 3 класса c_news m_news v_news, и так для каждой страницы на сайте, + я создаю классы группируя методы определенной функциональности например m_upload, и при необходимости создаю объект этого класса и использую его методы, вроде это и есть ооп, хотя все так сделано что больше похоже на "хранилище/неймспейс/какая-то обертка для функций", теперь не знаю что делать(

[Stalker_RED]

deniska_kuzmenko: К примеру такая структура
class article {
// свойства (вероятно их будет больше)
private title;
private url;
private content;
private created;
// методы
public setTitle($title){}
public setUrl($title){}
public setContent($title){}
//
public save(){
// собираем свойства в кучку, формируем запрос для вставки в базу, отправляем
}
}

// создаем новую статью
$article = new Article();
$article->setTitle($title);
$article->setContent($text);
$article->setCreated(time()); // текущее время
$article->save();

Это был объект "статья" и ООП.

а это не ООП

class Article {
// метод для создания статьи
public static newArticle($title, $url, $content, $created) {
// здесь вся кухня
}
}

[deniska_kuzmenko]

Stalker_RED: спасибо большое) теперь стало все понятно) ну вот Вы бы мне что посоветовали, начать как можно быстрее перейти к 1 варианту? и есть ли названия у 2 варианта или это просто гавнокод?)

[Stalker_RED]

deniska_kuzmenko: Посоветовал бы почитать книжку про ООП. Или две.

[Stalker_RED]

deniska_kuzmenko: Тут какая штука - если проект quick and dirty, то можно обойтись и такой вот функцией в процедурном стиле, обернутой в класс для красоты.
Но по мере роста проекта, с увеличением сложности, оказывается, что такую архитектуру сложно поддерживать, сложно понимать где, что и по каким правилам происходит с данными.

[deniska_kuzmenko]

Stalker_RED: в моем случае получается действительно быстро разрабатывать, но и не так грязно как Вы представляете. Я все структурирую, в коде нет повторений. В принципи мой стиль меня полностью устраивает, и самое главное нет проблем с поддержкой кода, но просто я сам понимаю что кодю не по стандарту не так как в книгах написано не так как профессионалы это делают, и иногда есть большое желание научиться это делать правильно. Но я нахожусь в какой то ловушки, если переходить на правильное ооп, то надо переписать все проекты на правильное ооп, а это не так уж и легко та и времени особо нет.