powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Выгоды контрактного программирования (design by contract)
25 сообщений из 232, страница 2 из 10
Выгоды контрактного программирования (design by contract)
    #36918555
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemarglegorych,

Да. Но это чуть другое из DbC.
-Изменение ширины не влияет на значение длины - это отсутствие побочных эффектов.в то время как у квадрата побочный эффект обязателен. Изменение "ширины" _должно_ приводить к изменению "длины" ( кавычки тут к тому, что у квадрата сложно выделить ширину и длину :) )
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36918828
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorychSiemarglИнварианты могут разными, в зависимости от задачи:
-вариант 1. Все стороны равны.
-вариант 2. Все углы прямые
-вариант 3. Сторон не больше 4х.-вариант 4. Величины длины и ширины могут меняться независимо

да.

SetWidth(Square(5), 10)
вернет значение
Rectangle(10, 5)
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36918937
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNSetWidth(Square(5), 10)
вернет значение
Rectangle(10, 5)это смотря как реализована SetWidth(). Если, что логично, она будет спрашивать встроенный метод Rectangle.SetWidth(), то вернёт вполне себе квадрат ( 10, 10 ), иначе или SetWidth должна знать, кого ей передают, или реализация Square::SetWidth() должна быть очень необычна ( и нарушать принцип наименьшего удивления при этом )
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36918976
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorychZyK_BotaNSetWidth(Square(5), 10)
вернет значение
Rectangle(10, 5)это смотря как реализована SetWidth(). Если, что логично, она будет спрашивать встроенный метод Rectangle.SetWidth(), то вернёт вполне себе квадрат ( 10, 10 ), иначе или SetWidth должна знать, кого ей передают, или реализация Square::SetWidth() должна быть очень необычна ( и нарушать принцип наименьшего удивления при этом )
Ну вот код:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
public class Rectangle {
	private double w,h;
	Rectangle(double w, double h) {
		this.w = w;
		this.h = h;
	}
	Rectangle setWidth(double newW) {
		return new Rectangle(newW, h);
	}
	Rectangle setHeight(double newH) {
		return new Rectangle(w, newH);
	}
	double getWidth() {
		return w;
	}
	double getHeight() {
		return h;
	}
	void show() {
		System.out.println("Rectangle("+getWidth()+","+getHeight()+")");
	}
}



public class Square extends Rectangle {
	Square(double side) {
		super(side, side);
	}
	void show() {
		System.out.println("Square("+getWidth()+","+getHeight()+")");
	}
}


public class Main {
	public static void main(String[] args) {
		Square s = new Square( 5 );
		Rectangle r = s.setWidth( 10 );
		s.show();
		r.show();
	}
}


в результате будет вывод:

Square(5.0,5.0)
Rectangle(10.0,5.0)
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36918985
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
подправил класс Square:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
public class Square extends Rectangle {
	Square(double side) {
		super(side, side);
	}
	Square setSide(double newSide) {
		return new Square( newSide );
	}
	void show() {
		System.out.println("Square("+getWidth()+")");
	}
}

теперь программа:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
public class Main {
	public static void main(String[] args) {
		Square s = new Square( 5 );
		Rectangle r = s.setWidth( 10 );
		s.show();
		r.show();
		s = s.setSide( 3 );
		s.show();
	}
}
выдает:
Square(5.0)
Rectangle(10.0,5.0)
Square(3.0)
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919026
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_модtchingizВ дизайне по контракту совершенно на теоретико множественных пальцах (то есть понятно) рассказывают, почему в примере Роберта Мартина с квадратами и прямоугольниками нельзя делать наследование.

Равенство сторон - это инвариант, который усилен в подтипе. Так что все правильно - квадрат подтип прямоугольника.
не правильно.
1)
Область определения функций (методов класса) была сужена.
(У прямоугольников была плоскость, у квадратов диагональ плоскости.)
2)
методы у так называемого ребенка - квадратов удовлетворяют аксиомам противоречащим
аксиомам методов так называемого родителя - прямоугольников.
поэтому, оказалось невозможное корректное выполнение цепочка
а) преобразование из ребенка в родителя
б) выполнение метода
в) восстановление ребенка взад.

