потому что в этом суть ООП

данные и логика по обработке этих данных должны лежать вместе

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

у тебя там только один объект GeoCordinat ?

больше никаких объектов ?)

делаем GodObject ?

у каждого объекта своя зона ответстветнности и свое поведение

у гео кординаты очевидно это координаты

оценка расстояния между двумя координатами - задача самих координат

ну и возможно название места

точно так же как деньги могут сравнивать друг дружку

короч, у тебя процедурныйы взгляд на вещи. Данные и процедуры

ну ок, это дело вкуса

но я бы делал не так

это не дело вкуса. это принципиальна вещи

инкапсуляция

закон деметры

зачем в простом объекте по хранению координат держать логику

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

новую кординату создай

вот тебе и сдвиг

кто его будет создавать?

и используй ее

это детали

кто тебе будет сдвигать?

а где она будет создаваться?

то что иммутабельность и вся хуйня это и так понятно

где эта логика должна быть?

отдельные функции в неймспейсе? статические методы? отдельный сервис?

а где ты ее двигаешь

для чего ?

на карте ?

новая отметка ?

class Point { public function moveRelativly(Point $point); }

какая разница?) алгоритм просчета дистанции не такой уж и простой

чтобы его везде копипастить

ну так вынеси его из объекта тем более

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

$theta = $lng1 - $lng2; $dist = sin(deg2rad($lat1)) * sin(deg2rad($lat2)) + cos(deg2rad($lat1)) * cos(deg2rad($lat2)) * cos(deg2rad($theta)); $dist = acos($dist); $dist = rad2deg($dist); return round($dist * 60 * 1.1515);

вот чтобы быть точнее

куда вынести?

ну я бы делал ServiceGeoCordinat

ну так вынеси его из объекта тем более

1. Куда? В PointDistanceCalculator? 2. Теперь придется открыть доступ к внутреннему состоянию Point

короч ты только что сломал инкапсуляцию(

и для определения дистанций метод distance(GeoCordinat $a, GeoCordinat $b);

как этот метод получит данные находящиеся внутри $a и $b?

гетеры?

публичные свойства?

да

геттеры очень даже ничего

поздравляю, ты только что нарушил закон деметры

https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%94%D0%B5%D0%BC%D0%B5%D1%82%D1%80%D1%8B

геттеры очень даже ничего

ууух

если у тебя есть геттеры, которые нужны ТОЛЬКО для одной фигни, значит эту фигню надо вносить в объект

так там МОДУЛИ

а тут классы

эти классы в одном модуле

вот елси у тебя 10 операций - то тогда значит данные лежат немного не там где надо)

геттеры в целом свидетельствуют о низкой внутренней связанности системы (coheasion)

полностью от них отказаться никак не выйдет, но лепить их просто так - это не ООП

хорошо вот тебе вопрос

твои кординаты должны взаимодействовать с дорой

тот же 2 гис например

и тебе надо просчитывать кратчайший маршрут

на основе карт

нет, мои координаты не должны с ними взаимодействовать

это графы и поиск кратчайшего пути

нам нужна дистанция между 2 точками

не кратчайшие пути

ок у тебя спека и ты прав

ты работаешь по тз и ничего никогда не меняется

что бы найти кратчейший путь тебе нужна карта

все стабильно

вот карта и найдет тебе все

$map->shortestWay($pointA, $pointB);

давай вместо координат на карте возьмем координаты на 2х мерном пространстве

или вообще вектора

там тебе 2гис точно не нужен)

ок ваше дело я не настайваю я просто говорю как бы я делал

с 2gis интереснее на самом деле)

хотите так делать либу делайте

просто на результаты вычисления могут влиять параметры самого объекта

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

я предпочитаю чтобы параметры для расчетов передавались явно

это лишь имхо

я предпочитаю чтобы параметры для расчетов передавались явно

тогда тебе стоит просто перестать притворяться что ты делаешь ооп)

ок я делаю процедурный код

еще какие выводы?

процедурный код = сложность

да

сложность = дорого поддерживать

писать ооп как говорите вы?

ну тип того

или функциональщина

там тоже самое но прикольнее

вот уже разбежался прямо переписывать

и чуть ближе к тому что тебе нравится

ОК для именованного конструктора берем не VO, а сущность, у которой есть свои хотелки и поведение и потом делаем User::createFromEmail($email)

у сущностей же может быть логика верно?)

вывод на самом деле прост, то что ваши взгляды отличны от моих