Иногда вижу, что в классе сперва определяются функции, а данные — в самом конце. Последний раз обнаружил такое у Yosifovich, в свежей книге "Windows Kernel Programming". Дядьку уж точно нельзя назвать ни начинающим, ни эксцентриком, а поди ж ты. Чем может быть обусловлен столь странный порядок определений? Традиционно везде и всюду сперва определяется "что", и только потом — "зачем" и "как".
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Иногда вижу, что в классе сперва определяются функции, а данные — в самом конце. Последний раз обнаружил такое у Yosifovich, в свежей книге "Windows Kernel Programming". Дядьку уж точно нельзя назвать ни начинающим, ни эксцентриком, а поди ж ты. Чем может быть обусловлен столь странный порядок определений? Традиционно везде и всюду сперва определяется "что", и только потом — "зачем" и "как".
Моё ИМХО: определяется порядком чтения. Читаем слева направо, сверху вниз.
Поэтому сперва видим public интерфейс, что можно дёрнуть, а уже потом то, что скрыто под капотом.
И это правильно.
_____________________
С уважением,
Stanislav V. Zudin
Re: Определение данных класса после определения методов
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Иногда вижу, что в классе сперва определяются функции, а данные — в самом конце. Последний раз обнаружил такое у Yosifovich, в свежей книге "Windows Kernel Programming".
Полностью согласен с описанными практиками. Пользователю класса, в первую очередь, интересен публичный интерфейс, т.е. то, что класс предоставляет. То как он устроен, пользователю обычно не интересно, а в активно развивающемся проекте может еще и 10 раз поменяться. Внутреннее устройство не должно влиять на код взаимодействующий с классом.
Re[2]: Определение данных класса после определения методов
Здравствуйте, Videoman, Вы писали:
V>Пользователю класса, в первую очередь, интересен публичный интерфейс, т.е. то, что класс предоставляет. То как он устроен, пользователю обычно не интересно
На это есть минимум два возражения:
— пользователь класса, по-хорошему, вообще не должен видеть его приватных членов, для чего пользователю передается чистый интерфейс. А разработчику класса всяко нужно помнить, что в нем определено.
— у того же Yosifovich в книге приведены не чьи-то готовые публичные интерфейсы, а прежде всего примеры того, как можно реализовать те или иные концепции. А в примерах важно прежде всего то, на чем класс основан, и как он работает со своими данными, а не интерфейс, который он выставляет на публику.
Re[3]: Определение данных класса после определения методов
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>На это есть минимум два возражения:
ЕМ>- пользователь класса, по-хорошему, вообще не должен видеть его приватных членов, для чего пользователю передается чистый интерфейс. А разработчику класса всяко нужно помнить, что в нем определено.
Не согласен. Разработчику класса вообще по барабану что и где. Он и так знает свой код. Обычно, код пишется один раз, а читает много раз и многими людьми. Если вы работаете один и ваш код никто не читает, то ваше дело что и как размещать. Если вы работаете в команде, то лучше сначала размещать публичный интерфейс, а потом все остальное.
ЕМ>- у того же Yosifovich в книге приведены не чьи-то готовые публичные интерфейсы, а прежде всего примеры того, как можно реализовать те или иные концепции. А в примерах важно прежде всего то, на чем класс основан, и как он работает со своими данными, а не интерфейс, который он выставляет на публику.
В учебной литературе, думаю, лучше сразу прививать полезные практики.
Re[2]: Определение данных класса после определения методов
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Моё ИМХО: определяется порядком чтения. Читаем слева направо, сверху вниз. SVZ>Поэтому сперва видим public интерфейс, что можно дёрнуть, а уже потом то, что скрыто под капотом. SVZ>И это правильно.
Имхо это не очень правильно. То что скрыто под капотом вообще не должно болтаться в определении класса.
Re[3]: Определение данных класса после определения методов
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>- пользователь класса, по-хорошему, вообще не должен видеть его приватных членов, для чего пользователю передается чистый интерфейс. А разработчику класса всяко нужно помнить, что в нем определено.
Очень популярное заблуждение. Для многих классов такой подход не только лишен смысла, но и просто вреден. В стандарной библиотеке полно примеров тому. Полезно почитать эту рекомендацию: 32. Ясно представляйте, какой вид класса вы создаете
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[3]: Определение данных класса после определения методов
Здравствуйте, kov_serg, Вы писали:
SVZ>>Моё ИМХО: определяется порядком чтения. Читаем слева направо, сверху вниз. SVZ>>Поэтому сперва видим public интерфейс, что можно дёрнуть, а уже потом то, что скрыто под капотом. SVZ>>И это правильно. _>Имхо это не очень правильно. То что скрыто под капотом вообще не должно болтаться в определении класса.
Гммм, и какие у нас варианты? Интерфейсы? Пимпл?
Можно, но иногда цена кусается.
_____________________
С уважением,
Stanislav V. Zudin
Re[4]: Определение данных класса после определения методов
Здравствуйте, Videoman,
V> Разработчику класса вообще по барабану что и где. Он и так знает свой код. Обычно, код пишется один раз, а читает много раз и многими людьми.
Угу. Особенно в случаях, когда разработчик класса уволился (уехал в другую страну/заболел/умер/etc.) лет этак пять назад, а у клиента ситуация "Шеф, усе пропало! Гипс снимают, клиент уезжает!" прямо здесь и сейчас.
Как раз для таких случаев в серьезных конторах придуманы Coding standards, нет?
Re[5]: Определение данных класса после определения методов
Здравствуйте, Vlad_SP, Вы писали:
V_S>Угу. Особенно в случаях, когда разработчик класса уволился (уехал в другую страну/заболел/умер/etc.) лет этак пять назад, а у клиента ситуация "Шеф, усе пропало! Гипс снимают, клиент уезжает!" прямо здесь и сейчас. V_S>Как раз для таких случаев в серьезных конторах придуманы Coding standards, нет?
Я как раз об этом и написал. Еще раз, прочитайте внимательно всю ветку, а не выдранную из контекста фразу.