если на шаге б) выполнялся метод родителя, нарушался инвариант ребенка.
если на шаге б) выполнялся метод ребенка, нарушались условия,
выполнения функций (клиента), которые были написаны в предположении
аксиом родителя.

пысы.
поскольку сам Карделли разрешил использовать наивную модель памяти при толковании
ооп, в которой
обьект это пара (кортеж, множество_методов), то
моя функциональная запись классов и обьектов в виде
абстрактных автоматов оказывается точным описанием.
(класс это пара (множество_допустимых_значений, множество_функций),
объект - это пара (кортеж , множество_функций))
А проблема не возможности наследования остается все равно.
Так что функциональность тут не причем.
Дело в несовместимости аксиом описания классов, совмещением которых
и занят Мейер в своем методе программирования по контракту
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919031
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вот аксиомы обоих классов
http://www.sql.ru/forum/actualthread.aspx?tid=756625&pg=4#9543464
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919054
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.SetWidth(  10  ); // опа!
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919074
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz,

Ну пц, пояснил )))))
Еще хуже стало.

Если я понял правильно, то для решения проблем преобразования "родственников" есть виртуальные ф-ции. Инвариант ес-но, тоже должен быть виртуальным.
И еще мне кажется, что "теорию происхождения видов" неправильно привязывать к ООП - суть разная. (Майерса не читал, что он имел в виду - не знаю)
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919086
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorychZyK_BotaN, красиво, но у меня 2 замечания:
1. методы set какбы намекают, что я меняю текущий объект, а не создаю новый
2. вообще говоря, я ведь могу захотеть сделать
Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.SetWidth(  10  ); // опа!

перечитай исправленную версию:

Код: plaintext
1.
Square s  = new Square(  5  );
Square evil = s.setSide(  10  ); // опа!
[/quot]

что мне не нравится в моем коде, дак это метод show.
я его написал, что-бы короче было. лучше было бы написать два метода
showSquare и showRectangle
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919100
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Siemargltchingiz,

Ну пц, пояснил )))))
Еще хуже стало.

Если я понял правильно, то для решения проблем преобразования "родственников" есть виртуальные ф-ции. Инвариант ес-но, тоже должен быть виртуальным.
И еще мне кажется, что "теорию происхождения видов" неправильно привязывать к ООП - суть разная. (Майерса не читал, что он имел в виду - не знаю)
1
не правильно. для решения проблем родственников - нужны совместимые
системы аксиом.
2
у прямоугольников аксиома говорит о не зависимости методов
Код: plaintext
1.
 all h: UReal, f: Figure:- GetWidth(SetHeight(f, h)) = GetWidth(f)
для любого вещественного х, и любой фигуры ф, гетШирина(сетДлина(ф,х))
равно гетШирина(ф), взятие ширины не зависит от применения установить длину.

а у квадратов зависит
Код: plaintext
1.
2.
,[gw_sh]
        all h: UReal, f: Figure:- GetWidth(SetHeight(f, h)) = h
взятьширину возвращает, то что задано задатьдлину.

шо тут непонятно?

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

3
не Майерс, а Бертран Мейер.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919107
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В результате клиент умирает от удивления, со словами: "а мы так не договаривались"
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919114
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Более того, точно такой же техникой на с++,
какой записывалось порождение квадратов из прямоугольников,
можно записать порождение прямоугольников из квадратов.
с точно той же проблемой не соответствия аксиом.
Эти классы не ребенок и родитель, а два близнеца.
Их не надо, вообще, один из другого порождать.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919122
belugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz,

как только ты делаешь квадрату setWidth он перестает быть квадратом. Надо просто в объектную модель ввести predicate classes как в языке cecil .
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919131
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
belugintchingiz,

как только ты делаешь квадрату setWidth он перестает быть квадратом. Надо просто в объектную модель ввести predicate classes как в языке cecil .

конечно, я это выше и продемонстрировал с примерами кода.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919135
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
под словом квадрат я не имею ввиду ничего другого кроме как
объекты обсуждаемого класса Square.
Они заданы однозначно и совершенно понятно формальным описанием
на с++ в примера Роберта Мартина.
После вызова функций setWidth из своего класса, квадрат квадратом быть не перестает.
Это переменная, объявленная классом, возможно, оказавшаяся в противоречивом состоянии..
И обсуждается смысл техники программирования,
а не смысл геометрических фигур на плоскости.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919143
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizпод словом квадрат я не имею ввиду ничего другого кроме как
объекты обсуждаемого класса Square.
Они заданы однозначно и совершенно понятно формальным описанием
на с++ в примера Роберта Мартина.

