> Kerk ©   (22.05.17 19:03) [19]

Забыл уже - это где пауки за колобком бегают?

> Юрий Зотов ©   (22.05.17 19:45) [20]

https://upload.wikimedia.org/wikipedia/en/5/59/Pac-man.png

Надо в лабиринте собирать печеньки и не попадаться врагам.

Не вижу никакого особого ООП в "Пакмэне".

Ну где же вы задачки, задачки, короткие задачки??

> Юрий Зотов ©   (22.05.17 15:10) [9]
> > K-1000 ©   (22.05.17 13:02) [6]
>
> > Квадрат от Прямоугольника.
>
> Тогда у Квадрата появляется неиспользуемое поле.


У него Width = Height всего-то.

> K-1000 ©   (22.05.17 20:28) [23]

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

Знаете, как такой код называют? На букву "Г". Даже если он работает.

Юрий Зотов

> > K-1000 ©   (22.05.17 20:28) [23]Ну да, всего-то неиспользуемое
> поле. Подумаешь, лишней памяти немножко отъели, но ведь
> работает же.Знаете, как такой код называют? На букву "Г".
>  Даже если он работает.

Покажите мастер класс как вы вделываете 4
(Библиотека программиста) Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес-Приемы объектно-ориентированного проектирования. Паттерны проектирования-ДМК Пресс (2010)

Если что они советуют в родительский объект включать все методы дочерних.
Ровно как и «Принцип подстановки» Барбары Лисков.

> Pavia ©   (22.05.17 20:58) [25]

> они советуют в родительский объект включать все методы дочерних.

Вы, извините, немножко не в кассу. Поскольку между методом и полем есть некоторая разница. Это раз.

Включать в родительский класс ВСЕ методы ВСЕХ дочек - глупость. В родителя надо включать лишь общие методы - то есть те, которые есть у всех дочек. Это два.

Не сотвори себе кумира, даже если он написал книгу. Это три.

взявшись за задачу через применение ООП
и запариваться про транжир памяти на целое одно лишнее поле в предке.

это как продать цистерну спирта, а вырученные деньги пропить.
столь же логично

> K-1000 ©   (22.05.17 20:28) [22]
>
> Не вижу никакого особого ООП в "Пакмэне".

Ну нифига себе. Там куча объектов, которые по сути похожи, но ведут себя по-разному. И всё это надо уметь держать в памяти, управлять и отрисовывать. Не суперзадача конечно. Но вроде чего-то глобального и не требовалось.

Pavia ©   (22.05.17 20:58) [25]


> Если что они советуют в родительский объект включать все
> методы дочерних


Ты спутал

ООП помогает людям в писать. Всего лишь.
И не помогает процессорам выполнять (плюс множество других вещей о которых оно не заботится).

вот и все.

> Ну где же вы задачки, задачки, короткие задачки??


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

Поможешь?

> Включать в родительский класс ВСЕ методы ВСЕХ дочек - глупость.
>  В родителя надо включать лишь общие методы - то есть те,
>  которые есть у всех дочек. Это два.

Видно что не читали, но уже осуждаете. Там это описание на нескольких десятков листов почему именно и как. Я конечно преувеличил, что прям всё.
Но большинство методологов следует включить в родителя, даже если они не везде есть. Это позволит сохранить кейсы внутри вашего фремворка. Иначе это грозит тем, что эти кейсы будут вываливаться во внешние объекты.
Это в учебной задаче уровень наследования малый, а в реальной где у вас фабрика объектов сложность кейса растёт по экспоненте от уровня наследования. Поэтому и следует их помещать внутрь объектов - инкапсулировать. А не тащить наружу в другие объекты.


> Вы, извините, немножко не в кассу. Поскольку между методом
> и полем есть некоторая разница. Это раз.

Я конечно понимаю старая школа. Но сейчас цена байта очень мала по сравнению с временем программиста.


> Не сотвори себе кумира, даже если он написал книгу. Это
> три.

Математика сэр.

> Pavia ©   (22.05.17 20:58) [25]
> Если что они советуют в родительский объект включать все
> методы дочерних.

Наоборот.

> Ровно как и «Принцип подстановки» Барбары Лисков.

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

Ну да. Наоборот.

> Kerk ©   (23.05.17 00:00) [33]


> Наоборот.

Если вас могут понять не правильно, значит вас поймут неправильно. Обратите внимание на слова.
Выбор наследование или перепоручения решается заранее. Когда мы разбиваем все методы на постоянные и изменяющиеся. Для неизменных когда мы применяем наследование. Если есть наследование то есть родители и дочки, А если нет наследование то и никаких дочерей нет.

В самом простом случае мы можем использовать только, то что знаем. Почему это так?
В алгоритме функции вы обязаны указать имя метода который вы вызываете - её сигнатуру.
Можно ли сделать иначе? Можно только это уже не наследование. Хотя в книге оно и обозвано наследованием(правда в одном месте видимо ощимка?!).  Решается это через класс с шаблоном-стратегии.
В умных книжках это называется делегированием. Переведём на русский так это же попросту перепоручения!
К чему это приводит? А приводит к тому что теперь тому кому перепоручили работу приходиться разбираться, а кто-же его вызвал и с кем он должен работать! Вот от этого и растёт кейс, только теперь у нас, а у него.

Хорошо когда у вас есть шаблон-прораб. Он подтаскивает близко-родственные классы так сказать из одного села. Тогда если как в примере с графическим редактором у нас три системы чётко разделённых.  Вот тогда можно избавиться от кейсов внутри кода. Просто описав три реализации для каждой системы свою.

Только я повторюсь к наследованию это не имеет отношения.

Выбор наследование или перепоручения решается заранее. Когда мы разбиваем все методы на постоянные и изменяющиеся.

>  Pavia ©   (23.05.17 00:49) [34]

Да я как раз обратил внимание на слова:

Если что они советуют в родительский объект включать все методы дочерних.
Ровно как и «Принцип подстановки» Барбары Лисков.

Судя по [34], у меня ощущение возникает, что ты взял какой-то частный случай и невероятно широко обобщил его зачем-то.

вот задачка для ооп.

сделать скелет приложения работающего с бд.
классы форм с dbaware спроектировать так, чтобы они ничего не знали ни про конкретный сервер, ни про библиотеки доступа.
специфику реализовать в абстрактном датамодуле и его потомках.
в результате переезд приложения с ora/odac на fb/fibs (mssql/ado и т.д.) не должен затрагивать гуи и занимать пару часов.

> Выбор наследование или перепоручения решается заранее. Когда
> мы разбиваем все методы на постоянные и изменяющиеся. Для
> неизменных когда мы применяем наследование. Если есть наследование
> то есть родители и дочки, А если нет наследование то и никаких
> дочерей нет.
>
> В самом простом случае мы можем использовать только, то
> что знаем.


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

Навеяло

> в результате переезд приложения с ora/odac на fb/fibs (mssql/ado
> и т.д.) не должен затрагивать гуи и занимать пару часов.
>
ну а биндинги (лайвбиндинги) разве не про это?

ну а биндинги (лайвбиндинги) разве не про это?

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

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