Продолжаю цикл статей на тему «Искусство программирования под Unix» Эрика Раймонда. Ранее я упоминал первые два правила — модульности и ясности.
Сегодня речь пойдет о третьем правиле —
Правило композиции: Создавайте программы такими, чтобы их можно было соединить с другими.
К сожалению, как в Windows, так и Unix, желание разработчиков «изобрести велосипед», создать и утвердить свой стандарт, выделиться на рынке, создает такое количество разнородных интерфейсов, что ни о каком практическом соединении программ не может быть и речи.
Здесь очень уместно вспомнить концепцию
Такой подход сложнее и затратнее в разработке, зато гибкость и масштабируемость уравновешивают многие подобные недостатки. Создание документированного API на самом раннем этапе открывает для вашего приложения двери в мир: его интеграцией со чужими программами могут заняться их разработчики, а не ваши, отчего в итоге выигрывают все.
Чем более стандартными будут протоколы и форматы файлов, чем больше удобства вы принесете конечным пользователям и своим коллегам. Чем больше ваша программа сможет взаимодействовать с другими системами, тем большую свободу вы откроете пользователям.
В таких условиях среди них находятся свои «кулибины», что может принести и проблемы. Например, можно вспомнить Gdrive — виртуальный
Очень важно найти сразу партнера, кто бы чуть ли не на нулевом этапе подхватил бы ваш API и участвовал в его проектировании и, может быть, реализации. Только так можно «услышать» пользователей, а не додумывать за них то, что им нужно.
Большой ошибкой является разработка API по принципу «лишь бы был». Без документации, без единообразия в применении, без единой логики, объединяющей различные варианты его использования, без це лостной архитектуры, польза от сервиса будет очень условной. В качестве отрицательных примеров можно вспомнить омгэшную CORBA и майкрософтовский COM — довольно плохо проработанные технологии для связывания разнородных систем. Разработкой спецификации CORBA занимался десяток компаний первого эшелона, но получилось то, что получилось: на мой взгляд, ни один вменяемый программист по собственной воле сегодня эту концепцию не выберет. А COM имеет довольно узкое применение для связи программ в среде MS Windows, хотя никто не мешал его с самого начала разработать более универсальным.
В мире Unix, для взаимодействия консольных программ есть технология каналов (pipe), о которой я уже писал раньше. Выход одной программы направляется на вход другой, и на совести «архитектора» таких связок — правильно их друг с другом состыковать. Выходит
В завершение хочу вернуться к началу: создавайте программы с открытыми интерфейсами, задумывайтесь об этом с самого начала их разработки. Создание программы, оперирующей своими форматами и не умеющей общаться с себе подобными — прошлый век.