Ответ 1
В конечном счете, это решение по моделированию домена, и здесь нет однозначного правильного ответа. Важно то, как каждый выбор влияет на читаемость и удобство сопровождения кода.
Я склонен отдавать предпочтение статическим членам для функциональности, которая очень "связана" с типом, в большей степени, чем какой-либо конкретный фрагмент кода бизнес-логики. Подумайте о функциях Parse или умных конструкторах/фабричных методах. Общий подход заключается в том, что если бы я реорганизовал код, переместив тип в другое место, это были бы функции, которые я определенно хотел бы переместить вместе с ним. Наличие их в качестве статических членов также помогает обнаружению через intellisense, поскольку вам нужно только знать имя типа, чтобы найти их.
С другой стороны, я бы использовал модуль для размещения бизнес-логики, которая представляет некоторый абстрактный процесс, и если рассматриваемая функция каким-то образом специфична для этой бизнес-логики и вряд ли будет полезна вне ее, то я бы пошел с функция в модуле, даже если он все еще в некоторой степени зависит от типа. Например, синтаксический анализатор с очень специфической целью, который будет полезен только как часть этого одного рабочего процесса по устаревшим причинам, будет функцией с привязкой, а не статическим членом, потому что другие клиенты, использующие этот тип, вообще не должны даже знать об этой функции,
В вашем случае я бы выбрал статический член Next если имеет смысл использовать его в нескольких различных модулях в вашем контексте - если возможность циклически проходить через Seasons - это фундаментальное качество, определяющее, что такое Season.
В противном случае, если у вас есть только один модуль, скажем, WeatherPatterns, который регулирует количество осадков в зависимости от смены сезона и является единственной частью вашего кода, где вы заботитесь о циклическом переключении между Seasons, то я бы поместил его в качестве функции в этом модуле.