Я встречал мало задач, в которых были бы нужны или удобны "интерфейсы ради интерфейсов". В основном такое возникает у людей, обчитавшихся бандитов и иллюстрирующих принцип "когда у тебя в руках молоток, все задачи похожи на гвозди".

Как правило, если хорошо подумать над архитектурой, количество интерфейсов стремительно уменьшается, а управляемость и прозрачность приложения значительно увеличивается.

Я не знаю, что такое flat api, но в случае плагинов ни малейшей необходимости в интерфейсах не вижу - до тех пор, пока плагины пишутся на той же дельфе, интерфейсы только мешают. Если речь о сервере а-ля MS Word - тогда да, конечно, интерфейсы - то, что доктор прописал.


А смысл? Интерфейс для сущностей ProgressBar подразумевает, что будет какой-то объект, который будет держать в себе указатель PBar: IProgressBar и время от времени вызывать что-нибудь типа PBar.ShowProgress(50). В общем-то, изрядная порнография. Куда правильнее сделать ProgressNotification, и пусть на него подписывается хоть ProgressBar, хоть LogWriter.

Плагины нужны для решения конкретных задач. Если делать систему, плагины к которой будет писать широкий круг покупателей своими силами - интерфейсы абсолютно уместны. Но сколь я видел таких проектов, в итоге плагины к ним писал только автор универсального подхода, а покупатели в лучшем случае говорили "а напишите нам такое вот, мы заплатим". В то же время плагины - хорошая альтернатива монолитной архитектуре и для внутренней разработки. Но при этом все пишут на дельфе и интерфейсы становятся пятым колесом.


Система становится более гибкой, модули - менее связанными, не строящими ненужных предположений друг о друге, абстракции - более естественными. В исходном варианте "объект" знает, что существует какой-то "прогрессбар", который ему надо пинать. Если нам нужно убрать прогрессбар из приложения - ну вот стал он не нужен - нам приходится править объект. В случае notification-а - мы просто убираем подписку, объект неизменен. Теперь допустим, что мы хотим пока идёт операция, каждую минуту писать в лог "процесс ещё не умер и не завис". В случае notification-а - мы вешаем подписку, которая это делает, в исходном случае - заставляем logwriter-а притвориться прогрессбаром, хотя он ну совершенно не прогрессбар. Теперь, когда нам потребуется одновременно рисовать прогрессбар и писать в лог - в исходном случае придётся либо добавлять в объект PBar2: IProgressBar, чтобы везде в коде скопировать вызовы ShowProgress, либо рожать прокси-объект, который для объекта притворится прогрессбаром, а внутри себя будет пинать как настоящий прогрессбар, так и лограйтер. В общем, одна сплошная порнография - и всё из-за нежелания воспользоваться notification-ами :)


Это, конечно, тоже своего рода молоток - когда начинаешь так делать, обнаруживаешь много задач, которые можно и стоит сделать так, хотя до того обходился иначе. Но в результате и приложение становится лучше по функционалу/интерфейсу, и код - лучше по читаемости/сопровождаемости.

На Delphi всё же редко пишут SDK к оборудованию.


Не удивлюсь, если это универсальный вариант, позволяющий работать с этим оборудованием из-под юниксов - в отличие от интерфейсов, привязанных к винде. Так что, возможно, здравое и грамотное решение.


Он, конечно, крайне условный. Но сама по себе иллюстрируемая им потребность - вполне реальна. Как бы это сказать... "Прогресс" - это факт. "Прогрессбар" - это интерпретация факта. Жёсткая связь факта с интерпретацией - слабое звено в архитектуре.

Безусловно. Но это перпендикулярно вопросу "как реализовывать api в программе, подключающей плагины".


Возможно. Не возьмусь судить.


Мне кажется, я ответил - ровно настолько, насколько можно предсказать круг писателей плагинов.


Боюсь, это решение ниже всякой критики. Смотрите сами: прерывать процесс - это потребность, которая может возникнуть где угодно. Без всякой связи с прогрессбаром. Запихивать его в прогрессбар - это примерно то же самое, что у TForm-а сделать метод ExecSQL. Теперь если мы захотим, допустим, повесить watchdog timer, который прервёт процесс по таймауту - этому таймеру надо будет притвориться progressbar-ом. И ещё отдельно - то, что не вызывающий сообщает процессу о необходимости прерваться, а сам процесс вынужден тратить время на некие периодические опросы.


Не возникает. В случае нотификаций, если Вы хотите реализовать подобную вывернутую идею с опросом, всё делается очень просто: делается другое оповещение (ProcessCancellationCheck). Процесс когда хочет дёргает его. Ваша кнопка - подписывается на него и сообщает свой статус "да, меня нажимали". И watchdog timer тоже подписывается и сообщает свой статус - "да, время вышло".

Но это, конечно, если предположить, что у процесса (или его контроллера) по каким-то причинам нет метода Cancel, который выглядит наиболее логичным решением для этого случая.

Если нужен Sender (в большинстве случаев не нужен и даже вреден) его можно положить в сам message. Что касается конкретно этой реализации - ничего не скажу, поскольку не пользовался. Я ещё во времена Delphi 2 сделал себе пару компонент, чтобы процесс был нагляднее. Когда на форме лежит ConnectionLostNotification - обычно дополнительных вопросов уже не возникает.