и придешь к тому, что у тебя монстр будет

и придешь к тому, что у тебя монстр будет

Почему? Я не вижу проблем. В какую сторону масштабировать решение?

у тебя 10 полей в модели

у тебя 10 полей в модели

Я посмотрел, что такое репозиторий. Понял, что ты имел ввиду. Решение не такое.

Должен быть билдер, который создаёт обект. После этот объект идёт в репозиторий. Ну или если все поля обязательны и полей не так много, то можно и конструктор зафигачить.

И сет гет это не api, это прямой инжект в поля

Слушай, а почему гет - это не апи?

вот это уже прям совсем близко

только билдер под капотом такой же сет делает

если что

если что

Билдер - это костыль в джаве, так как нет нормального синтаксиса в создании объектов.

короче, Андрей, учись свои мысли выражать, пожалуйста, сейчас ты совсем другое говоришь, чем до этого)

в итоге мы пришли к одному с небольшими отличиями

Если мы возьмём питон или c#, то там есть значения по умолчанию или же именованные аргументы. Это удобный способ конструировать объект.

короче, Андрей, учись свои мысли выражать, пожалуйста, сейчас ты совсем другое говоришь, чем до этого)

Эм? Где я утверждал обратное? Кроме кода, так как я не правильно понял пример.

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

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

Ну это да. Отказ от утил классов - это такая конфетка.

Слушай, а почему гет - это не апи?

Дисклеймер: не надо только говорить, что я доебываюсь, это важно. Геттеров не должно быть по принципу tell, don't ask. Но вот, например, охранник хочет увидеть твой пропуск, ты должен показать. Кажется, что вот он гетер. Однако, вместо String getAccessCard(), лучше сделать String showAccessCard(), на худой конец просто accessCard(). Почему это важно? Такое мышление и именование помогает оставлять гетеры только там, где это действительно необходимо по смыслу. А вообще это все эзотерика, конечно, никто от и до таких правил не придерживается, но, если стараться, то код получается меньше и читабильнее (не в смысле, как императивщики говорят, мол, вот я смотрю на портянку в 2к строк и мне все понятно, сразу все вижу, нахер ваш ооп, а в смысле того, что каждая сущность маленькая, у нее single responsibility, поэтому ей легко дать говорящее имя и при чтении легко понять, что она делает, а самое главное легко запомнить и понять архитектуру, когда все маленькое, ответственности не дублируются и у сущностей только по одной ответственности. Но, ещё раз, такого почти не бывает. Мне нравится, например, код aeron в этом плане, рекомендую.

Дисклеймер: не надо только говорить, что я доебываюсь, это важно. Геттеров не должно быть по принципу tell, don't ask. Но вот, например, охранник хочет увидеть твой пропуск, ты должен показать. Кажется, что вот он гетер. Однако, вместо String getAccessCard(), лучше сделать String showAccessCard(), на худой конец просто accessCard(). Почему это важно? Такое мышление и именование помогает оставлять гетеры только там, где это действительно необходимо по смыслу. А вообще это все эзотерика, конечно, никто от и до таких правил не придерживается, но, если стараться, то код получается меньше и читабильнее (не в смысле, как императивщики говорят, мол, вот я смотрю на портянку в 2к строк и мне все понятно, сразу все вижу, нахер ваш ооп, а в смысле того, что каждая сущность маленькая, у нее single responsibility, поэтому ей легко дать говорящее имя и при чтении легко понять, что она делает, а самое главное легко запомнить и понять архитектуру, когда все маленькое, ответственности не дублируются и у сущностей только по одной ответственности. Но, ещё раз, такого почти не бывает. Мне нравится, например, код aeron в этом плане, рекомендую.

Я это, новенький тут и просто интересуюсь (не срача ради): а чем accessCard() лучше getAccessCard()? get - глагол, явное действие, к тому же автодополнение с get покажет все, что можно получить. showAccessCard() - имхо, неудобно, когда карту, например, нужно отдать, а не показать - делать еще метод giveAccessCard?

Я это, новенький тут и просто интересуюсь (не срача ради): а чем accessCard() лучше getAccessCard()? get - глагол, явное действие, к тому же автодополнение с get покажет все, что можно получить. showAccessCard() - имхо, неудобно, когда карту, например, нужно отдать, а не показать - делать еще метод giveAccessCard?

