ну ок. Будет User and UserImpl )

User <- ConcreteUser

User {FrameworkName}User как вариант

Animal <- Cat

я правда не знаю что за юзер там будет. так что просто сказал

вообще... название интерфейса неправильное

User {FrameworkName}User как вариант

User AppUser ? норм ?

у ларавеля оно правильнее называется. Authenticatable

гг

вообще если упарываться по инкапсуляции, то можно объявлять в Application слое интерфейсы которые реализовывать в Infrastructure и уже ТОЛЬКО там юзать всё что идет с либами или фреймворками

User AppUser ? норм ?

Вообще интерфейс с названием User неправильный

само название об этом говорит

и проблема с неймингом

Вообще интерфейс с названием User неправильный

why ?

Потому что интерфейс должен описывать методы, которые он представляет, а не конкретную сущность

у ларавеля оно правильнее называется. Authenticatable

^

Потому что интерфейс должен описывать методы, которые он представляет, а не конкретную сущность

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

Ну ну

у меня есть интерфейс для вьюМоделек которые API возвращает

интерфейс называется PreView и содержит метод render()

как мне надо было назвать, Renderable ?

А почему бы и нет?)

В целом есть еще интерфейсы типа Animal < Cat, как я выше написал. Вот они уже не про набор методов, а про абстракцию над группой сущностей

Потому что интерфейс должен описывать методы, которые он представляет, а не конкретную сущность

для меня интерфейс это тип. Я описываю тип пользователя. У пользователя есть uid - я и описал этот метод в этом типе. Это так же как тип Animal и там метод walk(direction): void

Итого имеем. Либо у тебя вариант: class User implements Authenticatable, Registrate, ... либо class Guest implements User

ну ок. Будет User and UserImpl )

Будет Symfony\Security\User и App\Entity\User

нелюблю суффиксы Interface и Exception

а в твоем наброске graphql был суффикс Exception :D

а в твоем наброске graphql был суффикс Exception :D

не люблю и не использую - разные вещи тащемта)

аргументный аргумент

как мне надо было назвать, Renderable ?

потмоу что Renderable это слишком общее название, еоторая в слое отображения по разному может трактоваться

Будет Symfony\Security\User и App\Entity\User

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

легко случайно заюзать чтото не то и не заметить

да это и шторм, и phan, и psalm заметят

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

ДАЖЕ В ПЫХЕ АУ

да это и шторм, и phan, и psalm заметят

что заметят?

ну ок. Будет User and UserImpl )

У тебя суффикс должен отражать суть реализации интерфейса, UserImpl это максимально тупое название, т.е должно быть Интерфейс User Реализации CorpPortalUser, RegUser, AdminUser и т.д

что заметят?

Type mismatch

а если это интерфейс и реализация

кто заметит то?

что заметят?

что типы не сходятся

а они сходятся :)

У тебя суффикс должен отражать суть реализации интерфейса, UserImpl это максимально тупое название, т.е должно быть Интерфейс User Реализации CorpPortalUser, RegUser, AdminUser и т.д

камон. для чего к названию класса user добавлять название компании или название фреймворка. Какой профит от этого?

а если это интерфейс и реализация

нельзя вместо реализации передавать что-то чисто интерфейса

почему нет то? блин

камон. для чего к названию класса user добавлять название компании или название фреймворка. Какой профит от этого?

Причем тут компания и фреймворк?)))

камон. для чего к названию класса user добавлять название компании или название фреймворка. Какой профит от этого?

никакого, это бред

в ларке есть 4 класса Repository

это и интерфейсы и реализации Cache и Config

это как назвать класс по названию звезды в системе альфа центавра

почему нет то? блин

потому что если кто-то ждет InMemoryImpl, ему нельзя передавать PostgresqlImpl ну

Причем тут компания и фреймворк?)))

что такое RegUser ?

и постоянно приходится смотреть как бы не то не заюзать

Зарегестиррованный пользователь

что такое RegUser ?

Артур упрлс

Это просто пример

Но я имел ввиду если ты называешь реализацию без суффикса, то 99% интерфейс просто не нужен

Зарегестиррованный пользователь

File : FileInterface как назвать клас файл ?

File : FileInterface как назвать клас файл ?

а для чего абстракция File нужна?

File : FileInterface как назвать клас файл ?

я тебе выше привел два примера

может ли быть реализация файла, которая с s3 работает?

Но я имел ввиду если ты называешь реализацию без суффикса, то 99% интерфейс просто не нужен

Использую правило: если есть публичный метод - должен быть интерфейс. Не всегда - но в библиотеках это правило должно быть 100%

File : FileInterface как назвать клас файл ?

Нужно знать что это за файл, и как он используется и в чем отличие, от других реализаций

Использую правило: если есть публичный метод - должен быть интерфейс. Не всегда - но в библиотеках это правило должно быть 100%

догматизм в чистом виде

сущностям интерфейсы не нужны

ERROR: S client not available

так же как и VO

да много чему интерфейсы не нужны

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

непонятно какую проблему этим пытаетесь решить

В целом, интерфейс есть у каждого класса

нужно еще об этом помнить

да, класс это тип+реализация

я рассказывал же про чувака который хотел создать интерфейс Point и юзать его для канваса и для геоточек

в данном примере согласен. Но в библиотеках думаю они должны быть всегда. Так как мы стараемся делать код гибким.

типо унификация

В целом, интерфейс есть у каждого класса

+++

может ли быть реализация файла, которая с s3 работает?

LocalFile, S3File : File

LocalFile, S3File : File

согласен. понял.

да многие не понимают что когда ты объявляешь public что то в класе ты уже объявляешь "интерфейс" в его первоначальном значении(а не в значении языковой структуры джавы и пыхи)

LocalFile, S3File : File

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

непонятно какую проблему этим пытаетесь решить

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

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

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

в данном примере согласен. Но в библиотеках думаю они должны быть всегда. Так как мы стараемся делать код гибким.

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

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

Ну да, а в чем проблема?

что это несбыточные мечты и отдельный интерфейс никак не помогает

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

це ж стратегия

це ж стратегия

https://imgflip.com/i/2gnvqt

путаница довольно популярная кстати)

https://stackoverflow.com/questions/31608902/polymorphism-vs-strategy-pattern

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

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

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

Зависит от контекста

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

меньше кода и дублирования

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

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

удобно спорить, можно приводить любые аргументы

в 9 случаях из 10 я бы ответил что круглый)

Артур, тебе надо взять таймаут