Показать сообщение отдельно
  #7 (permalink)  
Старый 02.12.2013, 01:51
Аспирант
Отправить личное сообщение для Antonius Посмотреть профиль Найти все сообщения от Antonius
 
Регистрация: 30.11.2013
Сообщений: 42

Сообщение от Maxmaxmaximus3 Посмотреть сообщение
В чем недостаток? Рсскажи подробнее? Что мешает создать для них неймспейс префикс или постфикс например "_" ?
Разумеется, если остановлюсь на этом варианте, то так и будет сделано.

Сообщение от kobezzza Посмотреть сообщение
Частая ошибка новичков изучающих ООП: модификаторы видимости private и protected созданы ИСКЛЮЧИТЕЛЬНО для увеличения уровня абстракции и банальной удобности, а не для "сокрытия от злых хакеров".

Я использую классическое соглашение:
_ private
__ protected

и всем советую
Это очевидно же. Дело в другом. Если есть причины сделать метод приватным, то это же не просто так. Например, у него может в будущем поменяться набор или формат параметров или тип/формат возвращаемого значения, он может быть переименован или удален. Да и просто он может выполнять сугубо служебные функции, и «не надо хотеть» использовать его извне. Публично доступен стабильный (хочется надеяться) API,

Но для выбора в моем случае это всего лишь один из «недостатков». Также смущает необходимость использования new. В подобного рода скриптах, рассчитанных на массовое использование, мне подобное требование не встречалась (неопытность? такие библиотеки, скрипты существуют?)

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

Более того, такой способ работает только для функций (ибо функции расшарены для всех экземпляров), а как же быть с приватными свойствами?

Кстати, никто не встречал использование вместо знака «_» знак «$» для приватных свойств/методов?
Наследоваться и перекрывать методы (публичные, разумеется), можно при использовании «паразитного», «фабричного» наследования, разве нет? А менять служебные приватные методы как минимум опасно — на их основе работает остальной код, для чего может потребоваться их изменение (а не доопределение новых)? Ко всем данным (приватным свойствам), которые имеют смысл за пределами объекта, должен быть обеспечен доступ средствами открытого API, не так ли? Что заодно позволит выполнять валидацию и коррекцию ошибочных данных (если это возможно) при доступе к ним. В моем случае геттеры-сеттеры я применять не планирую — поддержка у них для этой задачи неудовлетворительная пока что.

Да, и еще вопрос вдогонку. Те, кто использует классическое прототипное наследование, в каком формате вы присваиваете значение прототипу? Constructor.prototype = { … } или Constructor.prototype.field = …?
Ответить с цитированием