Здравствуйте, Jack128, Вы писали:
J>Если я перекрою неявное преобразование типов из B в A, то экземпляр B можно будет передать в любой метод, принимающий A. Значит ли это, что B — наследник A ??? Если нет, то почему?
Нет, так будет сделать нельзя. Потому что вы не сможете передать экземпляр B в любой метод, принимающий A. Вы по-прежнему будете передавать в метод экземпляр А.
Впрочем, язык, о котором вы говорите, разрабатывали не идиоты.
Попробуйте "перекрыть неявное преобразование" и подставить экземпляр B вместо A:

class A
{
   private int _a;
   public virtual void SetA(int a) { _a = a; }
   public virtual int  GetA() { return _a;}
}

void AnyMethod(A& param) // вот вам "любой" метод ;)
{
  param.SetA(42);
  cout << param.GetA();
}

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>"Видит" — это немного не то...
S>>Вместе с тем, модификаторы доступа ограничивают не видимость, а именно доступ.
S>Это понятно. Инкапсуляция — это, конечно же, явление, а не механизм. Однако когда мы говорим о поддержке инкапсуляции в языке, мы ожидаем от компилятора проверки всех этих "я не должен".
Согласен. Когда мы говорим об инкапсуляции в языке мы почемуто подразумеваем разметку доступа членов класса и совершенно упускаем interface/implementation, *.h/*.c, PImpl и другие вещи.

S>Лично моя точка зрения — в том, что в контексте языков программирования рассматривать документацию бессмысленно. С точки зрения документации, все языки обладают одинаковой выразительной силой. Интересны те контракты, которые можно выразить в языке — всё точно так же, как с инкапсуляцией. Контракт как явление существует независимо от языка, но поддержка контрактов всё же требуется.
С тем что модификаторы внесли дополнительное средство выразительности и имеют отношение к самодокументации — я согласен.

S>>Позже при отсутствии документации мы стали пытаться восстанавливать контракт по видимым/публичным артефактам. Но это вовсе не значит что обнаружив публичный метод с названием __не_вызывай_меня_никогда_все_сломается___совсем(), следует его первым делом вызвать.

S>Названия методов — ни о чём. Также как и аргумент с именем pleaseDontPassNullHere.
В отношении инкапсуляции разница между модификатором видимости и соглашением по именованию членов лишь в том, что модификаторы видит компилятор и проверяет правомерность обращения к членам. В отношении скрываемых деталей ничего не изменяется.

S>>Проверка компилятором корректности использования контрактов вторична. Вот возьмем тот же WinAPI. Контракты есть, а модификаторов нет. И компилятор не ограничивает нас от того что бы послать любое сообщение любому Handle-у. Кто скажет что в WinAPI нет инкапсуляции?
S>Инкапсуляция там — в том, что вы не можете напрямую работать с внутренним состоянием контрола. Контракт, выраженный в терминах WinAPI, у всех контролов ровно один — SendMessage().
Я привел WinAPI лишь как пример наличия инкапсуляции при отсутствии проверок видимости компилятором.

S>То, что контролы ведут себя существенно по разному в ответ на разные значения аргументов этого единственного метода "сделайВсё" — это недостаток выразительности в выбранном языке/платформе.
S>Неспроста первое, что делают все ООП-шные UI фреймворки под винапи — это определяют иерархию классов с методами, чтобы отойти от нетимизированного и непроверяемого SendMessage().
Да, при этом выразительность повышается, а инкапсуляция, как правило, уменьшается. Не хочу сказать что предпочитаю WinAPI. Просто наблюдение.

Здравствуйте, kurel, Вы писали:

K>из "Чистый код" Р. Мартина (гл. 3, "Функции"):

K>

K>Структурное программирование

K>Хотя мы с симпатией относимся к целям и методам структурного программирования, в очень компактных функциях эти правила не приносят особой пользы. Только при увеличении объема функций их соблюдение обеспечивает существенный эффект.

самое смешное, что уважаемый Р. Мартин испытывает симпатию к идеям Дейкстры совершенно их не понимая
Идея-то не в том, что от гото избавится без вариантов, а в том, что мы в любом месте кода можем написать слабейшее предусловие того, что программа будет успешна. То есть, попросту говоря, assert...

Дорогой Erop, Вы писали:

E>самое смешное, что уважаемый Р. Мартин испытывает симпатию к идеям Дейкстры совершенно их не понимая
E>Идея-то не в том, что от гото избавится без вариантов, а в том, что мы в любом месте кода можем написать слабейшее предусловие того, что программа будет успешна. То есть, попросту говоря, assert...


Из каких приведенных мною слов Р. Мартина вы заключили, что он их понимает идеи Дейкстры? И где он пишет о том, что от гото избавится нет вариантов?

K>Из каких приведенных мною слов Р. Мартина вы заключили, что он их не понимает идеи Дейкстры? И где он пишет о том, что от гото избавится нет вариантов?

Здравствуйте, kurel, Вы писали:

K>Из каких приведенных мною слов Р. Мартина вы заключили, что он их понимает идеи
Ну он там типа пересказывает "идеи Дейкстры", при этом говорит вообще не о том о чём идеи

Здравствуйте, Erop, Вы писали:

E>Ну он там типа пересказывает "идеи Дейкстры", при этом говорит вообще не о том о чём идеи

Он описание идеи вроде бы не затрагивал, подразумевая, что читатель знаком с ней.
И вроде бы он ясно пишет то, что хотел сказать:
— множественные return \ break \ continue усложняют чтение кода в большой функции, но в компактной функции вариант без множественного return может быть менее выразительным (а Р.Мартин рекомендует писать очень компактные функции, и обосновывает почему, в нескольких главах этой книги)
Пример (хоть и используется java, но будем считать что мы не знаем о конструкции ?:, это ведь всего лишь пример, который первым пришел в голову).

множественные return

int max(int first, int second) {
    if (first > second) {
        return first;
    } else {
        return second;
    }
}

одна точка выхода

int max(int first, int second) {
    int result;
    if (first > second) {
        result = first;
    } else {
        result = second;
    }
    return result;
}

— про goto он пишет, что если кто-то и решит использовать goto в своей программе, то желание использовать goto может возникнуть только в некомпактной функции, а раз к этому моменту Р.Мартин убедил читателя его книги в том, что нужно писать очень компактные функции, то вопрос об использовании goto и не поднимается. Ведь и вправду, зачем использовать goto в функции объемом 3-5 строчек...

Здравствуйте, kurel, Вы писали:

K>- множественные return \ break \ continue усложняют чтение кода в большой функции, но в компактной функции вариант без множественного return может быть менее выразительным (а Р.Мартин рекомендует писать очень компактные функции, и обосновывает почему, в нескольких главах этой книги)

положим это не всегда хорошо. Ну да фиг бы с ним, не о том разговор же.
Я же конкретнонаписал, что смешно:

Хотя мы с симпатией относимся к целям и методам структурного программирования, в очень компактных функциях эти правила не приносят особой пользы. Только при увеличении объема функций их соблюдение обеспечивает существенный эффект

А структурное программирование оно не про конретную функцию, оно про программу в целом. И эффект приносит и в программе оформленной в виде больших функций и в программе обормленной в виде маленьких...

K>множественные return
K>

K>int max(int first, int second) {
K>    if (first > second) {
K>        return first;
K>    } else {
K>        return second;
K>    }
K>}
K>

Ну и это совершенно процедурный и доказуемый код...
Ты тут что конкретно не можешь написать? Постусловие? слабейшее предусловие всей функции? Или какого-то места в функции?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Jack128, Вы писали:
J>>Если я перекрою неявное преобразование типов из B в A, то экземпляр B можно будет передать в любой метод, принимающий A. Значит ли это, что B — наследник A ??? Если нет, то почему?
S>Нет, так будет сделать нельзя. Потому что вы не сможете передать экземпляр B в любой метод, принимающий A. Вы по-прежнему будете передавать в метод экземпляр А.

A a = CreateA(); // мы не знаем как реализована CreateA
по каким признакам я могу понять, что a — это экземпляр B? Только без рефлексии, пожалуйста.

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

Здравствуйте, Ромашка, Вы писали:

Р>Оно всегда прилетит, чудес не бывает. Я не знаю, как это точно называется, я называю это слабо/сильно интегрированными системами. Слабо интегрированные системы это и есть лапша. Замечательный пример — 1Ц. Классический говонокод — вся логика на формах, глобальные переменные и прочие радости. Такой подход дает постоянную (по мере усложнения проекта) цену на добавление нового функционала и быстро растущую стоимость изменения системы. Понятно почему, попытка что-либо изменить приводит к необходимости переписать весь проект. В противоположность этому есть сильно интегрированные системы. Там стоимость добавления нового функционала растет по мере увеличения сложности, а стоимость изменения системы остается постоянной.

Интересная техника — "Такой подход дает постоянную (по мере усложнения проекта) цену на добавление нового функционала и быстро растущую стоимость изменения системы."

Цена изменений вроде постоянная, а стоимость изменений растёт

Здравствуйте, Jack128, Вы писали:

J>A a = CreateA(); // мы не знаем как реализована CreateA
J>по каким признакам я могу понять, что a — это экземпляр B? Только без рефлексии, пожалуйста.
Не понимаю вопроса. Всё зависит от того, какой язык мы рассматриваем.
В С++ а — экземпляр A, а вовсе не B, как бы там ни была реализована CreateA().
В C# в а может оказаться ссылка на экземпляр типа, не совпадающего с A, только в том случае, если этот тип является подтипом A. Я навскидку знаю пять способов объявления A и устройства CreateA, которые позволяют получить в a что-то другого типа (не A), но ни один из них не относится к оператору преобразования типов.

Так что я по-прежнему не вижу способа ввести отношения is-a при помощи оператора неявного преобразования.

S>>Впрочем, язык, о котором вы говорите, разрабатывали не идиоты.
J>Ну мало какие языки на свете есть. Представим условную джаву с перегрузкой преобразования типов, но без ссылок.
Давайте представим, хотя ООП без ссылок не имеет физического смысла.
Покажите мне этот пример на вашей воображаемой джаве.

Здравствуйте, jazzer, Вы писали:

J>Или там "из функции должен быть только один выход", потому что типа Дейкстра доказал, что такие функции лучше — и поэтому начинаются пляски с тем же goto, лишь бы return в середине функции не написать.
Один выход это фигня. Мне для генерации кода функции с несколькими точками входа нужны.
Но в .НЕТ всё жёстко... придётся в натив уходить...

Кстати, McSeem2, по существу вашего поста. Почитайте главу 6 "Объекты и структуры данных" в книге "Чистый код" Роберта Мартина. Глава коротенькая. И размышления Роберта Мартина разумны. Вам должно понравиться.

Здравствуйте, Ромашка, Вы писали:

Р>Ты знаешь... я вот только что переписал с нуля софт, который народ писал четыре года. За две недели. Так вот, самое тупое решение которое работает, является оптимальным.

Здесь как раз ничего удивительного, народ набил шишки, собрал информацию, выработал решение, а ты пришел на готовое. Сколько лет потребовалось на изобретение радио и сколько потрачу его я на пайку приемника-передатчика?

MS>>Все это такое фуфло, я вас скажу эти ваши философии. Так же как и много других умных слов про программирование.
B>Кто-то, судя по всему, неправильно выбрал профессию.
ввиду врожденной бинарности мышления среднего человека (т.е. среднего человека всегда бросает в крайности) обычно встречаются типа программистов:
— те кто пишут код, с той целью чтобы он работал
— те кто пишут код, с той целью чтобы его колупать