Вопрос по принципу Лисков.

Дата регистрации: 28.11.2016 13:43:35

Опять анонiмус со своими Гидралисками пришёл.

Вы, простите, с кем сейчас разговаривали?

Нарушили ли мы принцип Лисков?

Да

этож анонiiмус он всегда разговаривает с метафизической общностью лора

В чем именно?

Для обьекта прямоугольник я мог задать ширину путем вызова метода setWidth, для квадрата, как его описал ты, не могу задать ширину вызовом этого метода, т.е. я не могу использовать объект квадрат, где раньше использовался прямоугольник.

допустим, мы переопределяем методы квадрата setWidth и setHeight таким образом, что квадрат не реагирует на них, просто игнорирует.

Нарушили ли мы контракты? Нет.

Афигеть.

Контракт прямоугольника (инвариант): ширина и высота положительны.

Стороны не отрицательны :-)

Контракт квадрата (инвариант): ширина и высота положительны; ширина и высота равны.

Стороны равны :-) (Вырожденный случай - точка) :-)

допустим, мы переопределяем методы квадрата setWidth и setHeight таким образом, что квадрат не реагирует на них, просто игнорирует.

Игнорить нельзя, выше ты определил ОДЗ, т.е. инварианты :-) Нарушение инвариантов - это логическая ошибка :-)

Нарушили ли мы контракты? Нет. Нарушили ли мы принцип Лисков? Да, вроде, тоже нет. Тогда в чем проблема?

Нет проблем :-)

Для обьекта прямоугольник я мог задать ширину путем вызова метода setWidth, для квадрата, как его описал ты, не могу задать ширину вызовом этого метода

А разве это есть в наших контрактах, что изменения гарантируются для любого вызова?

Игнорить нельзя, выше ты определил ОДЗ, т.е. инварианты

Что то я не вижу в каком месте они нарушаются

Согласно твоим контрактам объекты можно инициализировать со сторонами 1 и 1 и вообще никакие методы не нужны.

Что то я не вижу в каком месте они нарушаются

У квадрата стороны равны :-) Поэтому, если имеется ссылка на объект прямоугольника (общий случай квадрата), когда на самом деле это квадрат, должна сработать проверка ОДЗ для квадрата :-)

вообще никакие методы не нужны.

А как же изменения сторон прямоугольника? Ты это к чему вообще?

Поэтому, если имеется ссылка на объект прямоугольника (общий случай квадрата), когда на самом деле это квадрат, должна сработать проверка ОДЗ для квадрата :-)

Если мы обращаемся к квадрату как к прямоугольнику, почему нас должны интересовать квадрат это или не квадрат?

допустим, мы переопределяем методы квадрата setWidth и setHeight таким образом, что квадрат не реагирует на них, просто игнорирует.

Допустим мы выносим эти методы в отдельный интерфейс, который квадрат ес-но не будет реализовывать.

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

Если мы обращаемся к квадрату как к прямоугольнику, почему нас должны интересовать квадрат это или не квадрат?

Кого нас? :-) Инвариант должен не нарушаться, только и всего :-) С другой стороны, нет основания игнорить вызов метода :-) Логичнее уж определить для квадрата setX и setY одинаково :-)

У прямоугольника ведь, помимо этого мало ли что еще может быть, например, метод масштабирования, который вполне применим и к частному случаю, если ты о мнимой «бессмысленности»

Anonimous, скажи, а это не твой тред: https://www.reddit.com/r/haskell/comments/5ezfmb/what_is_haskell_good_for/ ? Очень похожий стиль.

Превратили программирование чёрт знает во что.

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

нет

Ты хочешь сказать, что в мире есть второй человек, обожающий JS и модель акторов, и при этом испытывающий анальный зуд при виде слова Haskell?

Видимо, да

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

Зацепила тебя Барбара :-) В данном конкретном случае нарушений не видно :-)

Поставьте, пожалуйста, тег «парадигма». Такие посты не воспринимаются серьезно без этого слова. Обязательно должно быть!

Не то чтобы зацепило, просто пришла вголову такая мысль. В целом мне насрать и на нее и на SOLID в целом, это все ереси, к нормальному ООП в кеевском смысле это едва ли имеет какое то отношение. В некоторых случаях может быть полезно, но не более того.

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

В шизофрении.

В целом мне насрать и на нее и на SOLID в целом, это все ереси, к нормальному ООП в кеевском смысле это едва ли имеет какое то отношение.

Ну, типа, если этого принципа придерживаться, то в рантайме проверок будет меньше :-)

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

