Первое, с чем сталкивается пользователь продукта – это его интерфейс. И не важно, как и чем он представлен. Это может быть пользовательский графический интерфейс, публичный интерфейс класса, API интерфейс службы. Как бы то ни было, худшее, что может сделать разработчик – это реализовать обманывающий интерфейс. Когда ты вызываешь метод Exist у класса File, то скорее всего, ты ожидаешь проверку на существование какого-либо файла по его пути, что логично. Но внезапно, оказывается, что эта команда не проверяет, а создает новый файл. Вот это поворот! На надо так…
Что я хочу сказать, что любой создаваемый тобой интерфейс должен соответствовать как минимум двум правилам. Во-первых, он должен быть ожидаемым. То есть, он должен делать то, что от него будет ожидать среднестатистический пользователь. Во-вторых, он должен соответствовать общепринятым стандартам. Если большинство других продуктов использует один и тот же формат – не нужно отличаться от них без крайней необходимости. Если все библиотеки создают файл с помощью команды Create, не нужно использовать глагол Make или любой другой из синонимов этого слова. Чем быстрее и проще будет пользователю начать работать с твоим продуктом – тем с большей вероятностью он это сделает.
Делай интерфейс максимально простым и лаконичным. Не нужно предоставлять over9000 возможностей в одном месте. Класс, в котором будет 100500 публичных методов, делающих абсолютно все – плохо спроектированный класс. Пользовательский интерфейс, содержащий сотни кнопочек и полей – ужасный интерфейс (хотя многие приложения как раз так и делаются). Не нужно сваливать все в одну большую кучу и надеяться, что пользователь как-нибудь сам разберется. Подумайте за его, сделай декомпозицию на отдельные логические компоненты. Это упростить жизнь и тебе, и пользователю.
Но при этом не усложняй интерфейс путем объединения различной функциональности в единое целое. Соблюдай принцип единственной ответственности. Сейчас поясню. Имея класс, содержащий большое количество методов, мы можем выделить отдельный класс, куда перенесем логически связанные методы, независимые от остальных. Но мы не должны объединять различные методы в один. Один метод должен выполнять одно единственное действие. Например, если мы создаем файл, то не нужно объединять создание файла, запись в него данных и его закрытие в один вызов, ведь у нас может возникнуть необходимость дописывать данные несколько раз.
Для того, чтобы научится создавать хорошие интерфейсы, необходимо научиться абстрагироваться от своего собственного мнения и смотреть как бы со стороны. Как человек, который впервые видит твою программу или библиотеку отреагирует на нее? Да, тебе как создателю может быть все предельно ясно и понятно, но для человека со стороны – не все так очевидно.
Грамотно спроектированный интерфейс (не важно программный или пользовательский) – это важный шаг к успеху всего проекта. Не поленись и потрать на проектирование дополнительное время. Поверь, это сполна окупится в будущем.
Большое спасибо за прочтение! Пожалуйста, поставь лайк и подпишись на канал, чтобы не пропустить свежие статьи. Этим ты очень поможешь развитию блога!
Также рекомендую прочитать статью Как делать меньше ошибок в коде
