Подходящий C API для проверки значений атрибутов - PullRequest
1 голос
/ 11 июня 2010

В C существует два очевидных способа предоставления внешнего доступа к внутренним значениям атрибутов (A), обеспечивающий общий интерфейс, который принимает список атрибутов, который изменяется со временем (некоторые добавлены / некоторые умирают) или (B) специальный интерфейс длякаждый атрибут.

Пример A:

int x_get_attribute_value(ATT att)
{
    if (a) return a_val;
    if (b) return b_val;
}

Пример B:

A_Enum x_get_a_type_attribute() {}
B_Enum x_get_b_type_attribute() {}

Я напоминаю, что API Eclipse очень похож на A (я могу ошибаться).Чего я не могу сделать, так это выдвинуть убедительный аргумент против любого из них.

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

B имеет проверку типа в некоторой степени - это перечисления C!

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

Ответы [ 3 ]

0 голосов
/ 11 августа 2010

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

0 голосов
/ 25 августа 2010

Если вы хотите поддерживать опции различных типов (целые числа, строки и т. Д.), То A не является начальным, потому что функции C могут возвращать значение только одного типа.Конечно, вы можете заставить функцию возвращать void* и типизировать результат, но это просто вызывает проблемы.

Короче говоря, если вы хотите / должны поддерживать несколько типов опций, решение B - этопуть.

0 голосов
/ 11 июня 2010

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

Основываясь на своем личном опыте, в общем, я бы ручался за А.

Многое также зависит от того, насколько тесно интегрировано программное обеспечение. Заимствуя терминологию Буча, опция A способствует слабой связи , в то время как B способствует сильной связи между компонентами программного обеспечения.

Если вы хотите иметь возможность заморозить интерфейс, сделать его стабильным в течение длительного периода времени, запретить любые изменения, тогда B позволит вам сделать это: добавление нового атрибута хорошо видно. Если вы хотите иметь возможность добавлять новые атрибуты в любое время, когда вы ожидаете, что их будет множество, тогда вариант А является очевидным излюбленным.

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

N.B. Очевидно, что не следует забывать о производительности: опция B выиграет A в любом микробенчмарке.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...