как теперь не забыть последовательность стэпов?

В чем проблема получить пароль от пользователя? Где нарушение инкапсуляции? Я не знаю как и где он это хранит, меня это не интересует

В чем проблема получить пароль от пользователя? Где нарушение инкапсуляции? Я не знаю как и где он это хранит, меня это не интересует

у тебя есть $user. все. Как ты достанешь из него пароль для сравнения?

как ты ВНЕ юзера сравниш хэши?

у тебя есть $user. все. Как ты достанешь из него пароль для сравнения?

У него есть интерфейс? Им и воспользуюсь

У него есть интерфейс? Им и воспользуюсь

ты хочешь кусочек стэйта забрать

причем тут интерфейс?

как ты ВНЕ юзера сравниш хэши?

Не понял в чем проблема

будешь вводить getPassword(): string?

Не понял в чем проблема

И - инкапсуляция. Геттеры (те которые начинаются с get и которые предоставляют доступ к стэйту) - это как раз таки нарушение инкапсуляции

более того

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

что противоречит самой идее объектов

и ты решил "реюзнуть" логику

Аха, один класс по десятку проектов, и окажется что в одном требуется одно поведение, в другом другое, в десятом десятое. А у меня в классе все захардкожено будет?

Аха, один класс по десятку проектов, и окажется что в одном требуется одно поведение, в другом другое, в десятом десятое. А у меня в классе все захардкожено будет?

а с каких пор мы реюзаем бизнес-сущности из проекта в проект?)

разные проекты - разные сущности

проще скопипастить и поправить

С тех пор как на аутсорсе и бизнес-идеи общие за мелкими изменениями

С тех пор как на аутсорсе и бизнес-идеи общие за мелкими изменениями

бери auth0 и не парься)

и у тебя исчезнет необходимость писать логику аутентификации и смены пароля

(собственно это одна из причин по которым у меня есть сущность Credentials) - оно просто приналдежит к отдельному контексту

но опять же

в том что мы сейчас обсуждаем нет "других проектов" и "аутсорса"

контекст очень простой

у нас есть юзеры и они хотят логиниться и менять себе пароль

потом может еще аватарку захотят менять

и у тебя исчезнет необходимость писать логику аутентификации и смены пароля

Я по секрету расскажу - у меня этой проблемы нет, т.к. проверка на стороне сишного сервера ))) я просто проксирую все к нему, но проверка у меня все равно отдельно, т.к. не всегда логин/пароль нужен

Я по секрету расскажу - у меня этой проблемы нет, т.к. проверка на стороне сишного сервера ))) я просто проксирую все к нему, но проверка у меня все равно отдельно, т.к. не всегда логин/пароль нужен

ну то есть у тебя юзер попросту ничего не знает о кредах, так?

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

Я писал про проблемы исходного кода, если он только пароль меняет - проблем нет, если делает что-то ещё - уже несколько поводов для изменения, уже нарушения принципа, о чем я писал )

Я писал про проблемы исходного кода, если он только пароль меняет - проблем нет, если делает что-то ещё - уже несколько поводов для изменения, уже нарушения принципа, о чем я писал )

пользователь один и тот же

ну то есть смотри

откуда берутся изменения?

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

Вся игровая логика на нем, все операции с деньгами, все действия по пользователю. Я - бекенд, сервисы всякие и прочее. На нем ответ ответственность за основные действия, а на мне сопутствующее окружение

Вся игровая логика на нем, все операции с деньгами, все действия по пользователю. Я - бекенд, сервисы всякие и прочее. На нем ответ ответственность за основные действия, а на мне сопутствующее окружение

ну то есть не пускают в серьезные штуки php)

так смотри. ВОт я тебе скинул конкретный пример

класс User

придумай мне поводы для изменений

не "поменять алгоритм хэширования" а "зачем поменять"

У нас хотят на сервере только игру оставить, все остальное на php перенестм

ну или там "проверять 5 предыдущих паролей а 10" "что бы предотврватить возможность перебора паролей если у юзера чего утечет с других сервисов".

Первое я написал, уже изменили раз. Если класс не для смены пароля - этого достаточно. После изменений с внедрением hashier - стало уже лучше

Первое я написал, уже изменили раз. Если класс не для смены пароля - этого достаточно. После изменений с внедрением hashier - стало уже лучше

...ты не понял суть

ладно, в другой раз, убегать надо

Второе ты сам написал, а оно может понадобиться

придумай мне поводы для изменений

add changeEmail)

add changeEmail)

это часть пользовательского профиля - все хорошо пока. Причина для изменений все еще одна и та же

