Обычно наоборот, конечно. Интерфейсы плохи тем, что их расширение это breaking change. Или кто-то соверинжинирил и сейчас ещё не нужен класс и интерфейс модно убрать лишнюю сущность, оставив только класс.
А меня наоборот. Теоретически это мешает переделывать интерфейс в класс и обратно (главное роль типа в программе, а интерфейс это или класс — вторична). Практически, правда, я соблюдаю нейминг конвеншнс того места, где я оказался.
Тогда оба варианта наилучшие. Так как оба меньше слона. Но вы, наверное, имели ввиду "быть как можно меньше".
Для основной мысли моего высказывания, впрочем, это не особенно важно — я просил т хотел показать что Ви зависимости от постановки меняется дизайн и без понимания того что мы дизайном и с какой целью трудно нельзя сказать что само собой разумеется, что метод X должен быть в классе Y
В дополнение к аналоги — тут на хабре была статья про то как владельцы ТЦ проталкивают своего поставщика инета и как боятся с альтернативами включая глушилки. Там правда, за него отдельно бабки просят
Допустим нас не интересует как кошку кормят разные люди и разница в кормушках для нас несущественна. Нам нужно знать только каким кошкам надо насыпать какой корм (в зависимости от породы, например)
Если мы смоделируем разницу в кормлении разных кошек в ооп языке внутри класса человека, то нам надо будет развозить какой-то паттерн матчинг и прочее.
Куда проще завести разные классы кошек с методом "прокормить" и описывать процесс кормления там а человека и кормушку вынести за скобки. Например человека вообще не включать в модель а кормушку использовать только для хранения ёмкости.
Это как раз менее важно — как только у того, кто пишет код квадрат и прямоугольник в коде станут обладать абсолютно теми же свойствами как и квадрат и прямоугольник в голове — противоречие снимется. Главное очень четко осознавать что именно он называет квадратом а что прямоугольником.
Если человек решит, что мутабельный прямоугольник с гарантией незвисимого изменения сторон для него тождественен понятию Прямоугольник, то он как логическое существо должен не наследовать от него квадрат и в обыденной жизни считать что. Если он решит, что прямоугольник это все прямоугольное, соответственно он должен либо убрать у прямоугольника в программе все остальные требования либо переименовать прямоугольник в программе, либо считать их омонимами.
Это не программирование, это схоластика, которая присуща только ООП. Причём это буквально так. В реальном мире не существует никакого наследования.
Это все про то, как человеку удобно думать про окружающий мир. Наследование это отражение того факта, что человеку удобно делить предметы на категории и подкатегории обладают по умолчанию свойствами надкатегорий (если все собаки хвостаты, а пудели — собаки, то пудели хвостаты).
Имхо при моделировании главное, понять, какой аспект реальности мы моделируем. В аэродинамических моделях продуваемых в аэжротрубе вряд ли делают маленьких пассажиров.
Модель это какая-то штука, которая в интересующем нас разрезе ведет себя как какая-то другая штука, но в чем-то удобнее.
Для меня из этого следует, что к какому классу принадлежит метод зависит от того, что мы моделируем а что отбрасываем. Например, если мы хотим смоделировать то, как Суворов берет крепости, вполне допустим и Измаил.Взять() (так как никаких других полководцев мы не рассматриваем и алгоритм взятия крепости зависит только от нее самой).
Поэтому, желательно, при рассмотрении каких-то, примеров приводить более подробные задания — что и для чего мы делаем.
При испытании лифта человека можно смоделировать мешком аналогичного веса, но другой формы, а при показе одежды манекеном похожей формы, но другого веса.
Соответственно это немного уменьшает неопределенность — или всех возможных вариантов останется два "неспособен написать hello world и не способен написать высоконагруженную систему", "не хочет писать задания" т.е. что-то говорит о кандидате в интересующем ключе.
Мы можем, например, дать простой "hello world", дать денег за hello world чтобы снизить влияние нежелания писать задания. Ну или не хотящих писать задания по какой-то другой причине отвергать.
Это вообще-то не прямоугольник, а некоторая другая сущность, с прямоугольником связанная только формой.
Это ничего особо не изменит в дискуссии *
Вся дискуссия ведётся от противоречия между свойствами математического прямоугольника, математического квадрата и того, что было выражено на языке программирования.
Если понять что на языке программирования кто-то словом "прямоугольник" и "квадрат" назвал нечто обладающее дополнительными ограничениями по сравнению с тем что мы привыкли называть прямоугольником и квадратом в обыденной жизни, то противоречие снимется.
Например, если сказать что сиреневый квадрат не является голубым прямоугольником это не породит дополнительной дискуссии.
Если у вас в рисовалке есть
изменяемые прямоугольники и квадраты, то либо класс фигуры должен меняться от изменения параметров; либо не надо требовать чтобы квадраты были прямоугольниками; либо надо обозначить что при изменении одной стороны прямоугольника не было бы ожидания, что у прямоугольника размеры сторон независимы. (Выделить Изменяемый прямоугольник отдельно и Изменяемый прямоугольник с независимыми сторонами отдельно)
Т.е. в этом как бы парадоксе вся соль в том что от прямоугольников и квадратов требуется больше чем прямоугольность и квадратность.
Если вы в вашей предметной области называете прямоугольником не все прямоугольники, а какую-то из разновидности, это уже не будет выглядеть парадоксально: Изменяемый ВсегдаКвадрат не очевидно что должен быть разновидностью Изменяемого ВсегдаПрямоугольникаСПроизвольным соотношениемСторон. Правда тогда вы должны сделать какой-то другой прямоугольник если вы захотите найти что-то общее у всех предметов произвольной формы. Например ввести какой-то абстрактный прямоугольник.
Здесь слово "всегда" означает что он не может перестать быт квадратом (в некоторых смолтоках можно поменять класс объекта, насколько я знаю, а в языке cecil есть предикатные подклассы)
Они этим одновременно плохи и хороши.
Обычно наоборот, конечно. Интерфейсы плохи тем, что их расширение это breaking change. Или кто-то соверинжинирил и сейчас ещё не нужен класс и интерфейс модно убрать лишнюю сущность, оставив только класс.
А меня наоборот. Теоретически это мешает переделывать интерфейс в класс и обратно (главное роль типа в программе, а интерфейс это или класс — вторична). Практически, правда, я соблюдаю нейминг конвеншнс того места, где я оказался.
Кстати в мире Гарри Поттера есть машина времени временные петли. Например, там было два Гарри Поттера — один наблюдал за другим.
Я не помню наблюдалось ли там две Совы но не помню также фундаментального ограничения на этот счёт.
Синглтоны также неудобны при юнит тестировании — многопоточное тестирование не запустить и каждый раз надо аккуратно восстанавливать состояние.
Тогда оба варианта наилучшие. Так как оба меньше слона. Но вы, наверное, имели ввиду "быть как можно меньше".
Для основной мысли моего высказывания, впрочем, это не особенно важно — я просил т хотел показать что Ви зависимости от постановки меняется дизайн и без понимания того что мы дизайном и с какой целью трудно нельзя сказать что само собой разумеется, что метод X должен быть в классе Y
То что вы написали после "нет" никак не отрицает ни основной мысли комментария ни процитированного текста :D.
" — собака куда меньше слона.
В дополнение к аналоги — тут на хабре была статья про то как владельцы ТЦ проталкивают своего поставщика инета и как боятся с альтернативами включая глушилки. Там правда, за него отдельно бабки просят
Допустим нас не интересует как кошку кормят разные люди и разница в кормушках для нас несущественна. Нам нужно знать только каким кошкам надо насыпать какой корм (в зависимости от породы, например)
Если мы смоделируем разницу в кормлении разных кошек в ооп языке внутри класса человека, то нам надо будет развозить какой-то паттерн матчинг и прочее.
Куда проще завести разные классы кошек с методом "прокормить" и описывать процесс кормления там а человека и кормушку вынести за скобки. Например человека вообще не включать в модель а кормушку использовать только для хранения ёмкости.
Или сделать таблицу смещений (подобно тому как при загрузке exe в досе было)
А как вы пишете тесты на перформанс и как избегание регрессий в перформансе?
Это как раз менее важно — как только у того, кто пишет код квадрат и прямоугольник в коде станут обладать абсолютно теми же свойствами как и квадрат и прямоугольник в голове — противоречие снимется. Главное очень четко осознавать что именно он называет квадратом а что прямоугольником.
Если человек решит, что мутабельный прямоугольник с гарантией незвисимого изменения сторон для него тождественен понятию Прямоугольник, то он как логическое существо должен не наследовать от него квадрат и в обыденной жизни считать что. Если он решит, что прямоугольник это все прямоугольное, соответственно он должен либо убрать у прямоугольника в программе все остальные требования либо переименовать прямоугольник в программе, либо считать их омонимами.
Это все про то, как человеку удобно думать про окружающий мир. Наследование это отражение того факта, что человеку удобно делить предметы на категории и подкатегории обладают по умолчанию свойствами надкатегорий (если все собаки хвостаты, а пудели — собаки, то пудели хвостаты).
Имхо при моделировании главное, понять, какой аспект реальности мы моделируем. В аэродинамических моделях продуваемых в аэжротрубе вряд ли делают маленьких пассажиров.
Модель это какая-то штука, которая в интересующем нас разрезе ведет себя как какая-то другая штука, но в чем-то удобнее.
Для меня из этого следует, что к какому классу принадлежит метод зависит от того, что мы моделируем а что отбрасываем. Например, если мы хотим смоделировать то, как Суворов берет крепости, вполне допустим и Измаил.Взять() (так как никаких других полководцев мы не рассматриваем и алгоритм взятия крепости зависит только от нее самой).
Поэтому, желательно, при рассмотрении каких-то, примеров приводить более подробные задания — что и для чего мы делаем.
При испытании лифта человека можно смоделировать мешком аналогичного веса, но другой формы, а при показе одежды манекеном похожей формы, но другого веса.
Соответственно это немного уменьшает неопределенность — или всех возможных вариантов останется два "неспособен написать hello world и не способен написать высоконагруженную систему", "не хочет писать задания" т.е. что-то говорит о кандидате в интересующем ключе.
Мы можем, например, дать простой "hello world", дать денег за hello world чтобы снизить влияние нежелания писать задания. Ну или не хотящих писать задания по какой-то другой причине отвергать.
Я про это:
Вся дискуссия ведётся от противоречия между свойствами математического прямоугольника, математического квадрата и того, что было выражено на языке программирования.
Если понять что на языке программирования кто-то словом "прямоугольник" и "квадрат" назвал нечто обладающее дополнительными ограничениями по сравнению с тем что мы привыкли называть прямоугольником и квадратом в обыденной жизни, то противоречие снимется.
Например, если сказать что сиреневый квадрат не является голубым прямоугольником это не породит дополнительной дискуссии.
Если у вас в рисовалке есть
изменяемые прямоугольники и квадраты, то либо класс фигуры должен меняться от изменения параметров; либо не надо требовать чтобы квадраты были прямоугольниками; либо надо обозначить что при изменении одной стороны прямоугольника не было бы ожидания, что у прямоугольника размеры сторон независимы. (Выделить Изменяемый прямоугольник отдельно и Изменяемый прямоугольник с независимыми сторонами отдельно)
Т.е. в этом как бы парадоксе вся соль в том что от прямоугольников и квадратов требуется больше чем прямоугольность и квадратность.
Если вы в вашей предметной области называете прямоугольником не все прямоугольники, а какую-то из разновидности, это уже не будет выглядеть парадоксально: Изменяемый ВсегдаКвадрат не очевидно что должен быть разновидностью Изменяемого ВсегдаПрямоугольникаСПроизвольным соотношениемСторон. Правда тогда вы должны сделать какой-то другой прямоугольник если вы захотите найти что-то общее у всех предметов произвольной формы. Например ввести какой-то абстрактный прямоугольник.
Правильно я понимаю, что тот кто не способен написать "привет мир" способен написать хайлоад систему?
Это вы в чате делаете или в устном общении но с отвращением?
Пригнали
Когда говорят "дискриминация" часто имеют ввиду "негативную дискриминацию" а есть еще "позитивная"