но я кажется понял о чем ты, ты про то что у нас есть поведение объекта "сейчас" и оно может в какой-то момент времени не соответстовать тому что надо.

Чот вы хрень какую-то обсуждаете.

Чот вы хрень какую-то обсуждаете.

действительно, надо обсуждать как контроллеры клепать

пришли к тому что наследование между классами не нужно?

опять

оставляем наследование между интерфейсами

Оно строится на основе требуемого. Наверное.

Должно строиться. А по факту как повезет :)

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

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

потому что наследование это сильная связь, а связанные вещи нам не нужны

Особенно сильно.

а когда два класса из разных модулей наследуются => они (классы) связаны => модули этих классов тоже связаны

Парни кстати про дядю боба я ен понял

Быстрая разработка программ. Принципы, примеры, практика. — Вильямс, 2004

Принципы, паттерны и методики гибкой разработки на языке C#. — Символ-Плюс, 2011.

это просто разные издания одной книги что ли?

Дядя боба на тему квадратов

https://youtu.be/TMuno5RZNeE?t=1h17m10s

da horsie как раз то о чем ты говоришь

и пример с адвакатами там же

da horsie как раз то о чем ты говоришь

Так я как раз про это (и другие похожие) видео говорю

Кто может нормально объяснить почему квадрат нельзя от прямоугольника наследовать? Стандартные объяснения знаю, но они меня не убеждают ни капли. Ну или объясните почему этот пример как пример дают )

Потому что ты нарушаешь "принцип" is A т.е. является. Обычная логика: является ли квадрат прямоугольником? нет! Является ли квадрат фигурой? да! Значит нужно наследоваться от абстрактной фигуры, а не от реализации.Нельзя наследоваться от него, только для того чтобы получить какое то уже готовое поведение и реализацию. Это ломает инкапсуляцию обьекта, получается обьект который в определённые моменты будет работать правильно, но иногда может ломаться. Так же если в предке, прямоугольнике были какие либо методы которые не нужны квадрату, но они в нём присутствуют. т.к. при прямом наследовании нет возможности от них отказаться. А что будет если за них дёрнуть? Это сломает предпологаемое поведение квадрата.

пример из реальной жизни: стек является вектором? нет. Так почему стек наследован от вектора? https://docs.oracle.com/javase/8/docs/api/java/util/Stack.html

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

Потому что ты нарушаешь "принцип" is A т.е. является. Обычная логика: является ли квадрат прямоугольником? нет! Является ли квадрат фигурой? да! Значит нужно наследоваться от абстрактной фигуры, а не от реализации.Нельзя наследоваться от него, только для того чтобы получить какое то уже готовое поведение и реализацию. Это ломает инкапсуляцию обьекта, получается обьект который в определённые моменты будет работать правильно, но иногда может ломаться. Так же если в предке, прямоугольнике были какие либо методы которые не нужны квадрату, но они в нём присутствуют. т.к. при прямом наследовании нет возможности от них отказаться. А что будет если за них дёрнуть? Это сломает предпологаемое поведение квадрата.

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

https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html Здесь то же самое, класс Properties который по задумке позволяет работать только с парами String String унаследован от Хештаблицы которая позволяет сетить в себя любые обьекты, допустим я создаю Пропертис, насетю туда любых обьектов и буду читать оттуда String? что будет? Properties не позволит мне этого делать только в том случае если он НЕ БУДЕТ hashTable который может принимать любой обьект. Т.к. в текущей ситуации этот принцип нарушен и мне как клиенту этого класса доступны методы как хештаблицы так и пропертис.

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

как раз так думали те кто писал некоторые классы jdk 1.0

пример из реальной жизни: стек является вектором? нет. Так почему стек наследован от вектора? https://docs.oracle.com/javase/8/docs/api/java/util/Stack.html

Вопросы у дизайну жавы есть со всех сторон

К тому, что это все нереально декорировать даже вопросов нет)

Вопросы у дизайну жавы есть со всех сторон

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

Вопросы у дизайну жавы есть со всех сторон

Это уже понове намного почти тот же jdk (javafx) https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/ListView.html

ListView constructor is not feasible, the recommended approach for setting the items is to simply call: ObservableList<T> content = ... listView.setItems(content); The end result of this is, as noted above, that the ListView will automatically refresh the view to represent the items in the list. Another approach, whilst accepted by the ListView, is not the recommended approach: List<T> content = ... getItems().setAll(content); The issue with the approach shown above is that the content list is being copied into the items list - meaning that subsequent changes to the content list are not observed, and will not be reflected visually within the ListView.

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

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

Что самое интересное что в TableView есть метод с такой же самой сигнатурой но там всё наоборот, этот метод setItems() не обновляет визуальное состояние TableView, нужно наоборот держать ссылку на ObservableList снаружи и уже через манипуляции с этим листом изменять отображение TableView

