G>Вообще-то нет Есть длины сторон. Квадрат задается одной такой длиной. Прямоугольник двумя... Но, походу, не суть.

class S
{
 int side_;
 virtual int Width
 {
  get
  {
   return side_;
  }
 }
 virtual int Height
 {
  get
  {
   return Width;
  }
 }
}

class R:S
{
 int height_;
 int width_;
 override int Width
 {
  get
  {
   return width__;
  }
 }
 override int Height
 {
  get
  {
   return height_;
  }
 }
}

    class S
    {
        private int _size;
        public virtual int Size
        {
            get
            {
                return _size;
            }
            set
            {
                _size = value;
            }
        }
    }

    class R : S
    {
        private int _size;
        
        public int Height
        {
            get
            {
                return base.Size;
            }
            set
            {
                base.Size = value;
            }
        }

        public int Width
        {
            get
            {
                return this._size;
            }
            set
            {
                this._size = value;
            }
        }

        public override int Size
        {
            get
            {
                return base.Size;
            }
            set
            {
                base.Size = value;
                this._size = value;
            }
        }
    }

public interface IRectangle
{
    int Width
    {get;}
    
    int Height
    {get;}
}

public class Rectangle : IRectangle
{
    private int _width;
    private int _height;
    
    public int Width
    {
        get { return _width; }
    }
    
    public int Height
    {
        get { return _height; }
    }
}

public class Square : IRectangle
{
    private int _size;
    
    public int Size
    {
        get { return _size; }
    }
    
    int IRectangle.Width
    {
        get { return Size; }
    }
    
    int IRectangle.Height
    {
        get { return Size; }
    }
}

ПК>> А теперь давай добавим в IRectangle модификацию...

void SetDimensions( IRectangle rectangle, int width, int height )
{
  rectangle.SetWidth( width );
  rectangle.SetHeight( height );

  assert( rectangle.Width() == width );
  assert( rectangle.Height() == height );
}

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

G> Угу... и что, у прямоугольника стороны обязаны быть не равны?!

figure.SetHeight( 5 );
figure.SetLehgth( 10 );
value = figure.GetHeight() / ( figure.GetLength() - figure.GetHeight() ); // деление на ноль в случае квадрата

size = figure.GetSquareSize();

G>Вообще говоря, основной вопрос в задаче — почему

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

G>>Так что, ИМХО, вариант S<-R, в общем случае, ППЛ не нарушает... в отличие от варианта R<-S.

G>size = figure.GetSquareSize();
G>

class S
{
 virtual int Size
 {
  get{return _size;}
  set{_size = value;}
 }
 
 virtual int Area
 {
  return (_size * _size);
 }
}

class R: S
{
 int Height
 {
  get{return base.Size;}
  set{base.Size = value;}
 }
 
 int Width
 {
  get{retunr _width;}
  set{_width = value;}
 }

 override int Size
 {
  //Может быть перекрыт как угодно... напримет так.
  get
  {
   _width = base.Size;
   return base.Size;
  }
  set
  {
   _width = base.Size = value;
  }
 } 

 override int Area
 {
  return base.Size * _width;
 }
}

G>>Вообще говоря, основной вопрос в задаче — почему

G>Ну да, а я о чем по вашему говорю?

G>class S
G>{
G> virtual int Size
G> {
G>  get{return _size;}
G>  set{_size = value;}
G> }
 
G> virtual int Area
G> {
G>  return (_size * _size);
G> }
G>}

G>class R: S
G>{
G> int Height
G> {
G>  get{return base.Size;}
G>  set{base.Size = value;}
G> }
 
G> int Width
G> {
G>  get{retunr _width;}
G>  set{_width = value;}
G> }

G> override int Size
G> {
G>  //Может быть перекрыт как угодно... напримет так.
G>  get
G>  {
G>   _width = base.Size;
G>   return base.Size;
G>  }
G>  set
G>  {
G>   _width = base.Size = value;
G>  }
G> } 

G> override int Area
G> {
G>  return base.Size * _width;
G> }
G>}
G>

