Стиль реализации статического класса

[maxkar]

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

Ну и правильно. Потому что наследование от "Abstract Singleton" очень плохо соотносится с LSP (Liskov substitution Principle). Наследование - это реализация отношения is-a. Представить себе что-то, работающее с Singleton - практически невозможно. А вот фабрику для упрощения вполне можно сделать. Она даже и методом может быть public static const getInstance : Function = createLazy(MySingleton.class). В AS3 правда при этом типизация потеряется. Если язык поддерживает макросы (или что-то высокоуровневое), можно и генерировать аксессоры по аннтоациям на классе, например. Но на самом деле там проще аннотации для контейнера развесить вместо singleton'а (см. google guice, например, spring тоже вроде бы так умеет, но это все java-библиотеки).

Добавлено через 13 минут

Вероятно, параметром вы называете примитивное значение. Это не так. Параметром функции вполне может являться и ссылка. Так что тут "вместо" совершенно непотребно. Я даже понимаю, что вы передаете ссылку на класс, а не на объект класса, верно?

Не, не верно. Согласен, формулировка у меня плохая получилась. Имелась в виду транзитивная передача. Вместо

public function SomeClass(arg : String) {
  this.someField = new SomeOtherClass(arg);
}

стоит получать сразу зависимость:

public function SomeClass(arg : SomeOtherClass) {
  this.someField = arg;
}

Так можно не всегда. Иногда в качестве SomeOtherClass выступает деталь реализации (класс с internal обслатью видимости, например). Но в таких случаях имеет смысл вместо конструктора рассматривать "creation method" (он же - фабричный метод), который получает параметры и создает требуемый экземпляр. Для сложных экземпляров все их зависимости так же будут внутри этого метода создаваться "снизу вверх". Причина для создания creation method здесь не столько в правильном построении зависимостей (сам класс в конструкторе это тоже может сделать) а разделение ответственностей: сам класс отвечает за свою функцию среди нескольких взаимодействующих классов, а за правильную настроку отвечает статический метод. В подобных случаях обычно еще достаточно велика вероятность, что потребуются создание того же класса с другими настройками, от других типов аргументов и т.п. С "creation method" это делается проще и однообразно для всех созданий.

Добавлено через 1 час 10 минут

Сообщение от wvxvw

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

Так можно же передать и саму функцию. Да, потеряем типизацию, но не будет лишнего интерфейса. На самом деле даже если в языке у нас будет строгая типизация функций, это не сильно поможет делать все чистыми функциями. И проблема здесь будет уже в "чистоте интерфейса". Большинству потенциально "грязных" функций для работы нужен контекст. Для базы данных - адрес соединения с базой данных. Для логгера - настройки логирования, файл для записи и т.п. Необходимость передачи этих параметров явно влияет на интерфейс. Допустим, мы пишем доступ к каким-то данным. Интерфейс в терминах объектов (getSettings...). Объекты только читаются, и мы хотим добавить кэширование и следить за его эффективностью. Чтобы сделать это на чистых функциях, везде нужно передавать контекст - контекст кэша, контекст базы данных, контекст статистики кэша. Соответственно, все пользователи должны иметь этот контекст только для того, чтобы вызывать наш метод. Инкапсуляция состояния позволяет сделать метод с "чистым" интерфейсом вроде getData(параметры). Попытки сделать композицию статических функций чтобы получить требуемый интерфейс приведут к появлению "грязных" замыканий. Проблема инкапсуляции на чистых функциях не решается никак и нигде. Либо появляются "грязные" функции, либо везде ходит нужный тип. В том же haskell'е функции доступа будут работать с "полиморфным" типом а в собранном приложении у передаваемого параметра будет жуткий-жуткий тип (несколько модандных трансформеров вокруг друг-друга).