Функционал и интерфейс
Покотиленко Костик -> debian-russian@lists.debian.org @ Fri, 13 Mar 2009 19:56:06 +0200:
>> >> >> Вот, навскидку назвал, и
>> >> >> это несмотря на то, что вы привели список _консольных_ утилит в основном.
>> >> >
>> >> > Просто для информации: к любой консольной утилите (у которой есть stdin
>> >> > и stdout) веб-морду можно приделать как два пальца об асфальт.
>> >> >
>> >> Осталось только узнать зачем.
>>
>> ПК> Вот-вот.
>>
>> ПК> Плохая практика: прога с CLI + фронтенд
>> ПК> Хорошая практика: прога с CLI <-- либа --> прога с GUI
>>
>> То, что ты назвал плохой практикой - unix way, и тот факт, что эта
>> практика - плохая, требует обоснования. Нет, я не утверждаю, что
>> браузер - достаточно хороший гуй, а HTTP - достаточно хороший протокол,
>> чтобы тыкать их во _все_ дырки... Фронтенд совершенно не обязательно
>> должен работать по HTTP...
>>
>> Ну и да, по ходу дела ты, по сути, записал в "плохую практику"
>> практически все клиент-серверные решения. Начиная с SMTP и HTTP :-)
ПК> Не так. Не путай клиент-серверное решение и IPC с фронтендом :). Разница
ПК> очевидна:
ПК> 1. IPC: связь нескольких процессов в пределах одной машины
ПК> 2. клиент-серверное решение: связь нескольких процессов работающих на
ПК> разных машинах
Это разделение уже изрядно условно. Так, во-первых, я хожу к
IMAP-серверу своего ноутбука вне зависимости от того, на том же ноутбуке
у меня гнус или на совершенно другой машине.
Во-вторых, и к нему, и к заведомо удаленному IMAP'у основной почтовки я
хожу ... правильно, по IPC. Этот IPC транслируется на удаленный хост
посредством ssh, но и gnus, и imapd видят пайпы к локальному процессу.
Точнее, emacs и imapd видят пайпы, а гнусу безразлично, пайп там или
сокет, он видит вообще буфер.
Я уж молчу про erlang (как язык) и прочие средства кластерной работы. У
них, я извиняюсь, задача _заключается в_ том, чтобы не было разницы, на
одной машине оно выполняется или на разных.
Ну и да, еще можно вспомнить про системы виртуализации и отношение их с
лицензиями на софт :-) А они даже у микрософта учитывают разницу между
виртуальной и физической машиной.
ПК> 3. фронтенд: использование функционала программы с одним интерфейсом в
ПК> другой программе с другим интерфейсом посредством чего-либо, в том числе
ПК> и IPC.
ПК> Во вменяемых ресурсах по написанию программ так и написано: "функционал
ПК> нужно отделять от интерфейса". Это для многих сложно, но на то есть свои
ПК> причины, и от того есть много преимуществ.
ПК> В проектах, где следуют такому принципу, фронтендами редко пахнет, так
ПК> как если есть либа со всем функционалом, проще её и использовать, и не
ПК> бояться, что в используемой программе ключики поменяются.
ПК> Это моё личное мнение, кто не согласен, начинайте новую тему, интересно
ПК> послушать что вам есть сказать.
Тебе не приходило в голову, что у библиотеки вообще-то тоже есть
интерфейс? Правда, рассчитанный на разработчика, а не на энд-юзера.
Из чего, кстати, следует, что функционал от интерфейса отделить
невозможно. Потому что тогда не будет способа воспользоваться
функционалом :-)
Так вот, у классической юниксовой CLI-программы интерфейс рассчитан на
юникс-юзера. Который ближе к разработчику, чем к энд-юзеру. И тем
самым просто является таким же API, что и у библиотеки. Только
протокол, над которым построен этот интерфейс, более высокого уровня,
чем у сишной библиотеки, и позволяет работать с ним непосредственно
человеку. Но если этот человек может алгоритмизовать некоторый набор
своих действий - он поручает его программе, и API для этого у него уже
есть. У тех разработчиков, которые об этом забыли (или забыли в букваре
про это прочесть), интерфейсы библиотек, кстати, тоже кривы до
умопомрачения. D-BUS тому ярким примером...
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Reply to: