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

Да - сделав его статическим, ты даёшь гарантии (enforced by compiler) что и в будущем "случайно" туда не просочится this. Таким образом ты усиливаешь инкапсуляцию, ограничивая доступ к данным объекта из метода, который и не должен бы этоми данными объекта пользоваться. (Предполагается, что неиспользоыание this является частью логики вычислений, и не появилось "случайно")

А если этот метод - часть интерфейса, который исплементирует класс?

тоже делать статическим?

ну вроде какой-нить public toName(): string

имя задано раз и на всегда

весь метод это одна строка return "foofoo";

не видел кейсов кроме именованого конструктора для статики других

Хммммм... то есть это foofoo - оно одинаковое для всех экземпляров?

писать просто статик, если в методе нет this - оч дурная затея кмк

Хммммм... то есть это foofoo - оно одинаковое для всех экземпляров?

да

весь метод это одна строка return "foofoo";

Думается мне, если это "одинаковое поведение для всего класса", и это умышленное поведение - есть как раз смысл объявить это, сделав метод "методом класса" (== static)

interface CallableByName { toName(): string; }

много реализаций

вроде class Foo implements CallableByName

toName() { return 'foo'; }

статикой делать?

toName - очевидно часть public contract

может ли статический метод быть часть контракта?

писать просто статик, если в методе нет this - оч дурная затея кмк

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

по-моему что-то тут не так

может ли статический метод быть часть контракта?

Давай посмотрим на это с другой перспективы: вот есть код, который по своей логике никак не связан с каким-либо экземпляром класса. Из каких соображений мы могли бы его объявить НЕ static, и зачем мы стали бы всегда передавать в него бесполезный и нерелевантный аргумент (this)?

Давай посмотрим на это с другой перспективы: вот есть код, который по своей логике никак не связан с каким-либо экземпляром класса. Из каких соображений мы могли бы его объявить НЕ static, и зачем мы стали бы всегда передавать в него бесполезный и нерелевантный аргумент (this)?

мне кажется это задача компилятора, если он знает, что аргумент не используется, пусть не передает

почему у меня должна об этом голова болеть?

мне кажется это задача компилятора, если он знает, что аргумент не используется, пусть не передает

Это не может так работать (в большинстве языков) - лишний параметр меняет сигнатуру метода.

в большинстве языков this передается неявно, сигнатура снаружи не меняется

честно сказать, я, кроме питона таких и не знаю

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

Это разве не шторм так делает? Это вредный совет да

Это разве не шторм так делает? Это вредный совет да

может и он, я не разбирался

Давай посмотрим на это с другой перспективы: вот есть код, который по своей логике никак не связан с каким-либо экземпляром класса. Из каких соображений мы могли бы его объявить НЕ static, и зачем мы стали бы всегда передавать в него бесполезный и нерелевантный аргумент (this)?

А зачем вообще складывать это в класс, если никак не хотим отнести этот метод к объекту?

А зачем вообще складывать это в класс, если никак не хотим отнести этот метод к объекту?

я привел пример. интерфейс "HasName"

Если он по логике модели у объекта, а по реализации не использует this, то ну и ладно. А если никак не относится, то делая его статическим делаете только хуже

в большинстве языков this передается неявно, сигнатура снаружи не меняется

Не совсем. Точнее да, всё верно - this кладётся на стек молча, незаметно для разработчика. Но это всё равно означает, что такой параметр передан. Положим, сегодня мой метод foo(int x) не использует this - у метода фактически один аргумент. Завтра я решил внутри foo(int x) использовать this - теперь у foo два фактических аргумента. Сигнатура изменилась, хотя он как в коде был foo(int x) так и остался - но foo "вчера" уже незримо несовместим с foo "сегодня". Имхо это причина, почему компилятор не может сам решать куда расставлять static.

Не совсем. Точнее да, всё верно - this кладётся на стек молча, незаметно для разработчика. Но это всё равно означает, что такой параметр передан. Положим, сегодня мой метод foo(int x) не использует this - у метода фактически один аргумент. Завтра я решил внутри foo(int x) использовать this - теперь у foo два фактических аргумента. Сигнатура изменилась, хотя он как в коде был foo(int x) так и остался - но foo "вчера" уже незримо несовместим с foo "сегодня". Имхо это причина, почему компилятор не может сам решать куда расставлять static.

это все кухня компилятора, я не хочу про нее знать, я хочу тык-тык по кнопкам

ни про стеки ни про какие другие оптимизации не хочу знать

у нас же язык высокого уровня

Не совсем. Точнее да, всё верно - this кладётся на стек молча, незаметно для разработчика. Но это всё равно означает, что такой параметр передан. Положим, сегодня мой метод foo(int x) не использует this - у метода фактически один аргумент. Завтра я решил внутри foo(int x) использовать this - теперь у foo два фактических аргумента. Сигнатура изменилась, хотя он как в коде был foo(int x) так и остался - но foo "вчера" уже незримо несовместим с foo "сегодня". Имхо это причина, почему компилятор не может сам решать куда расставлять static.

Так компилятор легко может отличить когда использунтся(сегодня), от когда не используется(вчера)