Firstly, a TableView instance needs to be defined, as such: TableView<Person> table = new TableView<Person?); With the basic table defined, we next focus on the data model. As mentioned, for this example, we'll be using a ObservableList. We can immediately set such a list directly in to the TableView, as such: ObservableList<Person> teamMembers = getTeamMembers(); table.setItems(teamMembers);

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

Да потому что стек это АТД и описывать его надо интерфейсом, а не классом.

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

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

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

Квадрат имеет те же свойства что и прямоугольник (+ ряд своих) но квадрат не являеться прямоугольником и наоборот

Квадрат имеет те же свойства что и прямоугольник (+ ряд своих) но квадрат не являеться прямоугольником и наоборот

"Квадрат не является прямоугольником" - это как минимум контринтуитивно.

Квадрат имеет те же свойства что и прямоугольник (+ ряд своих) но квадрат не являеться прямоугольником и наоборот

квадрат является прямоугольником?

по определению

p.s. чет зацепила всех эта тема

> Квадра́т — правильный четырёхугольник (c) википедия

Сам себе противоречишь.

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

Сам себе противоречишь.

может ты?)

Стока флейма из ничего) Тут же все очевидно. Квадрат и прямоугольник - два разных класса. Возможно даже они имплементят один интерфейс IПрямоугольный. Можно реализовать приведение типов Квадрат -> Прямоугольник. Можно и наоборот Прямоугольник -> Квадрат, но нужно понимать что такое преобразование возможно только в отдельных случаях (при a = b), а в остальных будет вываливаться исключение

может ты?)

Еще раз я сказал что квадрат не являеться прямоугольником и наобором (прямоугольник не квадрат)

Поэтому и наследоватся нельзя

квадрат является прямоугольником?

А еще ромбом

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

про параллелограмм забыли

Он тут не причем

Наркоманы. Хватит уже :)

Проблема здешних обувателей же в другом: они яро уверовали, что отношение "is-a" имплементится исключительно наследованием (данных)

Проблема здешних обувателей же в другом: они яро уверовали, что отношение "is-a" имплементится исключительно наследованием (данных)

да это мы еще вчера обсудили)

Ну ок

и да, проблема именно в том что ты сказал)

что наследование не воспринимается как вид зависимости, а если это просто вид зависимости то вместо подтипов можно делать просто отдельные типы вложенные в другой. Что generalization воспринимается как "is a"

@mkusher ты читал "Designing Data-Intensive Applications"?

что наследование не воспринимается как вид зависимости, а если это просто вид зависимости то вместо подтипов можно делать просто отдельные типы вложенные в другой. Что generalization воспринимается как "is a"

Ну а во что ты вложешь квадрат: в прямоугольник или ромб?

Ну а во что ты вложешь квадрат: в прямоугольник или ромб?

ни во что, конкретно в этом примере вкладывать смысла нет

Есть два стула...

ERROR: S client not available

Да стул один

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

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

но у них же разные интерфейсы

у квадрата и ромба setSize а у прямоугольника setWidth и setHeight

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

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

ну то есть да, если такое не требуется - то норм

а различия делать отдельными типами

Он не может требовать что изменять

Он не может требовать что изменять

в смысле?

он декларирует поведение

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

Он не может требовать что изменять

Вообще да, но в данном случае вопрос именно про независимость измерний

Это не поведение прямоугольника. Интерфейс прямоугольника и вообще может быть пустым

Это не поведение прямоугольника. Интерфейс прямоугольника и вообще может быть пустым

Дада, все верно. Но исходная задача не про то

Ну, все-таки не интерфейс, а типаж, давайте уже нормально и изъясняться

Не типаж, а поведение

Нет

Поведение вообще странное слово и к теории типов отношения не имеет

давай типажи)

Конечно, если вы запихнули change_size (w, h) в прямоугольник, то квадрат им уже не будет (а отличие от отдельных set_width и set_height)

Конечно, если вы запихнули change_size (w, h) в прямоугольник, то квадрат им уже не будет (а отличие от отдельных set_width и set_height)

Исходная задача именно с такими условиями

Ну, во-первых, нет size, есть отдельно понятие высоты и ширины

А, во-вторых, что значит изменить их?

Это ведь другой прямоугольник становится

Ну, во-первых, нет size, есть отдельно понятие высоты и ширины

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

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

Ты можешь говорить о высоте квадрата, если введена ось

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

Это ведь другой прямоугольник становится

Но я все равно настаиваю на этом

Но я все равно настаиваю на этом

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

это же не решает проблему

Ты не меняешь, там просто нет методов для изменения

ну понятно