Как правильно называть пакеты?
 

Меня давно преследует злой рок связанный с именами пакетов.
Есть пакет содержащий классы-задания и первое, что приход в голову, назвать пакет task ли tasks.
Но если я сделаю так, то во всем пакете я не могу использовать эти слова при названии свойст, так-как
FD не понимает к чему я обращаюсь и выкидывает ошибку. И хорошо если название состоит из двух слов,
то я пишу слово_слово, но с одним словом мне приходится что-то дописывать, а именно package.
Типа task_package. Но чтобы потом везде была гармония, то мне приходится во всех именах использовать слово package.
В общем, как Вы называете и избегаете ошибок связанных с названием пакета и свойства?

Пакет – tasks, потому что там их много.
Задача – task – единственное число.
Если класс-контейнер, который содержит много разных – то TasksGroup/TasksContainer.
Класс всегда должен быть единственным числом.

Да, но мне нужно создать массив задач и название тоже будет tasks... И это уже ошибка.
Или писать allTasks?

пакет com.sitename.tasks
А массивам придумывать другие названия. Это уже второстепенно.

caseyryan, я от Вас так часто слышу слово "конвенция", что ответить на немного "непотемный" вопрос, попрошу Вас - есть ли какая-то конвенция, которая придумана специально для protected или internal свойств, для которых нужно создать геттер-сеттер? Если переменная privatе, то тут все просто.. Но как быть с другими модификаторами... Не подчеркивать же.
И если я не ошибаюсь, то некоторое время назад Вы уже делились ссылкой на русскоязычную конвенцию,
но я не смог найти её не в гугле не на форуме. Если можно, поделитесь пожалуйста.

А что со свойствами protected и internal? Их названия пишутся с маленькой буквы, без подчеркиваний. Зачем ставить геттеры и сеттеры для таких свойств? Если нужен протектед или интёрнал геттер, то делаем приватную переменную, а для геттера / сеттера задаем модификатор protected или internal вместо public

LifeIsRhythm, вы придумываете себе проблемы на пустом месте.

Есть класс, назову его класс А, который объединяет работы множества других классов.
Этот класс стал сложен для понимания и я разбил его при помощи "наследства" на подклассы.
И получается так, что свойства идут по мере их важности от супер-класса до самого последнего, public класса. И естественно, что большинство свойств protected, да и вообще, если углубится в понятия ОПП,
то private свойства считаются неОчень, так-как ставят крест на расширении...
И вот если бы мне не было тяжело понимать этот код, то сделал бы с приватными свойствами и создал бы геттеры-сеттеры. Но получилось по другому и я решил посоветоваться... Но если ответ, это общение интернал-наследников через геттеры и сеттеры, то это кажется немного странным... Нет?

Кто эту чушь придумал? ) Впервые слышу, что private свойства считаются "не очень". Не надо так углубляться, а то утонуть можно :D

Абсолютно не понимаю в чем проблема, и вообще о чем речь. Если не нужны геттеры сеттеры для internal / protected свойств, то делаем их просто переменными. Если нужны, то делаем так:
И где тут что плохого в приватной переменной?

Антипаттерн - Наверное, я плохо объяснил... Свойства у меня protected, так-как они используются в классах-наследниках, но для них нужно сделать геттеры. Понимаете, для protected свойств - геттеры, public геттеры. И по этому я и спросил, как в таких ситуациях должны выглядеть сами protected свойства? Они же не могут быть с подчеркиванием, а это означает, что нужно придумывать какую-то приставку или ещё что-то, чтобы имя с геттером не совпадало. Вот я и поинтересовался, есть ли упоминание об этом в конвенции.

taskArray

Могй голос уходит за tasksList.

taskList тогда уже

Я наконец-то кажется понял о чем речь. В этом случае их можно сделать private и использовать обычные public геттеры (которые так же будут видны потомкам), а для изменения из потомков создать свое пространство имен и в потомках использовать его для полного контроля над свойствами, но при этом извне можно будет только получать их значения через публичные геттеры. Это вполне обычный подход, который используется во многих фреймворках. Но никаких дополнительных приставок придумывать не нужно.

И к чему городить огород, если можно просто объявить их protected?
По поводу оформления — я просто ставлю прочерк как и для private. Для меня главное пометить, что это свойство недоступно извне и является "личным" для экземпляра. Для данного класса в цепочке наследования оно по-сути тот же самый private, разница есть только при анализе самой цепочки наследования, да и то... нет, ну на самом деле — Вы ведь все-равно не сможете в наследнике обращаться к private суперкласса. То есть, в коде класса-наследника не будет этих переменных суперкласса, так зачем выдумывать какие-то особые приставки чтобы отделить protected от того, чего вообще нет в коде? (разве что свои собственные private наследника, но сколько их может быть?). Не усложняйте правила игры — конвенции нужны для упрощения, а не усложнения разбирательства с кодом.

Чтоб было красиво)
Но, по большому счету, для своих проектов даже protected свойства не нужны. У меня еще ни разу не было случая, где их использование было реально необходимо. Все делалось исключительно из соображений "красоты" кода. Ведь использование _ на свойствах protected и private одновременно, ничем не лучше объявления свойства как public.

Наследование вообще не очень богато в AS3, обычно рекомендуется использовать композицию. Если посмотреть на другие языки, то да, там ради каждого нового свойства готовы создать новый класс (тех же GoF приходится постоянно интерпретировать хотя бы в интерфейсы, обилие наследований бросает в дрожь). Флэш таки ограничен размером предоставляемой памяти, да и профессиональным уровнем разработчиков тоже))) Я пользовался protected довольно массированно, однако это был, не побоюсь этого слова, настоящий хардкод — у меня была базовая кнопка и несколько ее наследников, отличающихся только цветом. Цвета и были захардкодены в protected-свойствах: я не собирался давать публичный доступ к цветам, но мог довольно быстро состряпать нового наследника, если понадобится какая-то серобуромалиновая кнопка — весь код наследника и состоял только из инициализации цветов. Ну и как бы ежу понятно, что это такой архитектурный бзик и можно сделать все совсем по-другому. Но меня такой вот простой и этим "красивый" вариант более чем устроил в условиях того проекта (набор контролов для быстрой сборки интерфейсов тестирования).

Понимаю, что вырываю из контекста, но ради интереса сейчас посчитал: на проекте используется 585 переопределенных защищенных методов (без учета сторонних библиотек) :)
На самом деле зря вы их так.
Использование в паре public final и protected override методов бывает очень удобно и полезно.

ChuwY - мы с Костиком синглтоны, у нас не командная игра, поэтому и протектед нет. У нас с вами просто разные пути и соотвественно разный код

Да, именно, из контекста. Я же сказал, что для своих проектов можно без них обойтись, просто заменив на паблики. Все будет так же работать.
И я не сказал, что это не удобно. Я сказал, что без них можно обойтись, так же как можно обойтись без mvc, например.
Я лично использую protected свойства, но мне редко бывает нужно делать для них public геттеры, хотя, такую ситуацию можно легко представить

Упс. Перечитал конец ветки и понял, что тут вообще говорили про свойства, а не методы.
Каюсь, каюсь :) защищенные свойства, что в лично моем коде, что в тех местах, где работаю, встречаются куда реже, чем методы.
А паблик геттер для них, пожалуй, даже не припомню приходилось ли хоть раз писать.