Зачем тебе отдельный "класс" координата?
Я объяснил на примере, что он инкапсулирует все координаты.
>Ты обрабатываешь данные внутри этого класса?
Да. В этм классе у меня реализовано сравнение координат. Если тебе нужно узнать координата А = координате В или нет, то используется внутренний метод. Поскольку просто экземпляры нельзя сравнивать – ведь они не значимого типа и сравниваться будет только ссылка. Кроме того, инкапсуляция сравнения избавит от переписывания кода сравнения в другом месте.
То есть, если координаты где-то хранятся в массиве, то нужен метод которых их будет сравнивать. Если координат станет больше двух, то метод придется переписать в основной программе. То есть мы лезем в бизнес логику, которая зависит от координат.
В моем случае, класс координата сам может сравнивать себя с другой координатой.
Вот так
А.сравнить(В) – вернет true или false.
Таким образом в теле другого класса где я сравниваю координаты, мне не придется делать изменения.
А.сравнить(В) будет возвращать bool значение не зависимо от того сколько внутри координат. Хоть 100. Инкапсуляция позволяет программе абстрагироваться от частной реализации, она плевать хотела что там в координате, главное что метод сравнения работает.
>Просто для того, чтобы "неопределенное поведение" все же знают эти современные ЯП - кладешь в переменную tiny int, а через пару тактов там уже вполне себе "string" внутри твоего собственного алгоритма не могло "изменить значения переменной"?
Ты не правильно понимаешь «неопределенное поведение» В массиве интов не может появится стринг. А вот если есть отсортированный массив, и ты несколько раз туда что-то добавил и удалил, то на 10-й раз может оказаться, что из-за сдвигания значений туда-сюда, значение, которое стояло на 5 позиции окажется на 6, но программа об этом не узнает.
>Что мешает в данном случае вместо "2мерного" массива ([x][y]) использовать "3х мерный" ([i][x][y])?
Можно использовать трехмерный, но с ним сложнее и дольше работать. Если массив станет 100 мерным, то искать и сравнивать в нем координаты будет затратно с точки зрения цикломатической сложности.
>inb4: в яваскрипте вообще все кругом объект - даже небо и аллах, и ничего, на нем пишут промышленные системы мирового уровня
Ничего не имею против яваскрипта, объектов и промышленных систем.
>Это мне напоминает подход, при котором предлагается плодить множество "типов" класса ошибка, лишь бы не использовать поле с её кодом.
>>Давай ты нарисуешь свою схему и мы вместе сравним чем она лучше моей
>Няша, ООП + патерны более-менее подходят для всяких "расширяемых систем бла-бла-бла", в примере "пакмен" использовать все это это просто маразм, уровня "прописывать маршруты сообщейний во фреймворке руками" (с) Zend 2 .
Так ведь пакман был примером и я сказал, что если нужен пакман, только пакман и ничего кроме пакмана, то можно сделать проще. Но я хотел привести пример архитектуры, которая как ты сам сказал «более-менее подходят для всяких "расширяемых систем бла-бла-бла"». Ведь писать песочницу, не имея четкого диздока – однозначно означает спонтанное добавление фич, о которых раньше не думал. А давайте сделаем персонажей не прото юнитами, которые только ходят и имеют ХП? Давайте они еще будут иметь, голод, настроение, предпочтения и аватарку? А потом захотим, чтоб у них были характеристики. А потом, чтоб они размножались и дети наследовали характеристики. И т. д. и т. п.
Поэтому необходима "расширяемая система бла-бла-бла". Чтоб привести ее пример я использовал простую, известную всем игру с минимальным набором правил и логики. Чтоб было понятнее, что я имею ввиду. Если я придумал новый сверхлегкий материал, то, сказав удельную его плотность тебе, ты не сразу поймешь отличие от стали. А вот если я дам тебе кастрюлю из стали и из моего материала - ты сможешь проверить вес и прочность, то станет все ясно. Хотя да, делать из этого материала конкретно кастрюлю не обязательно, он предназначен для ракет. Это просто наглядный пример на уровне привычных человеку вещей.
