Использовать вложенные genericized наборы или пользовательские промежуточные классы?
Попробуйте следующий запрос: это ваш запрос, но он немного изменен для целей тестирования (он не использует таблицу ABC и генерирует только 10 строк, используя предложение CONNECT BY LEVEL <= 10 - но вы можете заменить 10 на 1000)
WITH My_Query As (
select random_group, count(random_group) as freq
from
(select case when rand_num >= 0 and rand_num<=0.053 then 1
when rand_num > 0.053 and rand_num <= 0.097 then 2
when rand_num > 0.097 and rand_num <= 0.142 then 3
when rand_num > 0.142 and rand_num <= 0.189 then 4
when rand_num > 0.189 and rand_num <= 0.234 then 5
when rand_num > 0.234 and rand_num <= 0.281 then 6
when rand_num > 0.281 and rand_num <= 0.341 then 7
when rand_num > 0.341 and rand_num <= 0.399 then 8
when rand_num > 0.399 and rand_num <= 0.458 then 9
when rand_num > 0.458 and rand_num <= 0.515 then 10
when rand_num > 0.515 and rand_num <= 1.000 then 11 end
random_group
from
(SELECT dbms_random.value(0,1) AS rand_num,
rownum as at_row_num
FROM dual
CONNECT BY LEVEL <= 10))
group by random_group
order by random_group
)
SELECT * FROM (
SELECT level as test_number FROM dual
CONNECT BY LEVEL <= 100
) row_generator,
LATERAL (
SELECT * FROM My_Query WHERE row_generator.test_number = row_generator.test_number
) x
;
Кстати: этот пункт WHERE row_generator.test_number = row_generator.test_number представляется излишним, но без этого вы получите неправильные результаты - одни и те же записи повторяются 100 раз вместо случайных данных для каждого теста.
7 ответов
2 лучше потому что:
- Меньше кода выполняет тот же эффект (лучше, на самом деле, как в № 1 часть Вашей информации о типе существует только в комментариях),
- Абсолютно ясно, что продолжается.
- Ваши ошибки типа будут зафиксированы во время компиляции.
Что там для рекомендации 1? по общему признанию Карта <Целое число, <Карта <Строка, <Карта <... дженерики немного тверды привыкнуть к, но к моему глазу намного легче понять, чем код с картами и списками карт, и карт списков карт и пользовательских объектов, полных списков карт.
Комбинация двух. В то время как можно использовать дженерики для замены пользовательских классов, Вы все еще захотите использовать класс для инкапсуляции понятий. Если Вы просто передаете карты карт карт списков ко всему, кто управляет тем, что можно добавить? кто управляет тем, что можно удалить?
Для содержания данных дженерики являются большой вещью. Но Вы все еще хотите, чтобы методы проверили, когда Вы добавляете торговлю или добавляете учетную запись, и без некоторого класса, переносящего Ваши наборы, никто не управляет этим.
Обычно также будет некоторый код для работы на наборы. Когда это становится нетривиальным, я упаковываю набор с поведением в новом классе. Чем глубже вложение, тем более вероятно это будет иметь место.
Я думаю, что ответ на это - то, что это зависит от ситуации. Обычно представление типа полезно, если это также представляет методы, связанные с типом, если те промежуточные типы розданы независимо и т.д.
Вы могли бы найти этот совет от Богатого Пятна (создатель Clojure) о создании совместимых библиотек довольно интересный:
Это предназначается как определенный совет устройствам записи библиотеки Clojure, но я думаю, интересная пища для размышления даже в Java.
Я думаю, что лучше иметь в виду объекты и подчеркнуть наборы немного меньше. Материализация является Вашим другом.
Например, естественно иметь объекты Студента и Курса при моделировании системы для школы. Где классы должны быть получены? Я утверждал бы, что они принадлежат объекта, где Студент и Курс встречаются - ReportCard. У меня не было бы GradeCollection. Дайте ему некоторое реальное поведение.
Я предпочитаю № 2. Более ясно, что продолжается и безопасно с точки зрения типов во время компиляции (я предпочитаю иметь как можно больше вещей, идут не так, как надо, во время компиляции, в противоположность наличию их происходят во времени выполнения... в целом мне нравится он, когда ничто не идет не так, как надо).
Править:
Хорошо существует два способа, которыми я вижу... Я предполагаю, что это зависит, на котором Вы использовали бы:
class Account
{
private Map<Region, TradeCollection> tradesByRegion;
}
class TradeCollection
{
private Map<Instrument, Trade> tradesByInstrument;
}
или
class Account<R extends Region, I extends Instrument, T extends Trade, C extends TradeCollection<I, T>>
{
private Map<R, C> tradesByRegion;
}
class TradeCollection<I extends Instrument, T extends Trade>
{
private Map<I, T> tradesByInstrument;
}
Я сделал это простое правило для меня: Никогда, чем два <и две запятые в объявлении дженериков и предпочтительно только одна запятая. После этого я представляю пользовательские типы. Я думаю, что это - точка, где удобочитаемость страдает достаточно для гарантирования дополнительных понятий.
Существует очень хорошая причина избежать слишком глубоких дженериков: сложность не находится только в фактическом объявлении, но и обычно имеет тенденцию быть одинаково видимой в логике конструкции. Таким образом, много кода имеет тенденцию стать замысловатым при вложении этих объявлений слишком глубоко. Создание промежуточных классов может помочь много. Прием должен часто находить надлежащие промежуточные классы.
Я определенно думаю, что необходимо пойти небольшой бит назад к старому стандарту. На самом деле Ваш второй образец является точной болевой точкой, где я все еще принял бы только для дженериков.