Я пишу метод, который является частью открытого интерфейса Java-класса. Он широко позволяет вызывающей стороне указывать значения, назначаемые ряду объектов базы данных, поэтому они должны предоставлять как идентификаторы самих объектов, так и значения, назначаемые им.
Я колеблюсь между реализацией этого как List<Pair<Integer, Integer>> или просто двумя List<Integer> аргументами. Оба, очевидно, будут работать , и ни один из них не вызовет проблем с реализацией или эффективностью в моем методе. В любом случае это в основном одна и та же информация (массив 2xn ), только чередующиеся по-разному.
Так что я хотел бы высказать несколько мнений о том, какое из них, по вашему мнению, будет лучше, и почему.
Преимущества списка пар, которые я вижу до сих пор:
- Более точно отражает фактические отношения между сущностями
- Устраняет некоторые классы динамических ошибок (например, несоответствующие длины списка)
Преимущества для пары списков:
- Не полагается ни на какие классы, не относящиеся к JDK (просто, как
Pair - концепция)
- Не требует строительства каких-либо вспомогательных объектов только для переноса данных вокруг
- В любом случае, вызывающие абоненты чаще имеют аргументы в отдельных списках, поэтому им не нужно перестраивать данные перед вызовом метода
Оба случая имеют одинаковую безопасность типов, а также одинаковую возможность несоответствия аргументов (например, ввод значений первым и идентификаторов секунд, когда это должно быть наоборот). Эту последнюю проблему можно избежать, создав тривиальную обертку вокруг Integer, называемую чем-то вроде PrimaryKey, которая имеет свои плюсы и минусы и в любом случае ортогональна этой проблеме, так как ее можно использовать одинаково в обоих случаях.
Тем не менее, существует золотая середина, которая может быть третьей опцией - тривиальный контейнерный класс с целочисленными полями для objectId и value. Это не требует помощи компилятора в обеспечении правильности объектов посредством ввода, но обеспечивает дополнительный уровень безопасности в назначениях. Я не думаю, что я бы пошел на это, так как мне не нравится идея загрязнения публичного интерфейса таким тривиальным классом, как этот.