Открытый / закрытый принцип и единая ответственность - графики

Question

Я кодирую программу исследования Графа и столкнулся с небольшим камнем преткновения.

Мой график состоит из Vertex а также NetworkLink объекты, и могут быть получены путем запроса GeographyModel объект.

Идея List<NetworkLink> извлекается из GeographyModel а затем поставляется в MetaMap получить необходимую дополнительную информацию.

То, что я хочу сделать, это попытаться придерживаться принципа Open / Closed, добавляя информацию каждый NetworkLink создавая MetaMap объекты, но в некоторой степени мои трусики в повороте о том, как это сделать!

Ниже приведен код для MetaMap,

public class MetaMap<T> {

private final String name;
private final Map<NetworkLink, List<T>> metaData;
private final Map<T, Set<NetworkLink>> reverseLookup;
private final List<T> fallback;
private final List<T> information;

public MetaMap(String name, T fallback){
    this.name = name;
    this.metaData = new HashMap<>();
    this.reverseLookup = new HashMap<>();
    this.fallback = new ArrayList<>();
    this.fallback.add(fallback);
    this.information = new ArrayList<>();
}

/**
 * Returns an identifier giving the information contained in this map
 *
 * @return
 */
public String getName() {
    return name;
}

/**
 * Marks from origin to destination with information of type T
 *
 * @param line
 * @param information
 */
public void markLineFragment(RunningLine line, T information) {
    line.getLinks().stream().map((link) -> {
        if(!metaData.containsKey(link)) {
            metaData.put(link, new ArrayList<>());
        }
        return link;            
    }).forEach((link) -> {
        metaData.get(link).add(information);
    });

    if(!reverseLookup.containsKey(information)) {
        reverseLookup.put(information, new HashSet<>());
    }

    reverseLookup.get(information).addAll(line.getLinks());
}

/**
 * Returns the information on the given NetworkLink
 *
 * @param link
 * @return
 */
public List<T> getInformation(NetworkLink link) {
    return metaData.getOrDefault(link, fallback);
}

/**
 * Returns the information associated with the given line fragment
 * @param line
 * @return 
 */

public List<T> getInformation(RunningLine line) {
    Set<T> resultSet = new HashSet();

    line.getLinks().stream().forEach((link) -> {
        List<T> result = getInformation(link);

        resultSet.addAll(result);
    });

    return new ArrayList<>(resultSet);
}

/**
 * Returns all of the matching links which match the given information
 * @param information
 * @return 
 */

public List<NetworkLink> getMatchingLinks(T information) {
    return new ArrayList<>(reverseLookup.get(information));
}

public void addInformation(T info) {
    information.add(info);
}

public void removeInformation(T info) {
    information.remove(info);
}

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

Я хочу следовать OCP и SRP, так как я добавляю возможности программы, но немного застрял в реализации / объединении двух концепций. Пара мыслей происходит...

Я мог бы получить каждую новую модель, требующую MetaMap зарегистрироваться в GeographyModelБоюсь, что я буду нарушать ПСП. Каждая новая функция может быть MetaMap и поддерживать его, но это потребует запроса GeographyModel на первом месте.

Любые идеи, как я мог бы подойти к этому?

Answer 1

Почему вы хотите внедрить OCP? Какие проблемы вы пытаетесь решить? Если вы внедрили OCP только потому, что все думали, что это хорошо, я настоятельно рекомендую вам подумать дважды.

Каждый принцип в SOLID / GRASP, а также шаблоны проектирования - это линии гильдий и решения для очень специфических задач. В основном это инструменты. Сначала вы должны определить свои проблемы, изложить их как можно более четко. Из них вы сможете подобрать нужные инструменты для борьбы с ними.

Слепое внедрение SOLID / GRASP или шаблонов проектирования очень похоже на использование молотка для приготовления пищи. Если вам повезло, вы могли бы добиться успеха, но мы оба знаем, что вероятность была очень низкой.

https://www.u-cursos.cl/usuario/777719ab2ddbbdb16d99df29431d3036/mi_blog/r/head_first_design_patterns.pdf

Пожалуйста, перейдите на страницу 125/681 (на верхней панели) и прочитайте всю страницу!