но именно в примере это лишняя зависимость

это попытка в классе предугадать в классе, как его будут использовать

вообще то ты всегда должен "предугадывать" или хотя бы "закладывать" способ использования твоих штукенций пряча нюансы

это попытка в классе предугадать в классе, как его будут использовать

что за AddressInterface?

откуда у тебя интерфейс взялся

геокордината это обычный объект же

который хранит координаты

любой! публичный метод или свойство составляют интерфейс объекта

и интерфейс должен быть удобным и простым

определение дистанции между 2 координатами надо стараться сделать в отдельном объекте

явно описывая что и зачем

а не как

определение дистанции между 2 координатами надо стараться сделать в отдельном объекте

не обязательно

ну в примере у тебя у координат определение дистанции

ну в примере у тебя у координат определение дистанции

есть такая штука - информационный эксперт. Данные должны обрабатываться там где они есть.

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

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

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

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

у тебя там только один объект 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 гис например

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

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

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