Переопределение getPreferredSize() прерывает LSP

Несколько аспектов этого интересного вопроса (Безумный уже упоминал о запасном моем коллеге-разработчике)

Нарушаем ли мы LSP, переопределяя только getXXSize() (а также setXXSize())?

Нет, если мы делаем это правильно :-) Первым авторитетом является API-документ свойства, лучше всего из его происхождения, то есть Компонента:

Устанавливает предпочтительный размер этого компонента в постоянное значение. Последующие вызовы getPreferredSize всегда будут возвращать это значение.

Это обязывающий контракт, поэтому, как бы мы ни реализовали геттер, он должен учитывать значение constant, если оно установлено:

@Override
public Dimension getPreferredSize() {
    // comply to contract if set
    if(isPreferredSizeSet())
        return super.getPreferredSize();
    // do whatever we want
    return new Dimension(dim);
}

XXSize — это связанное свойство, не так ли?

В родословной JComponent есть только косвенные доказательства: на самом деле Component запускает PropertyChangeEvent в установщике. Сам JComponent, похоже, документирует этот факт (выделено мной жирным шрифтом):

@beaninfo предпочтительный: true bound: true описание: предпочтительный размер компонента.

Что... совершенно неверно: быть связанным свойством означает, что слушатели должны быть уведомлены всякий раз, когда значение изменяется, то есть должно пройти следующее (псевдо-тест):

JLabel label = new JLabel("small");
Dimension d = label.getPreferredSize();
PropertyChangeListener l = new PropertyChangeListener() ...
    boolean called;
    propertyChanged(...) 
        called = true;
label.addPropertyChangeListener("preferredSize", l);
label.setText("just some longer text");
if (!d.equals(label.getPreferredSize())
   assertTrue("listener must have been notified", l.called); 

... но не получается. По какой-то причине (не знаю, почему это могло показаться уместным) они хотели, чтобы константная часть xxSize была связанным свойством — такие наложения просто невозможны. Возможно, это была (конечно, дикая догадка) историческая проблема: изначально сеттер был доступен только в Swing (по уважительным причинам). В своем бэкпорте для awt он мутировал в свойство bean-компонента, которым никогда не был.

Вообще говоря, на этот вопрос нет простого (или правильного) ответа.

Нарушает ли переопределение getPreferredSize принцип замены Лисков? Да (на основании имеющейся документации).

Но разве большинство Object не является расширением? Какой смысл менять поведение метода, если он должен строго соответствовать ожиданиям исходной реализации (да, есть хорошие примеры, когда вы должны это сделать, например hashcode и equals и другие, где линия выделена серым цветом) ?

В данном случае проблема, по-видимому, связана с неправильным использованием setXxxSize и тем фактом, что эти методы на самом деле являются public. Почему они общедоступны? Я понятия не имею, поскольку они являются причиной большего количества проблем, чем любая другая часть API (включая KeyListener).

Переопределение getPreferredSize предпочтительнее, поскольку изменение переносится вместе с объектом, в отличие от вызова setPreferredSize из-за пределов владения/контекста объекта.

Поскольку предполагается, что getXxxSize предоставляет менеджеру компоновки подсказки по размеру, на самом деле не кажется какой-либо достаточно веской причины иметь методы setXxxSize public, поскольку, ИМХО, разработчики не должны с ними связываться - для этого требуется компонент. обеспечил наилучшую оценку необходимого размера на основе собственных внутренних требований.

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

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

Лично я считаю, что нужно максимально игнорировать setXxxSize (или относиться к нему как к protected). Одной из причин переопределения getXxxSize является то, что люди не могут изменить размер, но в равной степени вы можете переопределить setXxxSize и создать неподдерживаемое исключение.

Если бы вы задокументировали решения об игнорировании setXxxSize, было бы это нарушением принципа замены Лискова? Возможно, поскольку компонент все еще может вести себя как родитель.

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

Основываясь на вашем примере, вы вообще не должны переопределять getXxxSize или setXxxSize, а вызывать setXxxSize из конструктора, так как это будет поддерживать текущий контракт API, но также будет наступать на пальцы ног при вызове переопределяемых методов из конструктора. .

Куда бы вы ни посмотрели, вы наступаете кому-то на пятки...

Короче всего. Если это важно для вас (для поддержания принципа замещения Лискова), вы должны использовать setXxxSize в контексте ваших собственных компонентов. Проблема в том, что невозможно помешать кому-то уничтожить ваши дизайнерские решения своими собственными ценностями, и, как я уже говорил в комментариях, когда люди делают это, на самом деле не понимая, что они делают, это просто превращает работу всех остальных в кошмар. .

Не злоупотребляйте setPreferredSize, используйте его только из контекста экземпляра объекта и не вызывайте его извне... ИМХО