Это лучше так как показывает что ты именно делаешь, а не как.

Дисклеймер: не надо только говорить, что я доебываюсь, это важно. Геттеров не должно быть по принципу tell, don't ask. Но вот, например, охранник хочет увидеть твой пропуск, ты должен показать. Кажется, что вот он гетер. Однако, вместо String getAccessCard(), лучше сделать String showAccessCard(), на худой конец просто accessCard(). Почему это важно? Такое мышление и именование помогает оставлять гетеры только там, где это действительно необходимо по смыслу. А вообще это все эзотерика, конечно, никто от и до таких правил не придерживается, но, если стараться, то код получается меньше и читабильнее (не в смысле, как императивщики говорят, мол, вот я смотрю на портянку в 2к строк и мне все понятно, сразу все вижу, нахер ваш ооп, а в смысле того, что каждая сущность маленькая, у нее single responsibility, поэтому ей легко дать говорящее имя и при чтении легко понять, что она делает, а самое главное легко запомнить и понять архитектуру, когда все маленькое, ответственности не дублируются и у сущностей только по одной ответственности. Но, ещё раз, такого почти не бывает. Мне нравится, например, код aeron в этом плане, рекомендую.

ты случаем не с Егором Бугаенко работаешь?

Это лучше так как показывает что ты именно делаешь, а не как.

вода какая-то

все это условно

ты случаем не с Егором Бугаенко работаешь?

Почему?

ты случаем не с Егором Бугаенко работаешь?

Один смузи на двоих пьют

Почему?

ну он очень любит вещать "очень интересные и оригинальные никому не нужные" идеи

вода какая-то

Возможно. Просто я привык читать код как рассказ. А не следть за потоками данных. Получили то, прислоили туда. Вот правда.

ты случаем не с Егором Бугаенко работаешь?

Нет, я выше писал, что с Егором не согласен и не навязываю никому ооп и сам на нем не пишу. Меня спрашивают как ооп -- я отвечаю

ну он очень любит вещать "очень интересные и оригинальные никому не нужные" идеи

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

ты случаем не с Егором Бугаенко работаешь?

Не, Егор топит за то чтобы не было кэмелкейсов в методах.

Не, Егор топит за то чтобы не было кэмелкейсов в методах.

Егор за многое топит)

Возможно. Просто я привык читать код как рассказ. А не следть за потоками данных. Получили то, прислоили туда. Вот правда.

Правда со всеми этими стримами новыми задолбаешься читать)

Не, Егор топит за то чтобы не было кэмелкейсов в методах.

это еще зачем

Я это, новенький тут и просто интересуюсь (не срача ради): а чем accessCard() лучше getAccessCard()? get - глагол, явное действие, к тому же автодополнение с get покажет все, что можно получить. showAccessCard() - имхо, неудобно, когда карту, например, нужно отдать, а не показать - делать еще метод giveAccessCard?

Вообще вопрос о "accessCard() или getAccessCard()" интеренес с точки зрения языка. В русском "человек.карточка()" звучит лучше, чем "человек.получитьКарточку()". Но в английском глаголы играют немного другую роль. Мы говорим "Я человек", а на английском - "I AM human" (я есть человек). Есть множество примеров (хотя ничего не лезет в голову), когда дословно переведенная фраза с русского на английский (на английском без глагола) звучит убого для английского уха, но нормальноо для русского. Поэтому интересно, что на этот вопрос носитель скажет

это еще зачем

Типа если у тебя кэмелкейс, значит у тебя скоуп перегружен и занимается, тем чем заниматься не должен.

Должно быть типа не user.getAccessCard(), а user.access.card() к примеру

Типа если у тебя кэмелкейс, значит у тебя скоуп перегружен и занимается, тем чем заниматься не должен.

Это не касается методов, а только имён переменных.

Я это, новенький тут и просто интересуюсь (не срача ради): а чем accessCard() лучше getAccessCard()? get - глагол, явное действие, к тому же автодополнение с get покажет все, что можно получить. showAccessCard() - имхо, неудобно, когда карту, например, нужно отдать, а не показать - делать еще метод giveAccessCard?

