я хочу что бы пароль быз завернут в класс который скрывает всю эту грязь

или в отдельный объект Credentials который вообще всю грязь с аутентификацией и секьюрити прячит от моего юзера

в моем случае PasswordVerifier явился следствием отсутствия такой концепции как Customer

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

а логины - это инфраструктура

я ее хочу изолировать и на этом ооп заканчивается. Внутри то процедурки

т.е ты PasswordVerifier просто переименовал в Credentials

тип того

>который вообще всю грязь с аутентификацией и секьюрити прячит от моего юзера

простая и понятная концепция

Credentials получается у тебя это название сервиса такое?

или он без зависимостей у тебя жить будет?

нет, сущность

мне там сервисы не нужны

а кто тебе нарисует базу с паролями, которые юзались массово?

а че я не могу внутри сущности сделать поле usedPasswords?

или "пароль должен быть глобально уникален"?)

как раз таки с точки зрения клиентского кода у меня будет простой и понятный интерфейс а все эти детали вроде храния истории - это внутри

это скрыто

а кто тебе нарисует базу с паролями, которые юзались массово?

словарик? Это можно опять же в фабрику паролей запихнуть) я ж от VO Password не отказываюсь

или фабрику кредов и тогда мутить историю по другому

словарик на 1 миллион паролей?

словарик на 1 миллион паролей?

1 гиг в оперативке че, малож. Ну и давай будем реалистами, максимум ты будешь юзать 10К паролей

и то как происходит поиск будет сокрыто в CommonPasswordDictionary

хочешь в рэдис ходи, хочешь в базу, хочешь из файла читай

хочешь фильтр блума мути

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

Доброго времени суток коллеги! Я в некотором тупике над пониманием вот этой части - http://www.intuit.ru/studies/curriculums/4076/courses/71/lecture/2132?page=11 А именно функции абстракции с ее описанием. Кто нить может разжевать мне то что там уже разжевали?

я нихера не понял как в оригинале так и в переводе(((

еще раз, из статьи мне непонятны содержимое двух заголовков : Функция абстракции Свойство согласованности Класс-АТД

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

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

так пробовали в 70-х/80-х и чет как-то не взлетело

некоторые приписывают даже смерть ООП именно тем самым uml диаграммам классов

(диаграммы послледовательностей, юзкейсов и т.д. все еще полезны)

некоторые приписывают даже смерть ООП именно тем самым uml диаграммам классов

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

не, так оно не работает. Может быть дядька-архитектор который апрувит какие-то штуки но ломать голову должны все

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

тогда его подчиненные будут быстрее расти и смогут более качественно выполнять свою работу. А так прикинь, заболел/умер твой лид, и все. проект умер

то бишь лид или архитектор это по большей части просто ответственность

именно так

тогда его подчиненные будут быстрее расти и смогут более качественно выполнять свою работу. А так прикинь, заболел/умер твой лид, и все. проект умер

скинуть проект на флешку и похоронить вместе с лидом

скинуть проект на флешку и похоронить вместе с лидом

лепс снова с нами?

лепс снова с нами?

А чё Лепс?)

подскажите, как считаете нужно поступить с отглагольными существительными в подобном кейсе для неких "решателей" уравнений например: interface Solver{ Solve(); int GetProgress(); void Cancel(); } class BruteforceSolver implements Solver class GradientDescentSolver implements Solver

Solver чего? какой то задачи? может лучше этот класс так и назвать, Task?

вы правы, сам до такого же варианта уже додумался

Solver чего? какой то задачи? может лучше этот класс так и назвать, Task?

С такими названиями: SolverUserManager SupporterProviderValidator теряется семантика кода, читаешь вот это и что там происходит? как в ассамблере нужно условно говоря "три раза прыгнут, дернуть себя за ухо" и можно получить результат 2 + 3 = 5 так и здесь "делаем что то, непонятно что, и получаем результат"

Есть один демотиватор как раз про именования в ооп

такой вопрос возник вот если бы не было к примеру до ки по ларавелю или симфони, то предположим пхп программер уровня миддл/синьор долго бы разбирался в этих фреймворках как ими пользоваться?

не тот чат

не тот чат

ларавел/симфони ооп фреймворки))

кек

контекст вопроса то не про их оопшность

а про кейсы использования, не связанные с ооп

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

сложный код != ооп

сложный код = сложный код

ооп = размытое определение

жизнь = тлен

жизнь = симуляция

жизнь = симуляция

не факт

жизнь = симуляция

религия = обман

у ларавел и симфони сложность получается размерами, а не теорией необходимой для понимания. Дока нужна, чтобы такие вот махины уместить в понятные человеку концепции, которые он может использовать

у ларавел и симфони сложность получается размерами, а не теорией необходимой для понимания. Дока нужна, чтобы такие вот махины уместить в понятные человеку концепции, которые он может использовать

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

accidential и eventual?)

essential

https://en.wikipedia.org/wiki/Essential_complexity

ну и классика https://en.wikipedia.org/wiki/No_Silver_Bullet

accidential и eventual?)

да да

accidential и essential, а то там ерунду написал)

eventual это из другой оперы))