int a1 = figure.Area();
int tmp = figure.Size();
if( a1 != figure.Area() )
   crash_system();

G>> А смысл, если Вы до сих пор при виде варианта S<-R "тыкаете" в п.1.

G>Смысл? Для вас смысл очень простой — если вы так уверены в себе, то я предлагаю вам на мне заработать. Ставлю, скажем, 50 баксов. Вы даете очередную реализацию — я пишу программу, которая ведет себя по разному для прямоугольника и квадрата. У меня получается — вы переводите мне 50 долларов. Почтовым переводом. Не получается — это делаю я. Выбираем арбитра — я предлагаю Синклера. Ну что, deal?

Второй момент — бессмысленно, имхо, рассуждать вообще о любом агрегате... Но, для варианта S<-R можно утверждать, что для для любого агрегата A, агригирующего S, всегда найдется такая реализация S и R:S, при которой: контракты S и R:S достаточны; инвариант S не нарушается A; R не противоречит ППЛ. С этим тоже не согласны? Причем имеенно только для варианта S<-R... Для варианта R<-S такого утвеждать нельзя.

G>Вы, должно быть, шутите, мистер Фейнман? С того, что у вас в условии заданы алгоритмы рассчета площади и публичные порперти, которые однозначно задают именно "квадрат" и именно "прямоугольник". Не существует других фигур, площадь которых рассчитывается по заданной схеме. Отсюда следует, что мы имеем дело именно с означенными геометрическими фигурами, а не сферическими конями в вакууме.

class Figure
{
public:
   // вот это было в примере
   virtual double GetArea() const = 0;

// а вот это вполне могло бы быть...
   virtual void Draw( Canvas & ) const = 0;
   virtual bool HasIntersection( const Figure & ) const = 0;
   vurtual bool Contains( const Point & ) const = 0;

// а вот это спорно, но вполне жизненно, и ППЛ не нарушает
protected:
   Point m_disp;
   double m_magnificationRatio;
   double m_angle;

   void ApplyAffineTransform( const Transform & ) {...}
};

G>> Так же, будет существовать и программа (агрегат), которая будет вести себя корректно.

If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T — BarbaraLiskov, Data Abstraction and Hierarchy, SIGPLAN Notices, 23,5 (May, 1988). .

G>> Ну не красиво же... право слово.

G>Вы меня убиваете, право слово. Я вам тут считай даром 50 баксов предлагаю , само по себе нивираятна блаародный и красивый поступок, вот. Причем все честно — Синклер человек строгих правил и не допустит тут никакого жульничества. А вы, можно сказать, раздающему, то есть мне, прикуп в морду швыряете. За что?!

G>Я ожидал услышать в ответ: я согласен. Вот вам моя программа. И, чуть позже: куда переводить деньги? 50 баксов, сами понимаете, не лишние.

G>Прямоугольник, определенный так как это сделано в задаче, не может являться подтипом квадрата. Он нарушает инварианты базового класса, или принцип подстановки Лисков, что по сути одно и то же. Поэтому я не могу сказать, что прямоугольник подтип квадрата. Но вам — можно.

Вы разве не согласны с тем, что тип — суть поведение? Разве Вы не согласны
с тем, что "вниз по иерархии" реализуемое типами поведение должно расширяться?
Как минимум — специализироваться? Так объясните мне — почему, если все поведение
квадрата, реализуемо прямоугольником, я не могу сказать, что прямоугольник
"подтип" квадрата?

G>Если да, то прежде чем... желательно бы услышать от Вас же расшифровку понятий: all programs, и behavior is unchanged

Если для любого o1 <- S найдется такой o2 <- T, что для любой программы p <- P, определенной в терминах T поведение p не изменится при замене o1 на o2, то S является подтипом T.

class Rectangle
{
    public int Width  
    {
        get { return _width; }
    }
    public int Height
    {
        get { return _height; }
    }
    public virtual void SetBounds(int width, int height)
    {
        _width  = width;
        _height = height;
    }
    
    private int _width;
    private int _height;
}

class Square: Rectangle
{
    public override void SetBounds(int width, int height)
    {
        if (width != height)
            throw Exception("...");
            
        base.SetBounds(width, height);
    }
}

