История изменений
Исправление www_linux_org_ru, (текущая версия) :
я тут со всеми на ты общаюсь (в обе стороны)
Ещё напишите, что инкапсуляция - это возможность выдать качественный продукт вовремя. Нет, возможность обеспечения соблюдения инварианта - это следствие инкапсуляции, но не она.
если интересно именно это обсудить — то инкапсуляция это только один из способов обеспечить соблюдение инварианта
другой (мало распостраненный сейчас) способ — напрямую записать предикаты и заставить компилятор их проверять, и плевать на инкапсуляцию (очень аморально, гы-гы)
В качестве примера, предоставление доступа к внутренностям в режиме только для чтения никак не может повредить состоянию объекта, и тем не менее инкапсуляция в таком случае сомнительна.
беря твое же упоминание про капсулу (я с ним согласен) — капсула может быть прозрачной, и это инкапсуляции не вредит
вообще речь у нас о терминах, и там могут быть разные мнения — вон википедия пишет, что не все разделяют деление на инкапсуляцию и information hiding
но мой пойнт в том, что инварианты нужны железно (в смысле обязательно), а вот information hiding может быть под вопросом
скажем, если мы проектируем тип Time с обычными операциями Time::get_year(), Time::set_year(int), ... Time::get_second(), Time::set_second(int), то можно и позволить например time.set_second(100500), которая будет переводить секунды в минуты, часы и т.п. и добавлять их тоже, а не только ставить секунды (примерно как в ui андроида)
но обязательно get_second() после этого не должна возвращать 100500 — это будет нарушением инварианта
а теперь information hiding — нужно ли предоставлять get_seconds_since_epoch(), где эпоха не юниксовая, а некая своя? можно *спорить* на тему, что этот метод выдает наружу деталь реализации — именно спорить
еще пример: пусть нам нужен класс Point { float x; float y;} про который известно, что x и y имеют точность существенно ниже аппаратного float
и как ты будешь скрывать деталь реализации — а именно, последние мусорные биты float-а? скорее всего, никак
да, можно наколбасить на шаблонах imprecise_float, но у него *все* операции будут ровно те же, что и у обычного float-а, и смысл его будет только в том, чтобы где-то компилятор ругнулся на его конверсию в обычный float; вряд ли этот imprecise_float действительно будет полезным при разработке софта
Исправление www_linux_org_ru, :
я тут со всеми на ты общаюсь (в обе стороны)
Ещё напишите, что инкапсуляция - это возможность выдать качественный продукт вовремя. Нет, возможность обеспечения соблюдения инварианта - это следствие инкапсуляции, но не она.
если интересно именно это обсудить — то инкапсуляция это только один из способов обеспечить соблюдение инварианта
другой (мало распостраненный сейчас) способ — напрямую записать предикаты и заставить компилятор их проверять, и плевать на инкапсуляцию (очень аморально, гы-гы)
В качестве примера, предоставление доступа к внутренностям в режиме только для чтения никак не может повредить состоянию объекта, и тем не менее инкапсуляция в таком случае сомнительна.
беря твое же упоминание про капсулу (я с ним согласен) — капсула может быть прозрачной, и это инкапсуляции не вредит
вообще речь у нас о терминах, и там могут быть разные мнения — вон википедия пишет, что не все разделяют деление на инкапсуляцию и information hiding
но мой пойнт в том, что инварианты нужны железно (в смысле обязательно), а вот information hiding может быть под вопросом
скажем, если мы проектируем тип Time с обычными операциями Time::get_year(), Time::set_year(int), ... Time::get_second(), Time::set_second(int), то можно и позволить например time.set_second(100500), которая будет переводить секунды в минуты, часы и т.п. и добавлять их тоже, а не только ставить секунды (примерно как в ui андроида)
но обязательно get_second() после этого не должна возвращать 100500 — это будет нарушением инварианта
а теперь information hiding — нужно ли предоставлять get_seconds_since_epoch(), где эпоха не юниксовая, а некая своя? можно *спорить* на тему, что этот метод выдает наружу деталь реализации — именно спорить
еще пример: пусть нам нужен класс Point { float x; float y;} про который известно, что x и y имеют точность существенно ниже аппаратного float
и как ты будешь скрывать деталь реализации — а именно, последние мусорные биты float-а? скорее всего, никак
да, можно наколбасить на шаблонах imprecise_float, но у него *все* операции будут ровно те же, что и у обычного float-а, и смысл его будет только в том, чтобы где-то компилятор ругнулся на его конверсию в обычный float
Исправление www_linux_org_ru, :
я тут со всеми на ты общаюсь (в обе стороны)
Ещё напишите, что инкапсуляция - это возможность выдать качественный продукт вовремя. Нет, возможность обеспечения соблюдения инварианта - это следствие инкапсуляции, но не она.
если интересно именно это обсудить — то инкапсуляция это только один из способов обеспечить соблюдение инварианта
другой (мало распостраненный сейчас) способ — напрямую записать предикаты и заставить компилятор их проверять, и плевать на инкапсуляцию (очень аморально, гы-гы)
В качестве примера, предоставление доступа к внутренностям в режиме только для чтения никак не может повредить состоянию объекта, и тем не менее инкапсуляция в таком случае сомнительна.
беря твое же упоминание про капсулу (я с ним согласен) — капсула может быть прозрачной, и это инкапсуляции не вредит
вообще речь у нас о терминах, и там могут быть разные мнения — вон википедия пишет, что не все разделяют деление на инкапсуляцию и information hiding
но мой пойнт в том, что инварианты нужны железно (в смысле обязательно), а вот information hiding может быть под вопросом
скажем, если мы проектируем тип Time с обычными операциями Time::get_year(), Time::set_year(int), ... Time::get_second(), Time::set_second(int), то можно и позволить например time.set_second(100500), которая будет переводить секунды в минуты, часы и т.п. и добавлять их тоже, а не только ставить секунды (примерно как в ui андроида)
но обязательно get_second() после этого не должна возвращать 100500 — это будет нарушением инварианта
а теперь information hiding — нужно ли предоставлять get_seconds_since_epoch(), где эпоха не юниксовая, а некая своя? можно *спорить* на тему, что этот метод выдает наружу деталь реализации — именно спорить
еще пример: пусть нам нужен класс Point { float x; float y;} про который известно, что x и y имеют точность существенно ниже аппаратного float
и как ты будешь скрывать деталь реализации — а именно, последние мусорные биты float-а? скорее всего, никак
да, можно наколбасить на шаблонах imprecise_float, но у него *все* операции будут ровно те же, что и у обычного float-а
Исходная версия www_linux_org_ru, :
я тут со всеми на ты общаюсь (в обе стороны)
Ещё напишите, что инкапсуляция - это возможность выдать качественный продукт вовремя. Нет, возможность обеспечения соблюдения инварианта - это следствие инкапсуляции, но не она.
если интересно именно это обсудить — то инкапсуляция это только один из способов обеспечить соблюдение инварианта
другой (мало распостраненный сейчас) способ — напрямую записать предикаты и заставить компилятор их проверять, и плевать на инкапсуляцию (очень аморально, гы-гы)
В качестве примера, предоставление доступа к внутренностям в режиме только для чтения никак не может повредить состоянию объекта, и тем не менее инкапсуляция в таком случае сомнительна.
беря твое же упоминание про капсулу (я с ним согласен) — капсула может быть прозрачной, и это инкапсуляции не вредит
вообще речь у нас о терминах, и там могут быть разные мнения — вон википедия пишет, что не все разделяют деление на инкапсуляцию и information hiding
но мой пойнт в том, что инварианты нужны железно, а вот information hiding может быть под вопросом
скажем, если мы проектируем тип Time с обычными операциями Time::get_year(), Time::set_year(int), ... Time::get_second(), Time::set_second(int), то можно и позволить например time.set_second(100500), которая будет переводить секунды в минуты, часы и т.п. и добавлять их тоже, а не только ставить секунды (примерно как в ui андроида)
но обязательно get_second() после этого не должна возвращать 100500 — это будет нарушением инварианта
а теперь information hiding — нужно ли предоставлять get_seconds_since_epoch(), где эпоха не юниксовая, а некая своя? можно *спорить* на тему, что этот метод выдает наружу деталь реализации — именно спорить
еще пример: пусть нам нужен класс Point { float x; float y;} про который известно, что x и y имеют точность существенно ниже аппаратного float
и как ты будешь скрывать деталь реализации — а именно, последние мусорные биты float-а? скорее всего, никак
да, можно наколбасить на шаблонах imprecise_float, но у него *все* операции будут ровно те же, что и у обычного float-а