Самый очевидный и простой вариант, с которого следует начать - это упаковать в класс SpiralMatrix чтобы приватные методы не торчали наружу:
public class SpiralMatrix
{
public static int[,] Create(int size)
{
var result = new int[size, size];
for (var i = 0; i < size; ++i)
{
for (var j = 0; j < size; ++j)
{
if (i > j)
{
WriteNumber(size, result, i, j);
}
else
{
WriteNumberTwo(size, result, i, j);
}
}
}
return result;
}
private static void WriteNumberTwo(int size, int[,] myArray, int i, int j)
{
if (i + j < size)
{
myArray[i, j] = i * (size - i) * 4 - (i - (size - i)) + i + j - size + 1;
}
else
{
myArray[i, j] = (size - (size - j - 1)) * (size - j - 1) * 4 + (j - (size - j)) + i + (j - size) + 3;
}
}
private static void WriteNumber(int size, int[,] myArray, int i, int j)
{
if (i + j < size)
{
myArray[i, j] = (size - (j + 1)) * (j + 1) * 4 - (i - (j + 1));
}
else
{
myArray[i, j] = i * (size - i) * 4 - (i - (size - i)) - (j - size + i + 1);
}
}
}
Ну и как бы всё, уже считай пишете в ООП-стиле:
var size = 3;
var spiralMatrix = new SpiralMatrix().Create(size);
(В реальном проекте код этого класса будет в отдельном файле и вы можете выкинуть из головы подробности, как именно идёт заполнение и просто писать имя класса метод, не вникая в детали реализации.
Вы так ежедневно используете классы типа "строка" или "массив", у которых дергаете разные методы, хотя в любой момент времени можете открыть исходники и посмотреть, эти классы написаны на том же самом C#, на котором вы пишете.)
Но в этой задаче особо классы и объекты не нужны, что видно хотя бы по тому, что у вас все методы статические, поэтому вы можете тоже в классе сделать все методы статическими и вызывать без инстацирования класса:
var size = 3;
var spiralMatrix = SpiralMatrix.Create(size);
Так что с одной стороны в этой задаче классы уже есть, но особых преимуществ они не дают.
Пример, где появляется классовое мышление - когда у вас есть базовый класс матрицы, есть наследники типа квадратная/прямоугольная/спиральная матрица, есть методы которые в базовом классе объявлены (транспонирование), есть какое-то переиспользование кода и т.п.
И вот на таких примерах уже более понятно становится, что в таком стиле есть свои выгоды написания.
Видите ли, программирование вам на курсе читают блоками. В первом крупном блоке вам объясняли как устроены методы и как написать тот или иной алгоритм (крупный метод разделить на мелкие, до тех пор пока каждый шаг алгоритма получится выразить в элементарных конструкциях языка программирования). Во втором крупном блоке вам объясняют классы, это как бы отдельная, паралельная тема.
И вы решили потянуть примеры из первой темы во вторую, а на них не особо наглядно видно преимущества ООП, хотя внутри класса вы будете использовать методы.
Лучше изучайте классы на примерах, которые специально подобраны в блоке про классы. Умеете крупный метод разделить на более мелкие -- хорошо, освоили процедурный стиль. Какие методы как распихать по классам, как сгруппировать -- это уже объектный стиль.
но уже давно пора забыть это дело и переключаться на ООП.
Вот да. Пара слов о когнитивщине.
как переключить мозг из процедурного стиля на ООП?
Я поменял заголовок, потому что в таком виде ответа нет и вопрос слишком оффтопичен, но попробую ответить. У вас сейчас стадия изучения ООП, когда мозг ещё не освоил мышление в этом стиле. В голове не укладывается, как это использовать. Это пройдёт. В детстве дети не умеют в абстрактное мышление. Они не понимают, что можно складывать не только три яблока плюс два яблока - но итог будет тот же, если складывать три груши и две груши. Это реально сложный интеллектуальный барьер, его проходят все и все забывают. Сейчас у вас иной барьер. Вам говорят про класс уточка и метод крякает -- и вы не понимаете, что это тоже самое, когда вы будете использовать класс "база" и класс "соединение" и "строка подключения". И когда вы придёте на реальное предприятие, скажем в банк - вы придумаете класс "банковский счёт" и класс "проводка". Но сейчас вы не понимаете и не умеете и вам дать задачу на банк - вы не увидите, что это те же самые уточки, просто вид сбоку. А вам больно думать.
Хотите быстрее пройти фазу изучения? Тренируйтесь больше!
И тренируйтесь не в написании алгоритмов, а именно в выделении объектов предметной области. Это пригодится в освоении domain driven design.
Вот например, есть игра и её предметная область разобрана именно с точки зрения классов. https://habr.com/en/post/322258/
Разберите этот пример, а потом начните придумывать свои. Десятками, сотнями. И разбирайте, думайте.
Я вас обрадую: этот барьер вполне преодолим, в нём нет ничего непосильного для человека. Вам нужна мотивация (хочу стать программистом) и вам нужна практика, тренировка (условные 10 тысяч часов).
И если вы ещё не догадались, это составная часть профессии программиста -- постоянное обучение и постоянная попытка перепрыгнуть через очередной барьер когнитивной сложности. Тут об этом подробнее написано, не все тезисы я разделяю, но в целом есть здравое зерно: https://habr.com/en/company/domclick/blog/569062/
способность длительно, в повседневном режиме выдерживать фрустрацию, возникающую от преодоления когнитивной сложности.
Детям в этом плане проще: один раз поняли арифметику -- и можно всю жизнь за прилавком проработать. Программистам в работе чаще приходится брать новые высоты.
