Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9 10   вперед  Ctrl      все
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
Siemargl
ZyK_BotaN,

Есть еще принцип Open-Close, который ты нарушил. Потому твой код ужасен.


Принцип Открытости-Закрытости (Open Close Principle или OCP)

Программные сущности такие как классы, модули и функции должны быть открыты для расширения, но закрыты для изменений.


у меня они как раз открыты для расширения и закрыты для изменения. все ок. где нарушение?
27 окт 10, 12:02    [9683565]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
_мод
tchingiz
присвоении t значения любой переменной s: S,

Любой нормальный компилятор обругает такое присваивание :) или хотя-бы предупредит


да нет, там вроде все нормально написано, и компиляторы вроде не ругаются.
27 окт 10, 12:07    [9683609]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
ZyK_BotaN
да нет, там вроде все нормально написано, и компиляторы вроде не ругаются.

Переменные ведь разных типов - компилятор предупредит (должен), что будет преобразование.
Плохое определение, вообщем.
27 окт 10, 12:34    [9683862]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
_мод
ZyK_BotaN
да нет, там вроде все нормально написано, и компиляторы вроде не ругаются.

Переменные ведь разных типов - компилятор предупредит (должен), что будет преобразование.
Плохое определение, вообщем.

как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.
27 окт 10, 12:37    [9683886]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
ZyK_BotaN
как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.

Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.
27 окт 10, 12:42    [9683935]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
_мод
ZyK_BotaN
как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.

Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.

можешь назвать о компиляторах каких языков ты говоришь.
27 окт 10, 12:44    [9683953]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
Кстати, у Лисков правильно написано - не присвоение t=s, а подстановка вместо t s.
Т.е. методы t непосредственно применяются к s и при этом их поведение не меняется.
К случаю квадратов и прям-ов это полностью подходит, т.к. методы прям-ов на квадратах либо нормально работают, либо не работают совсем. Но поведение их не меняется.
зы Нужно делать, как в динамических языках - левая часть принимает тип правой. То же и при передаче парметров, т.е. в методы прям-ов передаются квадраты без преобразования типов.
27 окт 10, 13:08    [9684158]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
_мод
Guest
ZyK_BotaN
можешь назвать о компиляторах каких языков ты говоришь.

Последний такой был pl/1. М.б. какой-нить паскаль. Но мне больше нравится подход в динамических языках: переменная принимает тип выражения из правой части.
27 окт 10, 13:23    [9684292]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
k0rvin
Member

Откуда:
Сообщений: 524
ZyK_BotaN
класс Integral является подтипом класса Real.

как это понимать?
"тип подтипом типа" понимаю,
"класс субклассом класса" понимаю,
"класс подтипом класса" не понимаю =/

ZyK_BotaN
или я что-то не понимаю?

скорее что-то путаешь.

ZyK_BotaN
просто в хаскеле нужно явно приводить объект дочернего класса к родительскому.

не совсем, многие классы предоставляют функции преобразования, выполняющиеся автоматически, типа fromInteger, fromEnum, toEnum, etc

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

это [почти] везде где так
27 окт 10, 13:31    [9684342]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
k0rvin

это [почти] везде где так

ну а я это указал для тех, для кого 1/2 = 0 - является интуитивно понятным.

k0rvin

"класс подтипом класса" не понимаю

виноват исправлюсь
27 окт 10, 17:14    [9686861]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
k0rvin

не совсем, многие классы предоставляют функции преобразования, выполняющиеся автоматически, типа fromInteger, fromEnum, toEnum, etc


но это ведь происходит без потери точности?
27 окт 10, 17:41    [9687178]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31955
_мод
ZyK_BotaN
как это разных? S - подтип. Т - супер тип. соответственно s принадлежит типу Т.

Это только позволяет компилятору выполнить преобразование. Предупреждение все равно д.б. М.б. это ошибка программиста.

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

пысы


Дмидек
Мемберы Siemargl и egorych добавлены в ЗПТ.
Чингиз - традиционный вопрос - ты им сообщишь при оказии или
мне написать письма ? :-)
27 окт 10, 20:03    [9687957]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6065
tchingiz, понял про ЗПТ, типа спс за доверие.

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

ZyK_BotaN, пример слишком тривиален (и дажи при том ты ромб выбросил, как неудобный=) и неопределены аксиомы, чтобы на нем тренировать.
27 окт 10, 20:18    [9688016]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
tchingiz
Member

Откуда:
Сообщений: 31955
не неудобный ромб, а мы его попросили, ато долго думать при длинном примере.
Его мысль все равно видна будет.
27 окт 10, 20:25    [9688039]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
Siemargl
tchingiz, понял про ЗПТ, типа спс за доверие.

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

ZyK_BotaN, пример слишком тривиален (и дажи при том ты ромб выбросил, как неудобный=) и неопределены аксиомы, чтобы на нем тренировать.


двай, изобретай. но что за проблема с аксиомами.
и самое главное ты не ответил на вопрос про открытость/закрытость
27 окт 10, 20:27    [9688050]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6065
ZyK_BotaN
и самое главное ты не ответил на вопрос про открытость/закрытость

Речь об этих классах.

Пример такой. Написал ты стороннюю коллекцию.
Пусть без ромба. Пусть vector<Rectangle*> (без указателя типы приведутся и потеряются).
Нужно все элементы коллекции скажем, уменьшить вдвое.
Но у тебя Rectangle::setWidth() и Square::setSide()

Чтобы написать коллекцию, тебе придется "открыть" классы и внести в них изменения, добавив общий метод.

