клон () по сравнению с конструктором копии по сравнению с методом фабрики?
Я знаю эту проблему и столкнулся с нею прежде. Для начала, двойной механизм запроса, где это делает те же ИЗБРАННЫЕ условия, действительно не оптимален. Но, это работает, и прежде чем Вы уйдете и сделаете некоторое гигантское изменение, просто поймете, что это не могло бы стоить того.
, Но, так или иначе:
1), Если Вы имеете дело с маленькими данными по стороне клиента, используйте реализацию набора результатов, которая позволяет Вам установить курсор до конца набора, сместить его строку, затем сбросить курсор к прежде сначала.
2) Модернизация запрос так, чтобы Вы получили КОЛИЧЕСТВО (*) как дополнительный столбец в нормальных строках. Да, это содержит то же значение для каждой строки, но это только включает 1 дополнительный столбец, который является целым числом. Это - неподходящий SQL для представления агрегированного значения с не агрегированные значения, но он может работать.
3) Модернизация запрос для использования предполагаемого предела, подобного тому, что упоминалось. Используйте строки на страницу и некоторый верхний предел. Например, просто скажите что-то как "Показ 1 - 10 из 500 или больше". Когда они просматривают к "Показу 25o к 260 из X", это - более поздний запрос, таким образом, можно просто обновить эти X оценок путем создания верхней границы относительно страницы * строки/страница.
5 ответов
Basically, clone is broken. Nothing will work with generics easily. If you have something like this (shortened to get the point across):
public class SomeClass<T extends Copyable> {
public T copy(T object) {
return (T) object.copy();
}
}
interface Copyable {
Copyable copy();
}
Then with a compiler warning you can get the job done. Because generics are erased at runtime, something that does a copy is going to have a compiler warning generating cast in it. It is not avoidable in this case.. It is avoidable in some cases (thanks, kb304) but not in all. Consider the case where you have to support a subclass or an unknown class implementing the interface (such as you were iterating through a collection of copyables that didn't necessarily generate the same class).
Один из шаблонов, который может сработать для вас, - это копирование на уровне bean-компонента. В основном вы используете конструктор без аргументов и вызываете различные сеттеры для предоставления данных. Вы даже можете использовать различные библиотеки свойств bean-компонентов, чтобы относительно легко устанавливать свойства. Это не то же самое, что выполнение clone (), но для многих практических целей это нормально.
There is also the Builder pattern. See Effective Java for details.
I don't understand your evaluation. In a copy constructor you are fully aware of the type, why is there a need to use generics?
public class C {
public int value;
public C() { }
public C(C other) {
value = other.value;
}
}
There was a similar question recently here.
public class G<T> {
public T value;
public G() { }
public G(G<? extends T> other) {
value = other.value;
}
}
A runnable sample:
public class GenTest {
public interface Copyable<T> {
T copy();
}
public static <T extends Copyable<T>> T copy(T object) {
return object.copy();
}
public static class G<T> implements Copyable<G<T>> {
public T value;
public G() {
}
public G(G<? extends T> other) {
value = other.value;
}
@Override
public G<T> copy() {
return new G<T>(this);
}
}
public static void main(String[] args) {
G<Integer> g = new G<Integer>();
g.value = 1;
G<Integer> f = g.copy();
g.value = 2;
G<Integer> h = copy(g);
g.value = 3;
System.out.printf("f: %s%n", f.value);
System.out.printf("g: %s%n", g.value);
System.out.printf("h: %s%n", h.value);
}
}
What you are missing is that clone creates shallow copies by default and convention, and that making it create deep copies is, in general, not feasible.
The problem is that you cannot really create deep copies of cyclic object graphs, without being able to keep track what objects have been visited. clone() does not provide such tracking (as that would have to be a parameter to .clone()), and thus only creates shallow copies.
Even if your own object invokes .clone for all of its members, it still won't be a deep copy.
Java doesn't have copy constructors in the same sense that C++ does.
You can have a constructor which takes an object of the same type as an argument, but few classes support this. (less than the number which support clone able)
For a generic clone I have a helper method which creates a new instance of a class and copies the fields from the original (a shallow copy) using reflections (actually something like reflections but faster)
For a deep copy, a simple approach is to serialize the object and de-serialize it.
BTW: My suggest is to use immutable objects, then you won't need to clone them. ;)