Почему не делает Наборов Java, API включает реализацию Графика?
Я в настоящее время изучаю Наборы Java API и чувство, у меня есть хорошее понимание основ, но я никогда не понимал, почему этот стандартный API не включает реализацию Графика. Эти три базовых класса легко понятны (Список, Набор и Карта), и все их реализации в API главным образом просты и последовательны.
Рассматривая, как часто графики подходят как потенциальный способ смоделировать данную проблему, это просто не имеет смысла мне (возможно, что это действительно существует в API, и я не смотрю в правильном месте, конечно). Steve Yegge предлагает в одном из его сообщений в блоге, чтобы программист рассмотрел графики сначала при принятии за решение проблемы, и если проблемная область не соответствует естественно этой структуре данных, только затем рассматривает альтернативные структуры.
Мое первое предположение - то, что нет никакого универсального способа представить графики, или что их интерфейсы не могут быть достаточно универсальными, чтобы реализация API была полезна? Но если Вы разделяете вниз график к его основным компонентам (вершины и ряд краев, которые соединяют некоторых или все вершины), и рассмотрите способы, которыми обычно создаются графики (методы как addVertex (v) и insertEdge (v1, v2)), кажется, что универсальная реализация Графика была бы возможна и полезна.
Спасибо за помощь мне понять это лучше.
1 ответ
Обратите внимание, что в структуру сбора включены некоторые специальные графы, в частности связанные списки и деревья.
Это также указывает на возможную причину отсутствия общей реализации Graph: поскольку графы могут иметь очень много разных форм и разновидностей с совершенно разными характеристиками, общий Graph может оказаться не очень полезным.
Кроме того, по крайней мере, до сих пор в моей практике я не чувствовал потребности в графиках большую часть времени. Некоторым доменам они, безусловно, нужны, а многим просто нет. (Из более чем дюжины проектов в различных областях, в которых я участвовал до сих пор, я перечисляю два, которые действительно нуждались в графиках.) Так что я полагаю, что со стороны Java-сообщества в целом не было большого давления, чтобы иметь Graph в коллекции. Фреймворк. Он содержит только самое основное, что нужно «почти всегда», «почти каждому». И действительно, одна из его сильных сторон - это (относительная) простота и ясность, которые, как я полагаю, разработчики считают ценным достоинством, которое необходимо сохранить.