Извините, более подходящего раздела не увидел.

Ответ на вопрос ЗНАЮ. Знающие ответ пусть помолчат, а новички попробуют на него ответить.

Дано: нужно реализовать два класса Square(квадрат) и Rectangle(прямоугольник). Понятно, что они очень похожи. Какой класс следует унаследовать от другого(или не нужно наследовать вообще   ) ? 

DeadSoul, тут от одного флейма очухаться не успели, а ты новый затеваешь? 
Ignat, убери тему от греха подальше!  

Void, не понял. При чем тут флейм? К тематике сайта вопрос имеет совсем прямое отношение

И вопрос на самом деле очень хороший. 

DeadSoul, я вот эту тему имею в виду. Если здесь начнется продолжение, увольте. 

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

то, что квадрат является прямоугольником в геометрическом смысле, ещё не значит, что он будет являться ним в той модели, которая будет описана в программе
причина простая - в программе объекты могут меняться, в геометрии и математике вообще величины не меняются
с другой стороны, в большинстве популярных языков, мягко говоря, не принято, чтобы объект менял свой класс

вот и получается, что объект прямоугольник, скорее всего будет иметь методы SetWidth и SetHeight
если квадрат наследовать от прямоугольника, то наличие в нём этих методов будет некорректным (по крайней мере, мне так кажется) - функции, получающие на вход прямоугольник вправе ожидать, что они могут сделать соотношение сторон любым

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

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


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

Добавлено @ 00:39 
например, Майерс (если не ошибаюсь) вообще не советует наследовать что-либо от конкретных классов
часто более удобно выделить то общее, что мы в них видим, в абстрактный класс и наследовать от него... 

...

Это сообщение отредактировал(а) Quadr0 - 15.7.2011, 11:15

А ещё можно сделать шаблон Quad и вводить зависимости между сторонами стратегиями. К примеру:
quad<figures::rectangle> rect;
quad<figures::square> sq;
quad<figures::rhombus> rh;

Где классы figures:: обозначают геометрические правила для сторон.
А ещё можно создать класс polygon и определять там количество вершин и опять-же, зависимости.
polygon<4, figures::square> sq;

Я даже могу предположить проверку совместимости кол-ва сторон с выбранной моделью, используя шаблоны можно такого понатворить!
И хотя это не ООП а АОП и в реальном проекте я вряд-ли такое буду практиковать, теоретически выглядит гламурно   

Либо вообще не определять квадрат (а зачем?), либо определить классы Квадрат и Прямоугольник производными от Четырёхугольника и предоставить в Квадрате метод ToRectangle(), либо попытаться реализовать вариант, предложенный Чипсетом. 

Опять - двадцать пять?   Я так понимаю, в этих войнах погибнут только самые зелёные, а бывалые зачинщики только посмеиваться будут... 
В самом деле, у квадрата лучше реализовать свойство "размер", который будет хранить в единственном экземпляре расстояние между двумя связанными вершинами, а прямоугольник уже наследовать от параллелограмма... Впрочем, что общего у квадрата и прямоугольника? Прямой угол между сторонами каждого угла? Так изменение параметров отличается.. Зачем наследовать одно от другого? 
О! Квадрат - от ромба, а прямоугольник - от паралелограмма, все они - от четырёхугольника, который просто хранит положение вершин и производит масштабирование(без нарушения пропорций). 
Т.е.:


                                     /---------- ромб --------------- квадрат
--- четырёхугольник---|
                                     \______ параллелограмм ---------- прямоугольник

 

skyboy, к вашему сведению Ромб --- это параллелограмм 

И что? Это не значит, что наследоваться имеет смысл. 

maxim1000 ответил на вопрос правильно. Тут наследовать одщно от другого нельзя. Аналогично нельзя наследовать и все предложенные выше классы.

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

2. Почему нельзя наследовать квадрат от прямоугольника:

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

Наилучший выход - реализация квадрата через прямоугольник, используя делегирование 

Учитывая, что LSP нарушается в данном примере только при наличии изменяющих объект операций, нельзя ли вместо делегирования обойтись такой иерархией?

ImmutableRectangle
Rectangle : ImmutableRectangle
ImmutableSquare : ImmutableRectangle
Square : ImmutableSquare

Несколько надуманно с практической точки зрения, но, с другой стороны, необходимость выделять квадрат в отдельный класс тоже совсем не очевидна. Хотя сам пример (равно как и круг/эллипс, действительное/комплексное число и т.д.) — превосходен. 

Это сообщение отредактировал(а) Void - 20.5.2006, 01:26

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


не в курсе, что такое делегирование... типа наследования  реализации (private в C++)?
тогда не всегда стоит - квадрату нужно меньше данных для описания, чем прямоугольнику, так что получится неоправданая трата времени
но "не стоит" здесь значит, что путь неоптимальный с точки зрения ресурсов, и при их нехватке лучше так не делать...


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

Честно говоря, я бы не наследовал ничего вообще. ООП это хорошо, но читабельность тоже рулит и если придется поступится ООПом то я положу его на алтарь читабельности без малейшего промедления.