А ничем в целом, слов меньше. Я про конкретный пример, кстати, плохой. Отдавать карту ты никуда не должен. Это не по ооп. Сори, труъ вэй это тебе принять охранника и ему в валидэйт пихнуть свою карту. Но я не люблю inversion of control, запутывает. Ну и это пример, который показывает слабость ооп как парадигмы. Это не то, как надо писать. Я говорю о текущих абстракциях, которых не избежать.

Не знаю, как вам, а я с чем-то согласен с Егором и не считаю, что он говорит бред

Ну методов типа getAbsctractBeanFactroy()

Это не касается методов, а только имён переменных.

И методов тоже, собственно getUserMail не тру будет)

И методов тоже, собственно getUserMail не тру будет)

Этот метод не только из-за camelCase плох.

Этот метод не только из-за camelCase плох.

Ну типа да, потому что скоуп будет перегружен, а кэмелкейс, это типа тебе подсказка)

Это как про количество уровней абстракции "пять плюс, минус два"

Или количество параметров в методе "не более трех"

Не канон, просто некоторые в религию превращают.

А ничем в целом, слов меньше. Я про конкретный пример, кстати, плохой. Отдавать карту ты никуда не должен. Это не по ооп. Сори, труъ вэй это тебе принять охранника и ему в валидэйт пихнуть свою карту. Но я не люблю inversion of control, запутывает. Ну и это пример, который показывает слабость ооп как парадигмы. Это не то, как надо писать. Я говорю о текущих абстракциях, которых не избежать.

Тру вей - это сделать объект "будка", посадить туда охранника и провериться в будке)

Этот метод не только из-за camelCase плох.

а чем плох camelCase?

а чем плох camelCase?

Я не говорил, что он плох.

Блин, опять не так написал.

Этот метод не только из-за camelCase плох.

Этот метод не из-за camelCase плох.

Я смотрю тебе это вчерашнее фото очень понравилось)

коты - наше все

Хомячки круче.

я добрался до компа, теперь нормально сформулирую свои мысли. show лучше, чем get, если принять принцип tell, don't ask. Говоря родным языком, если сущность А хочет что-то от сущности B, то она A должна сказать "B, сделай", а не "B, дай, я сама сделаю". Возвращаясь к примеру с охранником. Пусть есть Person и Guard и нужно проверить пропуск и, если он валиден, пройти. Императив (ask, programmer tells how): Card card = person.getCard(); if (guard.validate(card)) { person.pass(); } else { person.turnBack(); } ООП (tell, programmer tells what): person.tryPass(guard); boolean tryPass(guard) { if (guard.validate(this.card)) { this.pass(); } else { this.turnBack(); } } То есть весь смысл в том, что ты говоришь: человеку -- попытайся пройти человек охраннику -- проверь мой пропуск человек сам себе -- идти вперед или назад Поэтому, если есть геттеры явные, то это уже не ООП. Но вот такие выверты приводят к inverion of control, когда вместо того, чтобы вызвать метод у объекта, ты передаешь этот объект внутрь метода другого объекта, который этот метод уже вызывает. Это все круто, красиво, декларативно, конечно, но уследить даже за таким простым примером сложно (имхо). ООП ради ООП -- это совершенно глупая идея, карго культ какой-то. У всего есть недостатки, так давайте от них отказываться. В этом примере я бы не стал так наворачивать, пусть будет императивно, но зато не запутано. В другом месте я буду придерживаться принципов ООП, потому что там они помогают. Если так хочется декларативности, то можно передать просто функцию-валидатор, так код внутри Person не завяжется на Guard, и вызов валидатора будет явно виден, без захода в Person: person.tryPass(card -> guard.validate(card)); На вопрос чем show лучше get ответ простой: гетеров должно быть мало, если все называть get, то привыкнешь и перестанешь обращать внимание, допустишь много гетеров, свалишься в императив, это первое. Второе это то, что get очень абстрактно, а для каждой конкретной ситуации можно подобрать более правильное слово. Ты же не называешь у билдера метод build -- getBuiltObject()? Потому что лучше в контексте подходит build.

лонг рид в чате, я ужасен, сорян

самое лучшее: Person: person.tryPass(card -> guard.validate(card));

