На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (2) 1 [2]  все  ( Перейти к последнему сообщению )  
> Что от чего наследовать квадрат от прямоугольника или прямоугольник от квадрата?
    Цитата applegame @
    не обязательно

    Это очень замечательно! Хороший термин. Хуже было бы если бы было "никогда" ;)

    А теперь давайте рассмотрим две стратегии понятия "построение".

    В нашем случае есть две стратегии:

    1) От меньшего - к большему. Аналог - построение здания из стройматериалов.
    2) От большего - к меньшему. Аналог - работа скульптора с камнем.

    От равного к равному не рассматриваем (типа работа химика или металлурга), ибо, в случае С++, нет функционала замены полей класса при наследовании. Типа в базовом было поле int A, а в наследуемом оно стало Double.

    Пока рассуждения верны?

    Добавлено
    Цитата amk @
    Никто.

    А кто может?

    Добавлено
    amk, кстати хорошо, лаконично все описал! :good: Хоть в учебник публикуй! ))) Еще бы описал виртуальное наследование для полноты ... было бы ваще супер.
    Сообщение отредактировано: JoeUser -
      Цитата Qraizer @
      Однако он иногда выходит мне в ПМ, ...и это вызывает сочувствие к его IQ

      А в чем смысл этих тем он объяснил? Мне кажется, что тут связка бот + человек. Ну не может сам человек плодить столь бессмысленные темы и причем всегда одинаковые.
        Цитата JoeUser @
        Или я о5 не про то?
        Про это, но не с той стороны. Я уж начал в голове повесть сочинять, но вот applegame сказал гораздо талантливее:
        Цитата applegame @
        Наследование - не обязательно расширяет функционал, а расширение функционала - не обязательно наследование. Это ортогональные понятия.
          Qraizer, с этим разобрались. Идем дашьше. ;)
            shm, я тоже так думал. Но вот иногда попадаются коты, которым от нечего делать лизать либо нечего, либо не дотянуться. К чужим вот тянутся.

            Добавлено
            Цитата JoeUser @
            Еще бы описал виртуальное наследование для полноты ... было бы ваще супер.
            Лиххко. При наследовании нескольких одинаковых атрибутов требуется решить, следует ли в контексте расширенного функционала рассматривать их как одинаковые или же как разные. К примеру, у окна, поделённого на фреймы, может быть только один атрибут "функция обработки сигналов". А может быть и по одной на каждый фрейм. Это вопрос не программирования, а архитектуры. Как решит проектный менеджер, так и сделает программист (пусть даже это одно лицо). Когда архитектор принимает решение о разделении атрибутов, программист просто использует наследование и не парится, а вот если он решит совместить, тогда программист запарывается на виртуальном наследовании.
            Сообщение отредактировано: Qraizer -
              Qraizer, если честно, положа лапу на сердце - вопрос был задан по прочтении этой статьи. Задумался, а нужен ли такой гемор, стОит ли овчинка выделки.
                И чего все зациклились на квадрате и прямоугольнике? Ведь еще есть ромб и параллелограмм. Которые, вообще-то, частные случаи трапеции. И все это - четырехугольники, частные случаи многоугольников, то есть разновидности замкнутых кривых на плоскости, являющихся множествами точек. Если рассматривать проблему, то в полном объеме!
                  JoeUser, как только я внутри там, почти в самом начале, увидел вектор указателей, читать сразу расхотелось. Но я-таки прочту, позже.
                  Ну а вообще никто не говорит, что задачи, сводящиеся к множественному наследованию реализаций, просты.
                    Начал читать, и снова захотелось бросить, т.к. буквально сразу после кода с вектором указателей наткнулся на банальнейший ляп проектирования: там и речи не идёт о наследовать реализации, задача описана в терминах реализации интерфейсов, и это совершенно другая задача. Если же для JustVisiblePlusUpdate хочется использовать уже готовые, ранее реализованные интерфейсы Renderable и Updatable, то дерево должно быть другим.
                    В общем, парень хорошо продемонстрировал мой тезис из прошлого поста. Правильная архитектура на первом месте.
                      Да у них там ООП головного мозга случился. Неуемное желание создать сложную иерархию ради сложной иерархии. После идиотского мозготраха, они объявили виртуальное наследование богомерзким и переделали дерево.
                        Цитата Qraizer @
                        Правильная архитектура на первом месте.


                        Именно. И принцип KISS ... Кстати, вот по нему то и ражачная статейка.

                        А по поводу вопросов топика провокатора :) ТС - я бы отталкивался при наследовании фигур именно от количества необходимых величин-описателей. От меньшего к большему, типа:

                        1) квадрат, окружность, треугольник-равносторонний ... - 1 измерение (половину высоты или радиус)
                        2) прямоугольник, эллипс, треугольник-равнобедренный ... - 1 измерение + 1 деформация
                        3) параллелограмм, яйцеобразная форма, треугольник-произвольный ... - 1 измерение + 2 деформации

                        А может вааще сперва изменить систему координат на какую нить эллиптическую ;)
                            В природной естественной среде объект принадлежит сразу нескольким классам.

                            На вопрос по прошу не отвлекаться.
                            user posted image

                            Так вот один и тот же предмет можно классифицировать по форме, по цвету, по наличию каёмки и тп. Ещё разные классы могу перекрываться.

                            user posted image

                            Отсюда проявляется проблема классификации.

                            Наиболее простой вид классификации. Это когда один класс целиком входи в другой.
                            user posted image
                            user posted image

                            Наследование с сужением функционала лучше всего работает.
                            Можно заменять реализацию функционала. Но интерфейс будет остаться.
                            А вот наоборот не работает или работает плохо. Так как нельзя вызвать из предка неизвестный функционал потомка. Поэтому предок должен содержать все методы потомков.


                            Но есть и второй способ наследования через перепоручение (Deligate). Что частично решает проблему множественного наследования.

                            В этом случае проблемы перекладываются с интереса на функции где надо обрабатывать через ветвления все варианты работы. Т.е использовать Case.
                            Предок не обязан знать о потомке. И проблему можно решить через внедрение или хук функции.
                            Что усложняет написания кода.


                            При работе с ООП есть методика сокрытия информации. Когда работаешь с объектами она учит программистов пользоваться объектами используя интуиции. Но вот когда встаёт задача проектировать класс то тут уже надо пользоваться другим подходом. А именно абстрагирование. Суть абстрогирование это изучение существующих классов и выбор того набора методов который наилучшим способом описывает все имеющиеся объекты и их реализации данного класса.Другими словами наиболее популярные методы. Для этого надо рассмотреть все классы и возможные реализации.

                            Вот как это делают на примере касса окна в книге 4-тырёх:
                            Цитата
                            Класс Window должен покрывать функциональность окон, которая имеется
                            в различных оконных системах. Рассмотрим два крайних подхода:
                            - пересечение функциональности. Интерфейс класса Window предоставляет
                            только операции, общие для всех оконных систем. Однако в результате мы
                            получаем интерфейс не богаче, чем в самой слабой из рассматриваемых
                            систем. Мы не можем воспользоваться более развитыми средствами, даже если
                            их поддерживает большинство оконных систем (но не все);
                            - объединение функциональности. Создается интерфейс, который включает
                            возможности всех существующих систем. Здесь нас подстерегает опасность
                            получить чрезмерно громоздкий и внутренне не согласованный интерфейс.
                            Кроме того, нам придется изменять его (а вместе с ним и Lexi) всякий раз,
                            как только производитель переработает интерфейс своей оконной системы.
                            Ни то, ни другое решение «в чистом виде» не годятся, поэтому мы выберем
                            компромиссное. Класс Window будет предоставлять удобный интерфейс,
                            поддерживающий наиболее популярные возможности оконных систем. Поскольку
                            редактор Lexi будет работать с классом Window напрямую, этот класс должен
                            поддерживать и сущности, о которых Lexi известно, то есть глифы. Это означает, что
                            интерфейс класса Window должен включать базовый набор графических
                            операций, позволяющий глифам отображать себя в окне. В табл. 2.3 перечислены
                            некоторые операции из интерфейса класса Window.


                            Для прямоугольника и квадрата. Надо смотреть для чего нужно объединять эти два объекта в класс/классы возможно их и не надо объединять вовсе.
                            Но если нужно, то Я бы использовал 3-тий вид наследования. Через множественное наследование интерфейсов. С одной стороны это будет объединение, но с другой стороны и разделения на интерфейсы.
                              Цитата Pavia @
                              На вопрос по прошу не отвлекаться.
                              А я всё-таки отвлекусь
                              Лишняя фигура - первая. Она единственная, которая не имеет признака, отличающего её от остальных четырёх
                              0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                              0 пользователей:


                              Рейтинг@Mail.ru
                              [ Script execution time: 0,0464 ]   [ 15 queries used ]   [ Generated: 28.03.24, 12:08 GMT ]