extends RsPage

@yegor256 выступает против имиплементационного наследования. Я здесь с ним не совсем согласен с точки зрения SOLID, но это долгая история.

Объясню почему ооп в 2к18 нинужно по одному тут @hcdev

Объясню почему ооп в 2к18 нинужно по одному тут @hcdev

А чо так мало админов?

@yegor256 выступает против имиплементационного наследования. Я здесь с ним не совсем согласен с точки зрения SOLID, но это долгая история.

я не хочу гуглить "имимплементационного" :) это означает что наследовать только абстрактные классы?

Объясню почему ооп в 2к18 нинужно по одному тут @hcdev

Иногда думается что в 2к18 не только ООП не нужно, но и ФП, математика, паттерны, SOLID, здравый смысл и голова на плечах. о_О

Так а что значит "дополнительно". Вот открыл класс, вот у него extends/implements есть. Ничего больше открывать не надо, чтобы узнать что класс наследует. Все что относится к классу находится в его модуле - его имя, его родители, его поля/методы, его документация в конце концов. Если класс при этом максимально cohesive, то он будет с большой вероятностью убираться на один экран. И пофиг как бы что его зовут RsPage, ибо сразу за именем будет implements Response

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

Иногда думается что в 2к18 не только ООП не нужно, но и ФП, математика, паттерны, SOLID, здравый смысл и голова на плечах. о_О

у данного товарища голова есть, а мозга в ней нет. Нонсенс

А чо так мало админов?

достаточно

достаточно

Ща бы в 2018ом не уметь в сарказм ?

какой нах сарказм?

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

)

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

В фп чате? Сильна

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

Ну и че это за словоблудство? У класса всегда будут зависимости, которые придется открыть чтобы понять. Хоть тресни но от каплинга на другие модули полностью не уйдешь. И если мы имеем иерархию классов по LSP, то в качестве зависимостей использовать конкретику не выгодно никогда. А значит типами полей и аргументов методов всегда будут интерфейсы, у которых имя как правило вменяемо. Единственное исключение - т.н. Егоровы матрешки. Но там и так конкретика, от которой не уйдешь.

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

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

Так ок. Кто говорит что в коде будут все эти RsPage? Есть у вас допустим класс который работает с респонзом, по DIP следует юзать в нем тип Response, а не RsPage.

https://habrahabr.ru/post/353292/

Хм, новая книга дяди Боба тоже этот момент осветила: фп и =. Совпадение?

Так ок. Кто говорит что в коде будут все эти RsPage? Есть у вас допустим класс который работает с респонзом, по DIP следует юзать в нем тип Response, а не RsPage.

В коде самого класса оно будет. Этого достаточно.

А так же оно будет в сетапе di

Хм, новая книга дяди Боба тоже этот момент осветила: фп и =. Совпадение?

Что за новая книга?

Что за новая книга?

Чистая архитектура

Надо почитать

А так же оно будет в сетапе di

Сетап di/Егоровы пирамидки - это конкретика. Там по определению никуда от них не денешься. И камон - о чем мы спорим? Ну не нравится Rs, можно сделать PageResponse, вопрос конвеншенов. Че такого то

Об этом и спорим. Здравый смысл против конвеншнов

Об этом и спорим. Здравый смысл против конвеншнов

Нука-нука? И в чем тогда здравый смысл?

Закладывать оптимально информацию в сигнатуры, а не ссылаться на конвеншны

Закладывать оптимально информацию в сигнатуры, а не ссылаться на конвеншны

Еще раз - в сигнатурах все нормально будет. Там будут интерфейсы и базовые типы. А если под сигнатурами вы подразумеваете di конфиг, то... хм... серьезно? о_О

Сигнатура - это имя в первую очередь. Сигнатура класса. Она будет так или иначе где-то использована.

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

Ну да. В di конфигах и будет. Либо в композиционных пирамидках если по EO. И один хрен увидев эти имена первый раз, хочешь-нехочешь а придется туда заглянуть хотя бы разок. А это значит что мы спорим исключительно о вкусовщине. Предлагаю закончить.

Я практиковал эту схему с префиксами, она не несла таких уж прям неудобств. Субъективно

