Подразумевает ли статика отсутствие состояния

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

подразумевает ли метод, помеченный как статический, что он не требует состояния

1) Нет. Вы не можете сказать, что статические методы подразумевают, что они не требуют состояния, потому что статические методы могут обращаться к статическим/одноэлементным ресурсам.

в большинстве случаев методы без сохранения состояния должны быть статичными

2) Да. Методы, не требующие состояния, а значит, не требующие экземпляра, обычно следует делать статическими.

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

По-настоящему апатридный метод действительно может быть сделан статическим, и, как правило, должен.

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

С другой стороны, статический — это термин, используемый для описания способа вызова метода. В C# это означает, что метод может быть вызван без экземпляра класса, но экземпляр класса — это не то же самое, что состояние. Есть еще статический экземпляр, который прекрасно поддерживает состояние: любая статическая переменная-член, поле или свойство могут поддерживать состояние. Статический метод или класс также вполне способен поддерживать состояние, используя файлы с отображением памяти, базу данных или что-то еще. Static - это соглашение о вызовах, не более того, и оно не связано с отсутствием гражданства или нет.

Я думаю, что его заявление имеет такой же смысл, как и «Демократии должны использовать желтые бумажные бюллетени».

Он смешивает концепции дизайна высокого уровня «сервисы без сохранения состояния» с деталями технической реализации низкого уровня «с использованием статических классов».

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

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

Он также серьезно неправильно понимает, что такое «статический» — статическая переменная — это способ хранения состояния между вызовами — и поэтому кажется, что он лучше подходит для службы с «отслеживанием состояния».

static – это ключевое слово языка, а state – концепция дизайна. Между этими двумя вещами существует очевидная связь, но это связь конкретного с метафизическим, а не связь причины и следствия. Статические методы могут ссылаться на некоторые виды информации о состоянии.

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

static может иметь состояние. вам просто нужно определить статические контейнеры для указанного состояния. и контейнеры совместно используются всеми вызовами ваших статических методов.

Краткий ответ на ваш вопрос: «нет», static не означает «нет состояния».

Что касается других ваших комментариев, static можно использовать, чтобы помочь вам реализовать службу без сохранения состояния, но одного static недостаточно. Еще один инструмент/метод, помогающий сделать что-то без состояния, — это использование неизменяемых структур данных. Это (в настоящее время) не является одной из сильных сторон C#, особенно по сравнению с F#.

Помимо перефразирования всех возможных определений «статических», ответ будет «да». Статические методы могут легко изменить состояние самого класса (представленного через статические переменные) и >даже изменять состояние экземпляров класса (в частности, когда им передается экземпляр или набор экземпляров). Однако в большинстве случаев вы будете использовать статические методы в тех случаях, когда состояние не изменяется. Наиболее важным примером является поиск или создание экземпляра (фабричные методы).

Тем не менее, правильный ответ — "нет". В реальной жизни (например, веб-службы через HTTP или взаимодействие с любым видом Orb) службы никогда не раскрывают свои методы службы, используя настоящие статические методы. Обычно вы вызываете статические методы, чтобы получить экземпляр службы (или экземпляр фабрики служб, из которой вы получаете экземпляр!), а затем работаете с этим. Это связано с тем, что прокси-сервер службы должен отслеживать свое внутреннее состояние. Таким образом, хотя ваши методы кажутся вам не имеющими состояния, на самом деле это не так.

Надеюсь, это не было слишком запутанным :)

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

Статический класс без каких-либо переменных уровня класса не имеет состояния. Он не содержит данных.

Каждый класс имеет структуру определения класса, в которой представлены и хранятся статические поля. Каждый «экземпляр» класса имеет доступ к статическим полям, хранящимся в определении класса (структура данных, называемая CORINFO_CLASS_STRUCT). Даже если НИКАКИХ экземпляров не было создано, код в любом месте вашей сборки может получить доступ к этим статическим полям уровня класса, используя синтаксис classname.StaticFieldName, вообще без какого-либо экземпляра.

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

Еще более важно то, что после загрузки определения класса CORINFO_CLASS_STRUCT, в отличие от истинного экземпляра класса, оно никогда не выгружается до тех пор, пока не будет выгружена сборка (или AppDomain). , так что, возможно, он более чувствителен, чем любое поле экземпляра, определенное в классе, потому что поле экземпляра исчезает, когда экземпляр подвергается сборке мусора.

Для получения дополнительной информации перейдите по CORINFO_CLASS_STRUCT ссылке на замечательную книгу Дона Боксеса, Essential .Net

Это в целом правильно. Однако у вас могут быть статические переменные, которые позволяют вашим статическим методам иметь состояние. Например, возьмем этот класс FooBarFactory:

class FooBarFactory
{
    private static _id = 0;
    public FooBar MakeAFooBar()
    {
        FooBar foo = new FooBar();
        foo.ID = _id;
        _id++;
    }
}
class FooBar
{
    public int ID {get;set;}
}

В этом случае ваш статический метод имеет минимальное состояние, но это (вероятно) необходимо.

Если вам нужен один экземпляр с состоянием, используйте шаблон singleton; это дает понять, что вы работаете с однократным объектом.

Исходя из этого, я бы рассматривал все статические классы и методы как не имеющие состояния. Это просто помогает сохранить рассудок.