инкапсулировать перечисления или нет?

Question

Предположим, у вас есть библиотека, которая разработана на двух уровнях: ядро, низкоуровневое и высокоуровневое. Мой дизайн сфокусирован на уменьшении сцепления между ними.

Одна из подпрограмм уровня высокого уровня принимает перечисление (скажем, FOO = 0, BAR = 1, BAZ = 2). Это перечисление используется непосредственно подпрограммами низкого уровня для его конечных целей.

Для разработки этого, у меня есть три варианта:

1. Процедура высокого уровня принимает перечисление инкапсулированного в модуль высокого уровня, и переводит один-к-одному на перечислении высокого уровня в перечисление низкого уровня значения. Преимущества: нижняя муфта. Недостатки: я повторяю себя
2. Процедура высокого уровня принимает значения перечисления модуля нижнего уровня и передает его «как есть». Преимущества: меньше набрав, меньше дублирования. Недостатки: более высокое сцепление.
3. Я создаю «модуль перечисления», который является внешним, и оба уровня зависят от этого модуля перечисления. Преимущества: концептуальная ясность. Недостатки: Uber catch-all модуль с перечислениями, которые не близки к их коду.

Есть ли у вас опыт в этом деле? Я бы пошел с 1, поскольку он уменьшает сцепление, но я хотел бы также услышать ваш опыт.

Answer 1

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

Если это так, то вариант № 3: «Разбить его» - это путь.

Если уровень высокого уровня должен выполнять некоторую обработку по команде или параметру, И он должен быть передан на уровень низкого уровня, то есть хороший шанс, что вы что-то взорвали в своем выборе демаркации между слоев. Слои НЕ должны заботиться о внутреннем бизнесе друг друга.

Если вам нужно это сделать, то разрывание его еще более важно, так как вы хотите, чтобы уровни BOTH зависели от перечисления, и вы ХОТИТЕ изменение в перечислении, чтобы заставить (как минимум) перекомпилировать обе стороны , (make, dependencies и т. д.)

Прочитайте классическую статью Дийкстры «Структура системы мультипрограммирования» и задумайтесь над тем, что она говорит о философии слоев. Он находится на веб-сайте Департамента UT Austin CS, в архиве Dijkstra.

Answer 2

Я думаю, это зависит от того, являются ли ваши уровни слоями или уровнями.

Если модуль низкого уровня находится за интерфейсом веб-службы, я бы пошел на # 1, который по существу достигнут прокси-кодом, сгенерированным для вас (конечно, в случае служб WCF или amsx).

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

Answer 3

У меня проблемы с связью здесь не возникало. ИМХО, оба уровня должны увидеть одно и то же перечисление (что-то больше похоже на вариант 3). Имена в перечислении должны быть именами высокого уровня (так, кто их читает, может хорошо их понимать, не нужно понимать низкий уровень), а его значения должны быть несущественными для части высокого уровня.

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

Надеется, что это помогает :)