Head First OOA & D - реализация свойств в иерархическом дереве объектов

Question

Я сейчас читаю книгу "Head First OOA & D".Есть примеры кода.У меня проблема с принятием следующего решения:

Если в системе существует иерархия сущностей, предлагается использовать карту свойств вместо записи всего дерева классов.

Например: Юнит с картой свойств:

public class Unit {
    private UnitType type;
    private Map<String, Object> properties;
}

Где UnitType - Enum.

Дерево юнитов:

public class Unit {
    private int healthVolume;
}

class Soldier extends Unit{
    private int strength;
}

class Tank extends Unit{
    private int armorAmount;
}

Да, естьАргументы в том, что в первом случае есть возможность без труда добавлять новые юниты и дополнительные классы.Например, в случае, если у меня 100 типов единиц:

Первый случай: мне нужно написать 1 класс.

Второй случай: мне нужно написать как минимум 101 класс.

Но эти String из Map<String, Object> не кажутся хорошими, потому что жесткое кодирование имени свойства не очень хороший стиль.Добавление Enum немного улучшит код, но есть и этот Object, который кажется очень странным, когда вокруг столько дженериков.

У вас есть идеи, как можно улучшить этот дизайн?Спасибо за помощь заранее.

Answer 1

Но это String из Map<String, Object>, похоже, совсем нехорошо, потому что жесткое кодирование имени свойства не подходит.

Вы правы и ложны. Я думаю, что автор (ы) хочет, чтобы вы подумали о дизайне, и в некоторых случаях достаточно не строить длинную иерархию классов. Если вам нужна строгая типизация и доступ к свойствам в стиле getter / setter, тогда использование этой карты свойств - плохая идея. Если вашему клиенту нужна гибкая, легко расширяемая иерархия, не содержащая сложных деревьев наследования, тогда эта карта свойств - это быстрый способ повысить производительность.

И используя иерархию сложного типа метода получения / установки, вы также получаете жестко закодированные имена свойств!