Понимание этой архитектуры

Question

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

Это в Java и использует интерфейсы, которые, должны добавить дополнительный слой, но они добавляют5 или 6.

Вот как это происходит при нажатии кнопки интерфейса пользователя, которая вызывает функцию, которая выглядит следующим образом:

foo.create(stuff...)
{
    bar.create;
}

bar.create точно так же, за исключением вызовов foobar.creat а это в свою очередь вызывает barfoo.create.это проходит через 9 классов, прежде чем он находит функцию, которая обращается к базе данных.

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

также в foo.create все переменные проверяются на ошибки, это имеет смысл, но при каждом другом вызове проверки ошибок повторяются, это похоже на вырезание и вставку кода.Это похоже на безумие, так как после того, как переменные проверены, когда их не нужно проверять, на мой взгляд, это всего лишь процессорные циклы.

Это мой первый проект, использующий Java и интерфейсы, поэтому я просто запуталсяк тому, что происходит.

Кто-нибудь может объяснить, почему система была спроектирована таким образом, какие у нее есть преимущества / недостатки и что я могу сделать, чтобы улучшить ее, если она плохая?

Спасибо.

Answer 1

Я предлагаю вам взглянуть на шаблоны проектирования и посмотреть, используются ли они в проекте. Первоначально ищите такие слова, как фабрика и абстрактная фабрика. Только тогда намерения предыдущего разработчика будут поняты правильно.

Кроме того, в целом, если вы не работаете на устройстве с ограниченными ресурсами, не беспокойтесь о стоимости дополнительного вызова или уровне косвенности. Если это помогает вашему дизайну, облегчает понимание или открытость для расширения, тогда стоит сделать дополнительные звонки.

Однако, если в коде есть copy-paste, то это не очень хороший знак, и разработчик, вероятно, не знал, что он делал.

Answer 2

Я не могу комментировать архитектуру без тщательного ее изучения, но, вообще говоря, хорошая идея - разделить службы на разные уровни. Таким образом, если вы измените реализацию одного сервиса, другой сервис останется неизменным. Однако это будет верно только в том случае, если между различными слоями будет слабая связь.

Кроме того, обычно считается, что каждая служба обрабатывает исключения, которые конкретно относятся к виду службы, которую она предоставляет, оставляя остальное другим. Это также позволяет нам уменьшить связь между уровнями обслуживания.

Answer 3

Очень трудно понять, что именно делается в вашем программном обеспечении.Может быть, это даже имеет смысл.Но я видел пару проектов, выполненных некими "маньяками шаблонов проектирования".Похоже, они хотели продемонстрировать свои знания о всевозможных делегатах, косвенных сообщениях и т. Д. Возможно, это ваш случай.