virtual Rectangle SetBounds(int width, int height) const;

A type hierarchy is composed of subtypes and supertypes. The intuitive idea of a subtype is one whose objects provide all the behavior of objects of another type (the supertype) plus something extra. What is wanted here is something like the following substitution property [6]: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.

G>О, у меня появился вопрос, который надо снять. А что такое "определение ПЛВ"? Вы разъясните пожелуйста, или дайте ссылку на оригинал, а то вдруг это какой-нибудь очередной килограмм на ампер с сайта udaff.com, и мне следует обидиться?

Subtype Requirement: Let phi(x) be a property provable about objects x of type T. Then phi(y) should be true for objects y of type S where S is a subtype of T.

G>Ой спасибо А я-то, тупил...

Если для любого o1 <- S найдется такой o2 <- T, что не будет существовать такой программы p, которая при замене o1 на o2 способна определить эту замену, то S является подтипом T.

И лучше бы перед тем как... почитать таки оригинал. Это поможет снять некоторые вопросы. И может быть Вам после этого станет ясно, почему, например, уже в определении ПЛВ нет этих терминов.

G>Вы меня удивляете ей богу... "Принцип Подстановки Лисков" Вам значит известен, а вот "Подтипы Лисков-Винг" (Liskov Wing Subtyping) значит нет?! Весело блин...

G> Для начала указали бы мне на "ошибку"... а то я, по глупости своей, её так и не увидел.

G>Кто говорит, что LSP никто ни при каких обстоятельствах не нарушает?

class Stream
{
    public abstract bool IsReadonly();
    public abstract void Read(...);
    public abstract void Write(...);
}

class FileReadStream
{
    public override bool IsReadonly() { return true; }
    public override void Read(...)    { ... }
    public override void Write(...)   { throw ...; }
}

G>>Кто говорит, что LSP никто ни при каких обстоятельствах не нарушает?

class Base {
    public abstract int GetType();
    public abstract void DoSomethingSpecialForDerived1();
    public abstract void DoSomethingSpecialForDerived2();
    public abstract void DoSomethingSpecialForDerivedN();
}
class Derived1: Base {
    public override int GetType() { return 1; }
    public override void DoSomethingSpecialForDerived1() { ... }
    public override void DoSomethingSpecialForDerived2() { throw ... }
    public override void DoSomethingSpecialForDerivedN() { throw ... }
}
class Derived2: Base {
    public override int GetType() { return 2; }
    public override void DoSomethingSpecialForDerived1() { throw ... }
    public override void DoSomethingSpecialForDerived2() { ... }
    public override void DoSomethingSpecialForDerivedN() { throw ... }
}
class DerivedN: Base {
    public override int GetType() { return N; }
    public override void DoSomethingSpecialForDerived1() { throw ... }
    public override void DoSomethingSpecialForDerived2() { throw ... }
    public override void DoSomethingSpecialForDerivedN() { ... }
}

class Container
{
public:
   virtual void insert(Object);
   virtual void iterate(Callback);
};

class AssociativeOrderedContainer : public Container
{
   . . .
};

The specification describes what the abstraction does, but omits any information about how it is implemented. By omitting such detail, we permit many different implementations. An implementation is correct if it provides the behavior defined by the specification. Correctness can be proved mathematically if the specification is written in a language with precise semantics; otherwise we establish correctness by informal reasoning or by the somewhat unsatisfactory technique of testing. Correct implementations differ from one another in how they work, i.e., what algorithms they use, and therefore they may have different performance. Any correct implementation is acceptable to the caller provided it meets the caller's performance requirements. Note that correct implementations need not be identical to one another; the whole point is to allow implementations to differ, while ensuring that they remain the same where this is important. The specification describes what is important.

First, a set is not a subtype of a list nor is the reverse true. If the same element is added to a set twice, the result is the same as if it had been added only once and the element is counted only once in computing the size of the set. However, if the same element is added twice to a list, it occurs in the list twice. Thus a program expecting a list might not work if passed a set; similarly a program expecting a set might not work if passed a list.