Я понял, что не вижу архитектурной разницы между двумя определениями классов: 






Класс должен иметь список объектов и некоторые свойства, присущие только всему списку.

У двух классов есть, конечно разница в том, что экземпляр `obj' первого класса можно передать в метод аля setSomeData((ArrayList)obj), но если все свои обработчики переписать только через геттеры: 



,то вроде бы и разницы нет.

Второе определение как-то более прозрачно...

Это сообщение отредактировал(а) Andrey1 - 8.5.2009, 13:01

а как же инкапсуляция )

По моему первый вариант предпочтительнее. Но стоит сделать его дженерик, а не привязыватся к обджекту.

Это сообщение отредактировал(а) SoulKeeper - 8.5.2009, 13:44

А чего с ней не так?

В первом случае у Вас фиксированная релизацация списка как ArrayList.
Во втором случае Вы можете поменять её на LinkedList или что Вам угодно.
Во втором случае можно добавить implements List<Object>, чтобы получить преимущества первого варианта.

Есть мнение, что ответ на этот вопрос может зависеть от области применения этого класса. 

Например, надо сделать класс-модель таблицы JTable. Допустим все необходимые методы вроде getRowCount, getElementAt и т.п. реализованы. Но теперь надо приделать методы, которые позволят классу-эксплуататору модели вносить в нее изменения (добавление/удаление строк, например). Казалось бы, в этом плане расширение класса (например, как в Вашем примере, ArrayList) только на пользу, ведь все эти методы уже будут определены. Но ведь после любого внесения изменения надо оповещать об этом таблицу, а значит придется тщательно все методы меняющие данные перегружать и писать в них вызов super + fireXXX. Таким образом, кода придется написать больше, чем во втором случае, да еще и можно что-то пропустить.

вообще правильно было сказано все зависит от области применения )


вот к примеру хотим мы реализовать очередь (ну или стек) с помощью List ... и сделать это можно как первым, так и вторым способом..
но в первом случае у нас будет куча методов которые нам не нужны (например get(int index)), а во втором будет доступно всего три метода к примеру get(), put(Object o), clear()

другой вариант: нас не устраивает количество функционала в ArrayList (то есть нужно все что есть + еще к примеру выборка всех элементов через один ( вот в такой ситуации конечно лучше делать extend

Как по мне, лучше всего будет использовать второй вариант + если необходимо реализовывать интерфейс Collection или List. А если уже и наследоваться, то рассмотреть использование AbstractList или AbstractCollection в качестве базового класса. Хотя, как было уже сказано, все зависит от задачи.

Да, все [в этом мире] зависит от задачи .
Проблема в том, что как правило в момент описания класса точная задача еще не ясна.
Для себя я сделал вывод, что если этот новый класс не нужно встраивать в существующий код, где требуется ArrayList<?> и не требуется именно расширение ArrayList<?>, то лучше использовать второй класс.




Это сообщение отредактировал(а) Andrey1 - 13.5.2009, 11:27

вот и пришли снова к инкапсуляции