Зачем ставить частные поля и методы в верхней части класса?

Question

Я видел этот де-факто стандарт во многих местах на многих языках, но я его никогда не понимал - зачем ставить ваши частные поля и методы в начало объявления класса? Метафорически кажется, что личные вещи должны располагаться внизу (скрытые), и все, что должно быть открыто, должно быть наверху, так что, когда вы читаете класс сверху вниз, вы сначала видите публичный интерфейс, а затем внутреннюю работу.

Какова причина этого?

EDIT: просто для того, чтобы уточнить, я не имею в виду практику объявления всех членов в верхней части класса, но включение частных членов/методов в начало объявления класса, прежде чем что-либо публичное.

Answer 1

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

Внутренние (частные) переменные и функции выполнялись в верхней части файла, а внешние (общедоступные) функции выполнялись в нижней части файла. Это означало, что публичные функции могут ссылаться на внутренние функции. Если у вас была рекурсия, вам придется переслать ссылку на функцию, объявив ее профилем.

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

Answer 2

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

Answer 3

Две причины.

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

На языке C и в javascript все ссылки в коде должны быть объявлены и/или определены выше, на которые они ссылаются, потому что все ссылки должны быть уже известны. (Да, я знаю, только javascript sorta.)

Answer 4

Лично, когда я пытаюсь читать чужой код и понимаю его, мне нравится иметь контекст, который предоставляют частные поля. Это дает мне быстрый взгляд на то, что они делают и что я могу ожидать увидеть. Если все сделано правильно, это может дать хороший предварительный просмотр, почти как оглавление для остальной части кода.

Answer 5

Не секрет, что они там. Вы боитесь, что кто-то узнает о внутренней работе? Если у них есть источник, они могут узнать все, что им нужно знать о вашем классе.

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

Answer 6

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

С другой стороны, это то, что вы действительно не хотите, чтобы другие люди читали, поэтому он принадлежит внизу.

Answer 7

Я думал, что стандарт defacto является общедоступным методом! по крайней мере, так я пишу свои уроки. Это помогает мне выбирать структуры данных для моих методов.

Answer 8

Что касается полей, довольно часто все поля являются закрытыми (инкапсуляция и все такое). И они маленькие. Поскольку они маленькие, приятно и возможно, чтобы собрать их все вместе, а верх класса - хорошее, стабильное место для их размещения. Я не знаю, является ли это историческим оправданием для него - я думаю, что корни языка C, вероятно, объясняют это лучше, но это может быть причиной того, что мы храним их там.

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

Answer 9

Я согласен, что он, вероятно, выходит из C, но он также служит для практической работы.

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

В случае кода ваши общедоступные функции будут обычно ссылаться на внутренние частные, и ваши частные функции с меньшей вероятностью будут ссылаться на публичные (хотя, безусловно, есть перекрытие.) Итак, понимая, какие частные переменные у вас есть и что они используются для использования при попытке понять, что делают публичные методы с этими переменными.

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

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

И, как всегда, нарушение целостности никогда не является хорошей идеей, если нет невероятно веских оснований.

Answer 10

В OOP- есть две вещи - данные и поведение

Частные члены представляют данные и открытые методы представляют поведение.

Вы можете думать о поведении только в свете данных, которые он представляет. Итак - вот почему я хотел бы сохранить элементы данных в верхней части.

Answer 11

из таких языков, как, где у вас есть, как говорит @ ChrisF >> таких как интерпретирующие языки, Python является видное один