Дизайн API: Гибкость По сравнению с Простотой в употреблении
Я предлагаю вам предоставить отдельного пользователя для mysqladmin и дать ему минимальные привилегии. Это может сократить уязвимость для хакеров.
mysqladmin похож на mysql, он использует аргументы для определения, какого пользователя, какого хоста и нужно ли запрашивать пароль:
-
-p- запрашивать пароль динамически (сложно использовать в пакетном скрипте) -
-pMyPwd- предоставить пароль (не очень безопасный) - (ни один из вышеперечисленных) - без пароля или ... [ 118]
Вы можете использовать mysql_config_editor для установки пароля особым образом, так что вам не нужно включать -p.
3 ответа
Если Вы - часть организации по стандартизации, которая может осуществить использование Ваших классов на других затем, можно пойти с гибким и сложным (например, stl).
Для всех остальных, если нет некоторые действительно неопровержимые доводы, затем простота использования должна всегда быть Вашим предпочтительным вариантом. Иначе немного людей будут использовать Ваш код. Если кривая обучения для использования чужого кода будет высока затем, то большинство людей решит повторно реализовать просто части, в которых они нуждаются. Это обычно - более быстрый путь, и проблемы легче разрешить.
По-моему, "простота понятности" является 2-й только к "Ему Работы Правильно" когда дело доходит до оценки качества кода.
Так нижняя строка, при добавлении гибкости прибывает за счет легкого, чтобы изучить и использовать, затем не добавляют гибкость, пока не ДОКАЗАНО, что гибкость необходима.
Я думаю, что необходимо рассмотреть целевую аудиторию для библиотеки - если Вы пишете библиотеку, которой могут пользоваться менее опытные разработчики, необходимо задуматься над тем, как помочь им. В случае STL C++, вероятно, большинство разработчиков, которые используют их, не возражает против дополнительной механики, потому что они привыкли к ним и оценивают гибкость намного больше.
Можно хотеть думать приблизительно два уровня доступа через API, который имеет уровень, который сохраняет вещи простыми и слой, который допускает больше управления. Но можно хотеть видеть, как платформа разрабатывает сначала перед движением в ту длину.
Я люблю библиотеку базовых классов.NET API. Дизайн библиотеки больше всего следует этим инструкциям.
При чтении их и сопроводительной книги, я взял несколько основных частей знания:
API был разработан, имея в виду, что у современных редакторов есть intellisense возможности. Более длинные имена приемлемы, потому что Вы можете строка вкладки завершать класс и имена методов. Это против функций C-стиля с короче, запутываемые имена как
strnicmp()Использование Создавания, Набора, шаблона Вызова: Всегда имейте значение по умолчанию, никакого конструктора параметра. Обеспечьте свойства, которые могут быть установлены в любом порядке, и затем позволять методам быть названными. Используя этот шаблон позволяет объекту быть в недопустимом состоянии в течение короткого промежутка времени. (После того, как конструктора вызвали, но прежде чем любые свойства были установлены), Но это хорошо. Можно передать неправильное употребление API путем выдавания исключения. Это делает использование класса более доступным.