Когда количество абстракций в одном джарнике вменяемо, эти префиксы быстро запоминаются. Но опять же - ничто не мешает юзать альтернативный нейминг.

Ну да. В di конфигах и будет. Либо в композиционных пирамидках если по EO. И один хрен увидев эти имена первый раз, хочешь-нехочешь а придется туда заглянуть хотя бы разок. А это значит что мы спорим исключительно о вкусовщине. Предлагаю закончить.

я именно поэтому и пытался спросить. class WhoCaresAboutNamesForImplementationClasses extends Response - это нормально для тебя?

я именно поэтому и пытался спросить. class WhoCaresAboutNamesForImplementationClasses extends Response - это нормально для тебя?

Это вполне вменяемое имя для бессмысленного класса, че? Так часто и поступают когда пишут внутри какую нибудь лабудень. О чем мы спорим опять же? Я не говорил что имя класса не имеет смысла вообще, я всего лишь сказал что с префиксами жить можно.

Это вполне вменяемое имя для бессмысленного класса, че? Так часто и поступают когда пишут внутри какую нибудь лабудень. О чем мы спорим опять же? Я не говорил что имя класса не имеет смысла вообще, я всего лишь сказал что с префиксами жить можно.

ну ты мечешься между двумя мнениями гдето посередине и видимо считаешь это золотой серединой. Либо имя имеет значение и мы делаем правильные имена без префиксов непонятных, либо имя не имеет значения вообще, и мы называем как хотим

ну ты мечешься между двумя мнениями гдето посередине и видимо считаешь это золотой серединой. Либо имя имеет значение и мы делаем правильные имена без префиксов непонятных, либо имя не имеет значения вообще, и мы называем как хотим

Ну хорошо - какое именование будет правильным по вашему мнению

Просто заменить сокращение смыслом

Rs => Response

PageResponse?

or ReponsePage I don't remember

А если имя абстракции длинное из-за предметной области?

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

ну ты мечешься между двумя мнениями гдето посередине и видимо считаешь это золотой серединой. Либо имя имеет значение и мы делаем правильные имена без префиксов непонятных, либо имя не имеет значения вообще, и мы называем как хотим

Вообще не совсем корректное умозаключение имхо. Если имя имеет значение, это еще не означает что правильные имена это имена без префиксов. Это как раз и есть вкусовщина, на холивар о которой вы пытаетесь меня вывести.

Вообще не совсем корректное умозаключение имхо. Если имя имеет значение, это еще не означает что правильные имена это имена без префиксов. Это как раз и есть вкусовщина, на холивар о которой вы пытаетесь меня вывести.

да не холивар. Rs - это абсолютно не сразу понятное слово. над которым надо думать. Заменить его Response - дело даже не 10 секунд а просто привычки правильно писать имена классов

да не холивар. Rs - это абсолютно не сразу понятное слово. над которым надо думать. Заменить его Response - дело даже не 10 секунд а просто привычки правильно писать имена классов

В теории все так. На практике я встречал ситуации когда отказ от префиксов приводил к длинным именам, которые муторно читать в той же EO композиции, где таких имен много. Проще сокращение запомнить.

Согласен c @Adelf32 . Замечу, что в проекте помимо Rs есть много других неочевидных сокращений:

Rq - Request Ps - Post?

а мне кажется это просто стиль. Человек просто любит все сокращать. писать как можно короче. с этим же связан совет удалить все пустые строки :)) я вот кстати наоборот люблю свободный стиль. с полными именами классов и везде отделяю пустыми строками логические вещи в методах.

@Adelf32 мне кажется, пхпшнику было бы проще работать с мапом, чем понять сокращения Егора ?

@Adelf32 мне кажется, пхпшнику было бы проще работать с мапом, чем понять сокращения Егора ?

каким мапом?)

каким мапом?)

Вам, задротам, со всем будет просто )

А так, мы в гиксах обсуждали по этой теме с ним

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

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

Кресты (вроде) ?

Rq - Request Ps - Post?

Не угадал, Ps - это pass

Не угадал, Ps - это pass

Я пытался

Квиз - угадай назначение класса Егора по его имени

Квиз - угадай назначение класса Егора по его имени

Чо такое Xe ?

eXtended Edition

Ох блин, сильно