а чем тебе не понравилась моя реализация фигур?
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919166
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919175
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizа что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?
если игнорировать метод show, то да.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919200
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz,
Пока не прочитал статью Лисковой, не понятно было о чем вы говорите )

Теперь возвращаюсь к своему же предыдущему утверждению:
инварианты (аксиоматика) связана с наследованием, и обязательна к учитыванию при проектировании.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919261
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
естественно
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919263
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Статья не Лисков, а Мартина
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919279
Фотография tchingiz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ZyK_BotaNtchingizа что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?
если игнорировать метод show, то да.
не понял, что да.
ты написал в функциональном стиле. Мне кажется, что это означает что цепочка
Код: plaintext
1.
2.
3.
4.
5.
z -некоторый кортеж
Square s = new Square( 5 );
Rectangle r = s;
r.method(z);
s = r;
должна быть изменена в


Код: plaintext
1.
2.
3.
4.
z -некоторый кортеж;
Square s = new Square( 5 );
Rectangle r = s;
s = r.method(z);

вопрос, в том, что
1) все ранее, написанные программы работают при применении методов, если подсунуть ребенка,
под видом родителя;
2) можно выполнить обратное преобразование родитель -> ребенок, после применения
методов, когда ребенок был под видом родителя.

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

вот это главное,
Код: plaintext
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919284
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingizZyK_BotaNtchingizа что ты хотел добиться? А то я недопонял пока
Перестал нарушаться принцип Лисков?
если игнорировать метод show, то да.
не понял, что да.

только метод show нарушает принцип Лисков.

tchingiz
ты написал в функциональном стиле. Мне кажется, что это означает что цепочка
Код: plaintext
1.
2.
3.
4.
5.
z -некоторый кортеж
Square s = new Square( 5 );
Rectangle r = s;
r.method(z);
s = r;
должна быть изменена в


Код: plaintext
1.
2.
3.
4.
z -некоторый кортеж;
Square s = new Square( 5 );
Rectangle r = s;
s = r.method(z);

здесь можно подробней? я не понял.


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

вот это главное,
Код: plaintext
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.
тогда с потерей точности будет работать.
но тогда преобразование нужно делать явно.
...
Рейтинг: 0 / 0
Выгоды контрактного программирования (design by contract)
    #36919288
Фотография ZyK_BotaN
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tchingiz
вот это главное,
Код: plaintext
[color=red]s = r;[/color]
а ты просто увильнул.
Так и у Мартина нет проблемы. Скопировал квадрат в прямоугольник, изменил его ширину и все.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
public class Rectangle {
	private double w,h;
	public Rectangle(double w, double h) {
		this.w = w;
		this.h = h;
	}
	public Rectangle setWidth(double newW) {
		return new Rectangle(newW, h);
	}
	public Rectangle setHeight(double newH) {
		return new Rectangle(w, newH);
	}
	public double getWidth() {
		return w;
	}
	public double getHeight() {
		return h;
	}
}



public class Square extends Rectangle {
	public Square(double side) {
		super(side, side);
	}
	public Square(Rectangle r) {
		this(r.getHeight());
	}
	public Square setSide(double newSide) {
		return new Square( newSide );
	}
	
}


public class Main {
	static void showRectangle(Rectangle r) {
		System.out.println("Rectangle("+r.getWidth()+","+r.getHeight()+")");
	}
	static void showSquare(Square s) {
		System.out.println("Square("+s.getWidth()+")");
	}
	
	public static void main(String[] args) {
		Square s = new Square( 5 );
		Rectangle r = s.setWidth( 10 );
		showRectangle(r);
		showSquare(new Square(r)); //явное преобразование вниз по иерархии
	}
}

вывод:

Код: plaintext
1.
2.
Rectangle( 10 . 0 , 5 . 0 )
Square( 5 . 0 )
...
Рейтинг: 0 / 0
25 сообщений из 232, страница 2 из 10
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Выгоды контрактного программирования (design by contract)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]