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