Сообщение Re[8]: Зависимости между классами и интерфейсами от 15.09.2020 20:28
Изменено 15.09.2020 20:44 AlexRK
Re[8]: Зависимости между классами и интерфейсами
Здравствуйте, fmiracle, Вы писали:
ARK>>·> NodeList children;
ARK>>А нельзя так?
ARK>> List<Node> children;
F>Можно-то можно, но это неэквивалентно. NodeList это может быть с одной стороны расширенный относительно List<Node> класс с дополнительными свойствами и методами, а с другой стороны — инкапсулировать способ хранения нод, он может быть совсем не List<T>, или сейчас List, а потом захочется поменять на другой способ, и не хотелось бы отлавливать все вхождения по всему приложению (его применений может быть куда больше чем только в классе Node).
Ну, так можно далеко зайти. Вдруг потом захочется и name чтобы был не string, и size чтоб не int. И поля другие, и методы, и списки аргументов.
Абстрагироваться от всего на всякий случай — это порочная практика, я считаю.
Впрочем, в данном случае вроде бы можно передать тип контейнера через генерик-параметр:
ARK>>·> NodeList children;
ARK>>А нельзя так?
ARK>> List<Node> children;
F>Можно-то можно, но это неэквивалентно. NodeList это может быть с одной стороны расширенный относительно List<Node> класс с дополнительными свойствами и методами, а с другой стороны — инкапсулировать способ хранения нод, он может быть совсем не List<T>, или сейчас List, а потом захочется поменять на другой способ, и не хотелось бы отлавливать все вхождения по всему приложению (его применений может быть куда больше чем только в классе Node).
Ну, так можно далеко зайти. Вдруг потом захочется и name чтобы был не string, и size чтоб не int. И поля другие, и методы, и списки аргументов.
Абстрагироваться от всего на всякий случай — это порочная практика, я считаю.
Впрочем, в данном случае вроде бы можно передать тип контейнера через генерик-параметр:
class Node<Container extends Iterable>
{
string name;
int data;
...
Node<Container> parent;
Container<Node<Container>> children;
Container<Node<Container>> ancestors;
}
class Document
{
Node<List> root;
List<Node<List>> findNodesByName(...);
}
Re[8]: Зависимости между классами и интерфейсами
Здравствуйте, fmiracle, Вы писали:
ARK>>·> NodeList children;
ARK>>А нельзя так?
ARK>> List<Node> children;
F>Можно-то можно, но это неэквивалентно. NodeList это может быть с одной стороны расширенный относительно List<Node> класс с дополнительными свойствами и методами, а с другой стороны — инкапсулировать способ хранения нод, он может быть совсем не List<T>, или сейчас List, а потом захочется поменять на другой способ, и не хотелось бы отлавливать все вхождения по всему приложению (его применений может быть куда больше чем только в классе Node).
Ну, так можно далеко зайти. Вдруг потом захочется и name чтобы был не string, и size чтоб не int. И поля другие, и методы, и списки аргументов.
Абстрагироваться от всего на всякий случай — это порочная практика, я считаю.
Впрочем, в данном случае вроде бы можно передать тип контейнера через генерик-параметр:
Не, похоже в жабе нельзя. Нужны higher-kinded types.
ARK>>·> NodeList children;
ARK>>А нельзя так?
ARK>> List<Node> children;
F>Можно-то можно, но это неэквивалентно. NodeList это может быть с одной стороны расширенный относительно List<Node> класс с дополнительными свойствами и методами, а с другой стороны — инкапсулировать способ хранения нод, он может быть совсем не List<T>, или сейчас List, а потом захочется поменять на другой способ, и не хотелось бы отлавливать все вхождения по всему приложению (его применений может быть куда больше чем только в классе Node).
Ну, так можно далеко зайти. Вдруг потом захочется и name чтобы был не string, и size чтоб не int. И поля другие, и методы, и списки аргументов.
Абстрагироваться от всего на всякий случай — это порочная практика, я считаю.
Не, похоже в жабе нельзя. Нужны higher-kinded types.