SELECT c.id
, c.name
, c.folder
, cs.num_users active_members
, cs.num_videos
FROM campaign c
JOIN campaign_stats cs
ON cs.campaign_id = c.id
JOIN (SELECT _c.id
, _c.name
FROM campaign _c
WHERE _c.type = 9) t_c
ON t_c.id = c.id
WHERE c.id IN (1,2,3)
AND cs.num_videos > 10
Это работает довольно хорошее для нас.
Этот фактический запрос не имеет большого смысла, так как я пытался создать его быстро как пример..., но это не точка.
в начале новых строк помогают создать динамические запросы:
$sql .= ", c.another_column"
все остальное просто.
У Стива Йегге есть забавная статья о синглтонах, в которой в этой цитате упоминаются подклассы:
Затем есть вещь о подклассах. Практически невозможно создать подкласс Синглтон, и если получится, то вам не следовало использовать Синглтон в первую очередь. Вы даже не хотят туда идти. Я шел по дорогам, которые я не смею перечислять. Просто представь, что не можешь этого сделать, и ты сэкономишь себе удивительные суммы боли.
На самом деле, я не думаю, что это возможно.
Вы создаете синглтон класса, объявляя его конструктор (-ы) как закрытый
. Но если вы затем попытаетесь объявить подкласс своего одноэлементного класса, конструктор подклассов не сможет увидеть конструкторы суперкласса ... поэтому они не будут компилироваться; Например,
public class A () {
private A() { }
}
public class B () {
private B() { }
}
Как Sun JDK 1.6, так и компилятор Eclipse Ganymede выдают ошибку компиляции в конструкторе B, в результате чего конструктор без аргументов для A не отображается.
Вы можете увеличить видимость private
, но тогда ничто (кроме здравого смысла) не мешает кому-то создать несколько его экземпляров. Другими словами, это больше не одноэлементный класс.
EDIT: Я предполагаю, что кошерной альтернативой было бы определить дерево из одного или нескольких абстрактных (не одноэлементных) классов с методами / членами, которые вы хотите сделать общими, а затем определить несколько одноэлементных классов как листовые классы по мере необходимости. Но это НЕ один одноэлементный класс, являющийся подклассом другого.
Обычно вы не можете, в любом полезном смысле. Это было бы еще одной причиной не использовать классы Singleton.
Если вы определили свой синглтон как:
public class Singleton {
private static Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
private Singleton() {
}
}
Тогда вы можете просто сделать:
public class NewSingleton extends Singleton {
}
Но вы не сможете использовать частные методы, поэтому, если вы хотите использовать singleton, вам все равно нужно будет вызвать Singleton.getInstance ();
, поэтому вы ничего не получите, расширив его.
Но нет причин, по которым вы не можете этого сделать.
Теперь, если если вы хотите добавить больше функций в класс Singleton, тогда вы можете использовать межтиповые аспекты из AspectJ и просто внедрить новые методы / свойства в Singleton, которые затем могут использоваться Singleton.
Синглтон ограничивает экземпляры, а не наследование. Что ж - как уже отмечалось, это ограничивает полезность наследования, и затем вы можете ослабить частный конструктор до упакованного или защищенного (что, как вы можете утверждать, уменьшает синглтон синглтона). Но какова цель?
Как уже ответили другие, использование одноэлементного подкласса невелико. Если вам нужен шаблон стратегии в контексте синглтона, вы можете определить интерфейс и делегировать реализацию этого интерфейса в экземпляре синглтона. Это сдвигает проблему на один уровень ниже и проясняет, почему вы хотите это сделать.
Чтобы ответить на ваш вопрос; предполагая, что выбор для конкретного подкласса, используемого вашим приложением, определен, например, в системных свойствах, вы можете сделать что-то вроде:
public static synchronised Singleton getInstance() {
if (instance == null) {
String clsName = System.getProperties().getProperty("singleton.class");
if (className == null || 0 == clasName.length()) {
instance = new Singleton();
} else {
Class cls = Class.forName(clsName);
instance = (Singleton) cls.newInstance();
}
}
return instance;
}
Отказ от ответственности: непроверенный код, добавление обработки исключений и т. д .:-)
Кстати, убедитесь, что ваш метод getInstance ()
синхронизирован.