я добрался до компа, теперь нормально сформулирую свои мысли. show лучше, чем get, если принять принцип tell, don't ask. Говоря родным языком, если сущность А хочет что-то от сущности B, то она A должна сказать "B, сделай", а не "B, дай, я сама сделаю". Возвращаясь к примеру с охранником. Пусть есть Person и Guard и нужно проверить пропуск и, если он валиден, пройти. Императив (ask, programmer tells how): Card card = person.getCard(); if (guard.validate(card)) { person.pass(); } else { person.turnBack(); } ООП (tell, programmer tells what): person.tryPass(guard); boolean tryPass(guard) { if (guard.validate(this.card)) { this.pass(); } else { this.turnBack(); } } То есть весь смысл в том, что ты говоришь: человеку -- попытайся пройти человек охраннику -- проверь мой пропуск человек сам себе -- идти вперед или назад Поэтому, если есть геттеры явные, то это уже не ООП. Но вот такие выверты приводят к inverion of control, когда вместо того, чтобы вызвать метод у объекта, ты передаешь этот объект внутрь метода другого объекта, который этот метод уже вызывает. Это все круто, красиво, декларативно, конечно, но уследить даже за таким простым примером сложно (имхо). ООП ради ООП -- это совершенно глупая идея, карго культ какой-то. У всего есть недостатки, так давайте от них отказываться. В этом примере я бы не стал так наворачивать, пусть будет императивно, но зато не запутано. В другом месте я буду придерживаться принципов ООП, потому что там они помогают. Если так хочется декларативности, то можно передать просто функцию-валидатор, так код внутри Person не завяжется на Guard, и вызов валидатора будет явно виден, без захода в Person: person.tryPass(card -> guard.validate(card)); На вопрос чем show лучше get ответ простой: гетеров должно быть мало, если все называть get, то привыкнешь и перестанешь обращать внимание, допустишь много гетеров, свалишься в императив, это первое. Второе это то, что get очень абстрактно, а для каждой конкретной ситуации можно подобрать более правильное слово. Ты же не называешь у билдера метод build -- getBuiltObject()? Потому что лучше в контексте подходит build.

Человек говорит охраннику "проверь мой пропуск"? :)

самое лучшее: Person: person.tryPass(card -> guard.validate(card));

поддерживаю

Человек говорит охраннику "проверь мой пропуск"? :)

да, ты когда в офис проходишь, пропуск не сам предъявляешь, тебя ловят и заставляют?)

Человек говорит охраннику "проверь мой пропуск"? :)

И почему person должен знать про охранника и про то, что он умеет валидировать?

Не хочет - не валидирует

И почему person должен знать про охранника и про то, что он умеет валидировать?

Я думаю это прописано в инструкциях )

И почему person должен знать про охранника и про то, что он умеет валидировать?

это предикат, туда можно что угодно запихнуть

person ничего не знает

ERROR: S client not available

это предикат, туда можно что угодно запихнуть

Захочу и ничего не запихну - валидации не будет

Захочу и ничего не запихну - валидации не будет

card -> true

Ну то есть все норм с этим?

:)

Захочу и ничего не запихну - валидации не будет

Гениальный аргумент.

Так легко можно обойти валидацию

как то ниочень. персон должен знать реализацию охраника

этож избыточная связанность

Человек сам решает, на каком основании его пускать

Так легко можно обойти валидацию

Дык у тебя валидация - часть кода.

даже если гвард интерфейс

как то ниочень. персон должен знать реализацию охраника

+1

Дык у тебя валидация - часть кода.

Какого кода? Персона?

Кривая асбракция, имхо

как то ниочень. персон должен знать реализацию охраника

Почему он должен знать реализацию? Он знает контракт.

Так легко можно обойти валидацию

person.tryPass(guard.getValidationFunction(card));

?

person.tryPass(guard.getValidationFunction(card));

Валидация в tryPass происходит

Могу не вызывать его, могу внутри ничего не делать

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

Я такой прихожу на работу и говорю охраннику:"сейчас я тебе расскажу, как ты должен меня проверить"

если у меня пропуск не подходит

кастуйте Бугаенко, тут срач начался

то у охранника сорвет крышу и он взорвет офис?

Я такой прихожу на работу и говорю охраннику:"сейчас я тебе расскажу, как ты должен меня проверить"

А охранник мне:"покажи бейдж или иди в жопу"

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

кастуйте Бугаенко, тут срач начался

Сливаетесь?

Егор то чем поможет?

Он не исправит кривую абстракцию

ничего person не знает о Guard, Guard передется, как аргумент, это не tight coupling

Егор то чем поможет?

разъяснит