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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

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

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

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

Ответ 5

Две причины.

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

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

Ответ 6

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

Частные члены представляют данные, а общедоступные методы представляют поведение.

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

из-за языков, например, где у вас есть @ChrisF, говорит → таких, как языки интерпретации, Python является видным

Ответ 11

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

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