более того, тебе всеравно для этой операции придется поменять класс User

как бы ты не пытался этого избежать

(а единственный способ этого избежать - сделать все поля публичными)

это да, okay, no problems

если же делать по дефолту мутаторы - ну это код который в данный момент не нужен - мертвый код

ну и это как помахать ручкой инкапсуляции

не говоря о том что тестирование станет сложнее гараздо (относитетльно но намного больше тупого кода и меньше возможностей для моков)

Код менять все равно придётся, т.к. там баги сейчас ))

Код менять все равно придётся, т.к. там баги сейчас ))

баги не причина для изменений. они не меняют поведение

не говоря о том что тестирование станет сложнее гараздо (относитетльно но намного больше тупого кода и меньше возможностей для моков)

Это про пример как раз

Это про пример как раз

тебе тест написать и показать насколько удобнее такие штуки тестить?

вечером

могу даже статью написать почему такой подход как ты предлагаешь нарушает OCP

Напиши, а потом добавь hashier (перепиши тесты), потом измени 5 на 10 (переписи тесты), потом верни 5 или убери проверку (и опять перепиши тесты). А все потому, что нарушение есть. В моём случае тесты тестировали бы только добавляемое поведение, а старые тесты менять не пришлось бы (только для удаления старого кода). И я не говорю, что тесты менять плохо, но при плохой архитектуре переписывать приходится больше чем следовало. Паттерны как раз помогают в этом

могу даже статью написать почему такой подход как ты предлагаешь нарушает OCP

Сообщение выше было про тесты, но статью тоже было бы интересно почитатб

вечером

Кстати, уже почти 10 вечера, где тесты? ))))))

Напиши, а потом добавь hashier (перепиши тесты), потом измени 5 на 10 (переписи тесты), потом верни 5 или убери проверку (и опять перепиши тесты). А все потому, что нарушение есть. В моём случае тесты тестировали бы только добавляемое поведение, а старые тесты менять не пришлось бы (только для удаления старого кода). И я не говорю, что тесты менять плохо, но при плохой архитектуре переписывать приходится больше чем следовало. Паттерны как раз помогают в этом

что за чушь ты несешь?)

Кстати, уже почти 10 вечера, где тесты? ))))))

клевая штука часовые пояса

ERROR: S client not available

вечером по UTC

добавил чутка тестов для затравки

что за чушь ты несешь?)

Я написал требования реальных заказчиков. Даже одного. Раз есть тесты, то либо забьешь на них, либо будешь переписывать. Пиши, я буду твоим заказчиком и буду менять требования как захочу ))) может на практике увидишь чем это плохо. Только твой код уже на пути к коду без проблем/вопросов, все равно придешь в том или ином виде к тому, что писал я )))

Ладно, буду за ноутом перечитаю

Меняй)

Я за ноутом только завтра вечером буду

Изменение номер 1: у нас часть пользователей с соцсети, а соцсеть требует, чтобы никакой регистрации/логинов не было. (Вроде как это реальное требование apple было, мы че-то такое делали)

всем привет

народ, есть какие-то проекты опенсорс

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

?

Потом: у нас вк же, хочу чтобы Дуров вообще не мог использовать старый пароль, а Буров мог менять на любой старый

php например

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

неа и не может быть, это жже опенсорс - написал пару строчек, запулреквестил. много ты в паре строчек об архитектуре думаешь?

неа и не может быть, это жже опенсорс - написал пару строчек, запулреквестил. много ты в паре строчек об архитектуре думаешь?

ну есть же фреймворки например где далеко не 5 строчек

ну есть же фреймворки например где далеко не 5 строчек

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

А что за языки прям тру ООП? Ну кроме smalltalk.

А что за языки прям тру ООП? Ну кроме smalltalk.

Js :)

А что за языки прям тру ООП? Ну кроме smalltalk.

Сам бы хотел это узнать

Если вспомнить вчерашний (кажись) спор насчет процедурщины и ооп - нету тру ооп языков (это был вывод)

а что значит тру ооп?

а что значит тру ооп?

Погугли Егора Бугаенко)

а что значит тру ооп?

Ну это как хаскелль или си, только с ООП.

а чем джава и c# не тру ооп?

а чем джава и c# не тру ооп?

Примтивы есть.

Примтивы есть.

То есть хаскель и раст более ООП, чем кресты и жаба, так?

То есть хаскель и раст более ООП, чем кресты и жаба, так?

Не знаком с хаскелем и растом.

Все понятно.

Даже обидно как-то)

ну в rust тоже есть примитивы же

если речь о примитивах