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

Собсно вопрос, который часто возникает при проектировании объектной модели, и который я не до конца понимаю и который я попытался выразить в простом примере - что от чего наследовать: прямоугольник от квадрата или квадрат от прямоугольника?
1) С одной стороны логично наследовать что-то более конкретное от более общего - то есть унаследовать квадрат от прямоугольника, так как любой квадрат является прямоугольником, но не любой прямоугольник квадратом.
В этом случае для кода:

class Rectangle { }
class Square : Rectangle { }
Square obj = new Square();
print(obj is Square); // вернет True
print(obj is Rectangle); // вернет True

две последние строчки вернут значение True, что собсно верно.
2) С другой стороны, обратное более практично - для прямоугольника необходимо хранить как ширину, так и высоту, в отличии от квадрата для которого достаточно хранить информацию только для одной из сторон. Следовательно при наследовании прямоугольника от квадрата класс Square не будет хранить избыточную информацию, что может быть критично, если нам надо создавать огромный массив объектов.
Так как же все таки правильнее наследовать?

Сообщение отредактировано: bububu - 16.06.15, 11:58

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

P.S. А чё, митинг не помог, что ли?

Цитата Qraizer @ 16.06.15, 12:15

Квадрат от прямоугольника.

Наоборот Прямоугольник от квадрата. Прямоугольник - деформированный квадрат, вводим коэф. деформации - получаем прямоугольник. +k - в ширину, -k - в высоту, ну или наоборот, не суть. Главное не использовать SCRUM!

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

Что-то мне это напоминает.

Баянистая троллота. Закапываем.

korvin, а ты думаешь, тут не обсуждалось? Мне лень было искать темы. И вообще, темы для холивара тут нет ни разу. Он бы ещё спросил, нужно ли комплексные числа наследовать от вещественных или наоборот, натуральные от целых или как-нибудь иначе, налить сначала сливки в кофе и идти на перекур или наливать после перекура. От скраммера не может быть толковых тем по определению, ибо мозг заточен исключительно под поведенческие паттерны, и никакого творчества.

Сообщение отредактировано: Qraizer - 16.06.15, 16:54

Цитата Qraizer @ 16.06.15, 16:51

а ты думаешь, тут не обсуждалось?

Я к тому, что текст стартового поста один в один, т.е. автор скорее всего просто тупо троллит, а не хотя бы хочет что-то обсудить.

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

Цитата Qraizer @ 16.06.15, 14:15

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

Давай разберем по косточкам
Ну, как я понимаю, главная задача наследования - расширение либо функционала базового класса, либо его характеристик, либо и то и другое? Так, нет?

Нет. Единственная задача наследования – повторное использование чёрных ящиков с целью сохранить их черноту и создать новую.

Цитата JoeUser @ 16.06.15, 19:54

Ну, как я понимаю, главная задача наследования - расширение либо функционала базового класса, либо его характеристик, либо и то и другое? Так, нет?

Нихьт. Главная задача наследования - упростить жизнь программисту. Если оно только усложняет, то не надо наследоваться вообще. Полагаю, Qraizer говорит о том же, но с другой стороны.

Сообщение отредактировано: applegame - 16.06.15, 20:17

Хорошо. Лан. С канонической точки зрения ООП, из трех китов:

Инкапсуляция
Полиморфизм
Наследование

Кто отвечает за расширение функционала?

Добавлено 16.06.15, 20:25
Qraizer, хотя твое "нет" ... по сути "да". Создавая новые ящички ты тем самым расширяешь функционал или характеристики. Или я о5 не про то?

Цитата JoeUser @ 16.06.15, 20:22

Инкапсуляция
Полиморфизм
Наследование

Кто отвечает за расширение функционала?

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

Цитата JoeUser @ 16.06.15, 20:22

Хорошо. Лан. С канонической точки зрения ООП, из трех китов:

Инкапсуляция
Полиморфизм
Наследование

Кто отвечает за расширение функционала?

Никто.

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

Ну еще добавлю
Перегрузка функций - упрощает жизнь программисту тем, что ему не требуется придумывать и запоминать сложные имена, позволяя использовать простые, легко запоминающиеся, а компилятор сам разберётся какая именно функция имеется в виду.
Перегрузка операций - упрощает жизнь программисту тем, что он может использовать естественную запись выражений, а не городить вложенные вызовы функций/процедур.
Шаблоны - упрощают жизнь программисту тем, что позволяют один раз описать последовательность действий (функцию, метод, операцию) для типов (классов), обладающих сходными свойствами, а не переписывать её заново для каждого из них.
Что-то подобное шаблонам дают дженерики.

Сообщение отредактировано: amk - 16.06.15, 21:11