если решение принимает ктото третий то это считай менеджер

Хороший пример — это как в играх происходит определение столкновения двух объектов.

Это не делает ни один из объектов.

потому что там процедуры выполняющиеся на GPU?)

если решение принимает ктото третий то это считай менеджер

Называйте, как хотите, это ваше право.

да, я просто не знаю как это еще называют)

ну короч менеджеры - это не ооп

не, это неверно

Аргументы?

что есть ООП тогда?

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

Это распространенная ошибка. А потом будут два класса с обязанностями 20.

что есть ООП тогда?

message passing, late binding. Аналогия - распределенная система компов. Каждый обладает своей изолированной памятью и хранит данные. Они могут обмениваться сообщениями по сети.

Это распространенная ошибка. А потом будут два класса с обязанностями 20.

ну на данный момент обязанность строго одна и все хорошо. А распространенная ошибка - отсутствие фазы рефакторинга после малейших изменений. 20 минут покодил, 5 минут приберись.

и именно на этом этапе надо применять SOLID-ы и граспы, апфронт не выйдет

а все эти DnsResolver-ы, UserManager-ы это уже симптомы нарушения тех самых "зон ответственности".

ну на данный момент обязанность строго одна и все хорошо. А распространенная ошибка - отсутствие фазы рефакторинга после малейших изменений. 20 минут покодил, 5 минут приберись.

Насчет ошибки — одно другому не противоречит. А обязанности уже две: фигура и знание о двери.

может потому что ей нужно знать о двери

Насчет ошибки — одно другому не противоречит. А обязанности уже две: фигура и знание о двери.

ну в моем примере неудачно - фигура должна знать только о размерах. Это можно введением доп интерфейса разрулить если очень хочется. Ну и в контексте нашей задачи дверь ничего не знает о фигурах и у нас все хорошо с точки зрения принципа "стабильных зависимостей"

Тогда это нечто большее, чем просто фигура.

это знание в любом случае гдето должно быть

ща нам лекцию про декомпозицию зальют. внимательно

Вы можете описать класс "фигура, знающая о двери" тогда это будет справедливо и правильно.

Тогда это нечто большее, чем просто фигура.

типичная ошибка - соблюдает объект принцип единой ответственности или нет можно определить ТОЛЬКО зная контекст. В данном контексте фигура должна знать о двери ибо кроме как узнать влазит или нет нам ничего не требуется

и нам не нужно отражать это в названии фигуры

вощем, жидная тема. но чтото тут есть. я подумаю над этим. а пока что жрать.

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

Тогда вы сами себя обманываете. Называете фигурой то, что ей не является. Для упрощения. Отсюда появляются обманутые ожидания ваших колег. Они-то не ожидают, что фигура знает про дверь.

Тогда вы сами себя обманываете. Называете фигурой то, что ей не является. Для упрощения. Отсюда появляются обманутые ожидания ваших колег. Они-то не ожидают, что фигура знает про дверь.

должен ли "заказ" знать о "комментарии"?

должен ли "банкомат" знать о "деньгах"?

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

можно сделать по другому

Да и да, это их составляющие, как комплексных объектов.

Дверь не есть частью фигуры.

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

Очень желательно :)

Да и да, это их составляющие, как комплексных объектов.

деньги не являются составной частью банкомата. Это лишь зависимость, они существуют вполне себе отдельно

Дверь не есть частью фигуры.

ей и не надо, это зависимость фигуры для выполнения поведения.

Они существуют, да. Одно другому не мешает.

Колесо тоже отдельно может существовать. Но это и часть машины.

Колесо тоже отдельно может существовать. Но это и часть машины.

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

и тут вопрос в жизненном цикле

более того, "представляют объекты реального мира" != "действуют как таковые"

мне надо поведение от объектов и больше ничего

так как реализовать shape.isFitInto(door) если shape и door - объекты? кто должен "раскрыть" свои параметры?

консенсуса нет. делай как считай нужным;)

shape.isFitInto(width, height)

так как реализовать shape.isFitInto(door) если shape и door - объекты? кто должен "раскрыть" свои параметры?

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

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

и удобно тестить

а когда появляются двери разной формы - вот тогда веселье

тогда нужно знать о каждой возможной форме

хотя в этом плане даже проще - у тебя дверь тоже формой становится

тогда нужно знать о каждой возможной форме

кому?

двери?

ей нужен только интерфейс

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

отл сценарий к фильму-катастрофе

House::shapeFitIntoDoor(shape, door) и хватит мучаться. Нате вам другой боли

Где, по вашему мнению, лучше всего объясняется MVVM (c#)?

Это ни задача фигуры, ни задача двери — решить, поместится ли фигура в дверь.

Сигнатура может быть такая: isFitIn(ShapeInterface shape): bool

Тогда можно любую фигуру передать)

Сигнатура может быть такая: isFitIn(ShapeInterface shape): bool

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

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

Тогда можно любую фигуру передать)

Фигура тогда все равно знает про взаимодействие с другой фигурой. Что не есть в ее природе.

Это сейчас чтоб понятно было, что это интерфейс, а не реализация :)

Это сейчас чтоб понятно было, что это интерфейс, а не реализация :)

ню лядно

Фигура тогда все равно знает про взаимодействие с другой фигурой. Что не есть в ее природе.

Задачки там всякие на вписанные окружности ?

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

Иначе будет конфликт именования между классом и интерфейсом часто.

Иначе будет конфликт именования между классом и интерфейсом часто.

если у тебя идет конфликт такой - значит что-то пошло не так

ERROR: S client not available

вот есть у тебя интерфейс Shape и какой тут может быть конфликт?

у тебя там дальше "конкретные" формы пойдут

Абстрактный класс Shape

Абстрактный класс Shape

а зачем он тебе?)

конкретно в нашем примере он не нужен

вводить его просто так - бредовая затея

ну и назови его если хочешь AbstractShape

Мы о нашем примере или вообще про интерфейсы?

Мы о нашем примере или вообще про интерфейсы?

вообще про суфиксы/префиксы

ну и назови его если хочешь AbstractShape

:)

Почему тогда здесь вводить префикс?

просто как по мне когда идет конфликт именования класса и интерфейса то кто-то там лишний либо класс надо переименовать

Почему тогда здесь вводить префикс?

потому что я не знаю зачем нам абстрактный класс и чем он абстрактный

когда узнаю - переименую во что-то нормальное

Ну, ладно, это все на вкус и цвет. Мне нравится psr, он адекватен. Твое дело называть все, как хочешь.

Ну, ладно, это все на вкус и цвет. Мне нравится psr, он адекватен. Твое дело называть все, как хочешь.

мне нравится здравый смысл

Ок, только не навязывай

Ок, только не навязывай

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

чаще всего ответ "прост"

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

Ок, суффикс Interface и префикс Abstract существует для избежания конфликтов и унификации нейминга. Если вводить суффикс только по-необходимости, получится несогласованность в названиях. Поэтому приняли такое соглашение в psr. Это я называю здравым смыслом.

CustomerInterface и Customer — пример из жизни.

о

не улавливаю про конфликты

да вам бы на ринг по хоже)

уходил, вы чет трете, пришел, все вы же

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

CustomerInterface и Customer — пример из жизни.

а интерфейс зачем тогда? если судя по названию реализация всегда одна

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

Почему? надо всегда минимум две реализации делать?

Почему? надо всегда минимум две реализации делать?

я ж “и” не просто так написал

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

Почему? надо всегда минимум две реализации делать?

а зачем тебе интерфейс?)