Второе нарушение тут.
	Square(Rectangle r) : Rectangle(r.getHeight(),r.getHeight()),
		Rhomb(90, r.getHeight()) {

	}
	Square(Rhomb r) : Rectangle(r.getSide(),r.getSide()),
		Rhomb(90, r.getSide()) 
Появится еще одна фигура - тебе придется переписать и ее наследников по иерархии, чтобы учесть ее ньюансы.
27 окт 10, 20:55    [9688168]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
Siemargl
ZyK_BotaN
и самое главное ты не ответил на вопрос про открытость/закрытость

Речь об этих классах.

Пример такой. Написал ты стороннюю коллекцию.
Пусть без ромба. Пусть vector<Rectangle*> (без указателя типы приведутся и потеряются).
Нужно все элементы коллекции скажем, уменьшить вдвое.
Но у тебя Rectangle::setWidth() и Square::setSide()

Чтобы написать коллекцию, тебе придется "открыть" классы и внести в них изменения, добавив общий метод.

действительно, передача по ссылку все портит. придется запрещать и ссылку.
недаром в с++, так можно
const double& c = 1
а так нельзя
double& c = 1
я был не прав, что не заметил такой дыры. Но с++ я выбрал, что-бы показать множ. наследование. а так здесь идут теоретические рассуждения. я заранее предупредил, что объекты должны быть иммутабельны.
у меня вся фишка в иммутабельности, а сдесь она нарушается.
но - это с++ с его выкрутасами, там даже константу можно изменить.
а поломаешь ли ты аналогичный код на java?
если есть здесь опытные с++-ки, подскажите можно ли сделать класс неизменяемых объектов в С++, не потеряв возможность наследоваться.

Siemargl

Второе нарушение тут.
	Square(Rectangle r) : Rectangle(r.getHeight(),r.getHeight()),
		Rhomb(90, r.getHeight()) {

	}
	Square(Rhomb r) : Rectangle(r.getSide(),r.getSide()),
		Rhomb(90, r.getSide()) 
Появится еще одна фигура - тебе придется переписать и ее наследников по иерархии, чтобы учесть ее ньюансы.


зачем? разве в принципе о/з сказано про то что можно изменять супер классы?
я лишь увидел что можно расширять наследников и запрещено ломать родительские классы.
27 окт 10, 22:13    [9688486]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6065
ZyK_BotaN,

1. Мне кажется, что ты неверно понимаешь иммутабельность.
2. Иммутабельность часто неудобна в реальной работе, чтобы на ней ставить икону. Кроме того, в С++ иммутабельности нет и в Java вроде бы тоже. (Она есть в D - и если поискать - можно найти статью Брайта, где поясняется отличие C++ const от D immutable)
3. Второе нарушение не относится к принципу о/з.
27 окт 10, 22:29    [9688571]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6065
Я придумал пример. Геймдев, RTS.
Владелец - поле боя.
Класс 1. Статический тайл. Контракт - всегда валиден.
Класс 2. Динамический тайл. Может быть разрушен. Контракт - не разрушен.
Класс 3. NPC. Может быть заморожен. Контракт - не заморожен.
Класс 4. User's soldier. Может управляться человеком. Контракт - жив, бегает.
27 окт 10, 22:41    [9688642]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
Siemargl
ZyK_BotaN,

1. Мне кажется, что ты неверно понимаешь иммутабельность.
2. Иммутабельность часто неудобна в реальной работе, чтобы на ней ставить икону. Кроме того, в С++ иммутабельности нет и в Java вроде бы тоже. (Она есть в D - и если поискать - можно найти статью Брайта, где поясняется отличие C++ const от D immutable)
3. Второе нарушение не относится к принципу о/з.


в джаве ты не сможешь подменить объект переданный по ссылке. там явных ссылок нет.
а в с++ можно все .
27 окт 10, 22:51    [9688691]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
Siemargl
ZyK_BotaN,


2. Иммутабельность часто неудобна в реальной работе.

согласен. но в данном случае она обязательна, и иначе иерархия ломается.

Siemargl

3. Второе нарушение не относится к принципу о/з.

можно на пальцах?
27 окт 10, 22:54    [9688707]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6065
ZyK_BotaN, давай про солдатиков придумывай.

Кстати, вспомнил историю из геймдева. Когда игра падала - потому что для свиньи вызывался метод "стрелять", а пистолета - то нету )
27 окт 10, 23:07    [9688746]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
ZyK_BotaN

Siemargl

3. Второе нарушение не относится к принципу о/з.

можно на пальцах?

а точнее, если не относится к принципу о/з то в чем проблема?
имхо, это не нормально добавлять в иерархию наследования класс, и хотеть, что-бы наследники об этом не знали.
27 окт 10, 23:08    [9688751]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
ZyK_BotaN
Member

Откуда: Новгород-Северский
Сообщений: 103968
Siemargl
ZyK_BotaN, давай про солдатиков придумывай.

Кстати, вспомнил историю из геймдева. Когда игра падала - потому что для свиньи вызывался метод "стрелять", а пистолета - то нету )

блицкриг?
там еще есть байка:
отнаследовали ракету от летающего аппарата.
и в плохую погоду ракета возвращалась на базу
27 окт 10, 23:09    [9688758]     Ответить | Цитировать Сообщить модератору
 Re: Выгоды контрактного программирования (design by contract)  [new]
egorych
Member

Откуда: и зачем;
Сообщений: 4742
Дмидек
Мемберы Siemargl и egorych добавлены в ЗПТ.
сэнкс, тронут ;-))
28 окт 10, 01:38    [9689317]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 7 [8] 9 10   вперед  Ctrl      все
Все форумы / Программирование Ответить