Честно говоря, квадрат - это не прямоугольник, у которого все стороны равны :-) Квадрат - это _правильный_ четырёхугольник :-) Другими словами, интерфейсы у них разные :-) У квадрата лишь один метод, какой-нибудь setLength, тогда как у прямоугольника их два :-)

Честно говоря, квадрат - это не прямоугольник, у которого все стороны равны :-) Квадрат - это _правильный_ четырёхугольник :-) Другими словами, интерфейсы у них разные :-) У квадрата лишь один метод, какой-нибудь setLength, тогда как у прямоугольника их два :-)

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

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

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

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

Тогда уж имеет смысл сущность «Многоугольник» с методами «являетсяПравильным?», «количествоСторон», «уголМеждуСторонами» и т.д. :-) Нафиг тут какие-то принципы подстановок? :-)

анонiмус предсказуем, его даже движок ЛОРа распознает в похожих темах.

Принципы подстановки тут не причем, это так, к слову:)

Можно себе представить класс «прямоугольник с заданным соотношением длин сторон», у которого метод setwidth меняет не только ширину, но и высоту. Квадрат это такой прямоугольник с соотношением 1:1. Но если контракт метода setwidth не позволяет менять ничего, кроме ширины, то такой прямоугольник не является прямоугольником.

Если прямоугольник не содержит методов setwidth/setheight, а содержит только getwidth/getheight, то квадрат является прямоугольником.

Надо поставить тест при регистрации - какая нибудь заумная концепция программирования и заведомо правильный ответ будет означать провал. Большинство кликнет на произвольный вариант, и лишь анонiмус будет тыкать правильные ответы и не попадет на ЛОР :)

Хм, надо этим кандидатов на собеседовании развлекать.

допустим, мы переопределяем методы квадрата setWidth и setHeight таким образом, что квадрат не реагирует на них, просто игнорирует.

Нарушили ли мы контракты? Нет. Нарушили ли мы принцип Лисков? Да, вроде, тоже нет.

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

Вот псевдокод для примера:

RSpec.shared_examples 'rectangle' do
  describe '#width=' do
    it 'changes #width' do
      new_width = subject.width + 1
      subject.width = new_width
      expect(subject.width).to eq(new_width)
    end

    it "doesn't change #height" do
      expect { subject.width += 1 }.not_to change { subject.height }
    end
  end

  describe '#height=' do
    it 'changes #height' do
      new_height = subject.height + 1
      subject.height = new_height
      expect(subject.height).to eq(new_height)
    end

    it "doesn't change #width" do
      expect { subject.height += 1 }.not_to change { subject.width }
    end
  end
end

RSpec.describe Rectangle do
  subject { described_class.new(width: 3, height: 4) }
  it_behaves_like 'rectangle'
end

RSpec.describe Square do
  subject { described_class.new(3) }
  it_behaves_like 'rectangle' # FAIL!
end

# $ rspec rect.rb
# ....F.F.
#
# Failures:
#
#   1) Square behaves like rectangle #width= changes #width
#      Failure/Error: expect(subject.width).to eq(new_width)
#
#        expected: 4
#             got: 3
#
#        (compared using ==)
#      Shared Example Group: "rectangle" called from ./rect.rb:80
#      # ./rect.rb:51:in `block (3 levels) in <top (required)>'
#
#   2) Square behaves like rectangle #height= changes #height
#      Failure/Error: expect(subject.height).to eq(new_height)
#
#        expected: 4
#             got: 3
#
#        (compared using ==)
#      Shared Example Group: "rectangle" called from ./rect.rb:80
#      # ./rect.rb:63:in `block (3 levels) in <top (required)>'
#
# Finished in 0.05544 seconds (files took 0.2406 seconds to load)
# 8 examples, 2 failures
#
# Failed examples:
#
# rspec './rect.rb[2:1:1:1]' # Square behaves like rectangle #width= changes #width
# rspec './rect.rb[2:1:2:1]' # Square behaves like rectangle #height= changes #height

Аплодисменты безымянному!

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

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

Я так по тебе соскучился....

Я так по тебе соскучился....

portquest2016:

Последний комментарий: 27.11.2016 21:47:53

Вы прям настолько близки?

А я по тебе.

Да не, это ж анонiмус :)

А portquest2016 — не анонiмус, ага.

Это уже обсудили выше.

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

Да? Ничего себе!

Нарушили ли мы контракты? Нет. Нарушили ли мы принцип Лисков? Да, вроде, тоже нет. Тогда в чем проблема?

Тебе контракты чтобы целы были или чтобы программа делала то что надо?

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

абстагирован от какой-либо пользы

Хорошая абстракция