Ребят, там сокращения идут от сокращения интерфейса. На самамо деле вы должны интерфесом думать, а не классом. В классе, есть отсылка к интерфесу в виде сокращения, и пояснение для непосредственного понимания что делает этот класс.

Ребят, там сокращения идут от сокращения интерфейса. На самамо деле вы должны интерфесом думать, а не классом. В классе, есть отсылка к интерфесу в виде сокращения, и пояснение для непосредственного понимания что делает этот класс.

Но из измени класса не понятно какой интерфейс реализует класс

Нужно в любом случае открывать файл и смотреть что там

Нужно в любом случае открывать файл и смотреть что там

Один раз открыв RqPage и поняв что такое Rq, второй раз открывать RqЧтототам для того чтобы понять что это реквест не придется.

Один раз открыв RqPage и поняв что такое Rq, второй раз открывать RqЧтототам для того чтобы понять что это реквест не придется.

другой такой же товарищ решит сократить Requirement => Rq. И через некоторое время мы решим, что нужно гдето вести реестр сокращений!

Один раз открыв RqPage и поняв что такое Rq, второй раз открывать RqЧтототам для того чтобы понять что это реквест не придется.

А если там другой Request? Или вообще не Request?

другой такой же товарищ решит сократить Requirement => Rq. И через некоторое время мы решим, что нужно гдето вести реестр сокращений!

Хз, может ввести Glossary абстракций в проекте не такая уж плохая идея?

другой такой же товарищ решит сократить Requirement => Rq. И через некоторое время мы решим, что нужно гдето вести реестр сокращений!

читшит

Хз, может ввести Glossary абстракций в проекте не такая уж плохая идея?

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

зачем промисы если есть события?

события не first-class значения

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

О да. Зашибись аргумент. Конечно проще искать эти абстракции размазанными в тонне говнокода. Это определенно менее провоцирует сюицид, чем список в какой нить HLD доке.

события не first-class значения

что?

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

О да. Зашибись аргумент. Конечно проще искать эти абстракции размазанными в тонне говнокода. Это определенно менее провоцирует сюицид, чем список в какой нить HLD доке.

А чо, нельзя сразу называть вещи полным названием?

Я против таких сокращений

О да. Зашибись аргумент. Конечно проще искать эти абстракции размазанными в тонне говнокода. Это определенно менее провоцирует сюицид, чем список в какой нить HLD доке.

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

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

Чо?

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

пиши await :)

что?

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

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

Событие - then, error на запрос?

Я не особо понимаю какое событие

Событие - then, error на запрос?

я тоже не совсем понимаю @artnv поясни

И промисы я видел только в джсе, хз что это ?

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

сахар не делает код трудночитаемым, трудночитаемым его делает погромист

И промисы я видел только в джсе, хз что это ?

reactphp еще

reactphp еще

Я на дарте

reactphp еще

а еще guzzle)

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

Это выше уже обсуждалось. Здесь "понятность" vs "громоздкость" - полные имена абстракций больше места занимают. И это вкусовщина.

а еще guzzle)

он ведь под капотом что-то из стека reactphp/amphp гоняет? или ошибаюсь?

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

а куда его передавать и зачем? Вот есть центральный объект Pub/Sub через него все общаются. Удобно ведь, а там коллбек в коллбеке, тот же коллбекхелл но я так понял что ради ассинхронности. Так событиями на оборот еще лучше с ассинхронностью работать и нет лапшекода, т.к. по файлам можно разбить код

он ведь под капотом что-то из стека reactphp/amphp гоняет? или ошибаюсь?

возможно, не ресерчил

Это выше уже обсуждалось. Здесь "понятность" vs "громоздкость" - полные имена абстракций больше места занимают. И это вкусовщина.

Вкусовщина только если проект ведешь ты один А если постоянно будут новые разработчики - жусть. Имхо

а куда его передавать и зачем? Вот есть центральный объект Pub/Sub через него все общаются. Удобно ведь, а там коллбек в коллбеке, тот же коллбекхелл но я так понял что ради ассинхронности. Так событиями на оборот еще лучше с ассинхронностью работать и нет лапшекода, т.к. по файлам можно разбить код

события подразумевают еще больший decoupling