ну Серега наверно имеет в виду какую-нить совместимость на уровне байт-кода

но мне на нее пофигу должно быть, как разработчику

тот же питон - хороший пример. язык как контракт, а не как реализация

не понял про питон

с наследование опять же возникают сложности. если в предке у меня статический метод, я в наследнике могу его сделать НЕстатическим?

с наследование опять же возникают сложности. если в предке у меня статический метод, я в наследнике могу его сделать НЕстатическим?

ты можешь добавлять в объект-наследник новые методы)

расширять вход и сужать выход

не понял про питон

ну есть питон как стандарт языка, а есть конкретные имплементации. python vs cpython

а когда речь про джаву, то чаще всего имеют в виду jvm

то есть внутренняя кухня имеет значение

ну есть питон как стандарт языка, а есть конкретные имплементации. python vs cpython

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

это нормально для промышленных инструментов

ты можешь добавлять в объект-наследник новые методы)

ну вот предок не умел менять имя, а потомок должен уметь. что делать?

а у предка уже статический метод нарисовался

не использовать наследование ?

тебе даровали структурные типы

зачем тебе иерархии

ну блин

наследование - один из столпов ооп, опять же в "обычном" понимании

плохо оно или нет, это отдельный вопрос

наследуй интерфейсы и наследуйся от них

не наследуй реализации

но статика мешает наследованию, получается

с наследование опять же возникают сложности. если в предке у меня статический метод, я в наследнике могу его сделать НЕстатическим?

Имхо нет, как раз по причине несовместимости сигнатур.

Имхо нет, как раз по причине несовместимости сигнатур.

а как быть?

оять же ты смотришь с точки зрения компилятора

а я - с точки зрения пользователя

оять же ты смотришь с точки зрения компилятора

Мммм согласен примерно на 78%. Но всё же (имхо) декларация static - это часть логики, а не реализации, и (опять же в моем понимании) означает декларацию/обещание "этот код по своей логике не требует и никогда не будет требовать знать state экземпляра". Примерно как int foo(string) значит "foo всегда будет ждать строку на входе и всегда возвращать число на выходе". В этой декларации нет ни порока, ни добродетели - есть лишь свойства.

И если язык поддерживает такую семантику, и мы ей воспользовались - мы же должны ей и соответствовать.

чтобы юзать статик должны быть более веские причины, чем техническое неиспользование this.

семантика какая-то должна присутствовать

This - это открытие доступа методу к state объекта. Далёкая аналогия - это как сделать метод public. Иными словами, _отсутствие_ static (как и отсутствие private) должно быть как-то обосновано. Примерно как говорят "нормальное состояние шлагбаума - закрытое".

О, сейчас.

http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

Строго говоря, здесь Meyers пишет про non-member functions (because in C++ you can ?) но в большинстве случаев они ведут себя так же, как и static.

нууууууу

class Point { public: int getXValue() const; int getYValue() const; void setXValue(int newXValue); void setYValue(int newYValue); private: ... // whatever... };

для начала я бы не называл вот это инкапсуляцией

Still, it seems clear that the class is more encapsulated than the struct, and we'd like to have a way to state this more formally. - не согласен вообще

для начала я бы не называл вот это инкапсуляцией

Выглядит отстойно, но предполагаю автор выбрал нечто для "тривиального примера".

ладно бы было что-то вроде point.moveTo() или point.printOnCanvas(canvas)

Да, согласен. Но как мне кажется все остальные выводы оно не особо изменит.

ну я к тому, что обсуждать тезис "статика помогает инкапсуляции" становится бессмысленно, если мы под инкапсуляцией понимаем разные вещи

но я не дочитал еще, погоди

Мммм а что мы понимаем под инкапсуляцией?

Мммм а что мы понимаем под инкапсуляцией?

я понимаю сокрытие стейта и деталей реализации. геттеры и сеттеры этого не делают

ну то есть вместо того, чтобы иметь cat.eat(food) мы делаем cat.getStomach().contents = food

это не инкапсуляуция

cat.walkto(point) это инкапсуляция. cat.position.x = 42 это не инкапсуляция

use of non-friend non-member functions improves a class's encapsulation, and a preference for such functions over member functions makes it easier to design and develop classes with interfaces that are complete and minimal (or close to minimal).

ну это и ежу понятно

не надо создавать члены класса, если они не нужны

я понимаю сокрытие стейта и деталей реализации. геттеры и сеттеры этого не делают

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

все же мне кажется, он там не совсем за статику топит

все же мне кажется, он там не совсем за статику топит

Он на плюсах специализировался.

use of non-friend non-member functions improves a class's encapsulation, and a preference for such functions over member functions makes it easier to design and develop classes with interfaces that are complete and minimal (or close to minimal).

Имхо он как раз именно тут и говорит "не передавайте в функции this если у вас нет на то серьёзных причин".

То есть - делайте static или non-member (если ваш язык позволяет).

То есть - делайте static или non-member (если ваш язык позволяет).

ну а как быть с наследованием-то?

это достаточно серьезная причина?

в сях я могу вызвать статический метод у экземпляра класса?

Нет конечно. Потому как в статическом методе у тебя нет "слота" для передачи this.

а

Методы класса вызываются у класса.