Вопрос дизайна: Как я могу прозрачно получить доступ к механизму IPC?

Question

Я хочу сделать это (без определенного языка):

print(foo.objects.bookdb.books[12].title);

или это:

book = foo.objects.bookdb.book.new();
book.title = 'RPC for Dummies';
book.save();

Где foo на самом деле является сервисом, подключенным к моей программе через некоторый IPC, и для доступа к его методам и объектам, некоторый уровень фактически отправляет и получает сообщения по сети.

Теперь я не ищу механизм IPC, так как есть из чего выбирать. Скорее всего, это будет не XML, а скорее s. е. как буферы протокола Google, dbus или CORBA. В чем я не уверен, так это в том, как структурировать приложение, чтобы я мог получить доступ к IPC так же, как к любому объекту.

Другими словами, как я могу получить ООП, который прозрачно отображает границы процесса?

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

Answer 1

Я думаю, что способ сделать то, что вы запрашиваете, - это передать все сообщения объекта как передачу сообщений. Это, как методы объекта обрабатываются в ruby ​​и smalltalk, среди других.

С передачей сообщений (а не вызовом метода) в качестве механизма взаимодействия с объектами такие операции, как вызов метода, которого не было, когда вы писали код, становятся разумными, поскольку объект все равно может что-то делать с сообщением (проверьте для удаленной процедуры верните значение для поля с тем же именем из базы данных и т. д., либо сгенерируйте исключение «метод не найден», или что-нибудь еще, о чем вы могли подумать).

Важно отметить, что для языков, которые не используют это как механизм по умолчанию, вы можете в любом случае выполнять передачу сообщений (у каждого объекта есть метод handleMessage), но вы не получите тонкостей синтаксиса, и вы выиграли вы не сможете получить помощь по IDE без каких-либо дополнительных усилий с вашей стороны, чтобы заставить IDE проанализировать ваш метод handleMessage для проверки допустимых входных данных.

Answer 2

Читайте о Java RMI - вводный материал показывает, как вы можете иметь локальное определение удаленного объекта.

Хитрость заключается в том, чтобы иметь два класса с одинаковыми сигнатурами методов. Локальная версия класса - это фасад какого-то сетевого протокола. Удаленная версия получает запросы по сети и выполняет фактическую работу объекта.

Вы можете определить пару классов, чтобы клиент мог иметь

foo= NonLocalFoo( "http://host:port" )
foo.this= "that"
foo.save()

И сервер получает запросы метода set_this () и save () от клиентского соединения. На стороне сервера (как правило) нетривиально, потому что у вас есть куча проблем обнаружения и управления экземплярами.

Answer 3

Ты не должен этого делать! Для программистов очень важно видеть и чувствовать разницу между IPC / RPC и локальным вызовом метода в коде. Если вы сделаете это так, что им не придется думать об этом, они не будут думать об этом, и это приведет к очень неэффективному коду.

Подумайте о:

foreach o, o.isGreen in someList { 
   o.makeBlue; 
}

Программист предполагает, что цикл занимает несколько наносекунд, вместо этого он занимает около секунды, если someList оказывается удаленным.