DDD агрегируется по сравнению с фасадом GoF

Последний листинг кода включает в себя то, что я узнал. По сути, я не понимал того факта, что «переменные», упоминаемые во многих публикациях как обновляемые, на самом деле были переменными tkinter (StringVar, BooleanVar и т. Д.). Таким образом, переменные python необходимы для установки переменных tkinter. Я также подумал, что mainloop автоматически ищет изменения в переменных tkinter и обновляется автоматически. Другими словами, я не понимал, что мне нужно было установить «trace» для переменных, которые я хотел наблюдать. После этого мне нужно было узнать, что «трассировка» не обновляется автоматически, вы должны использовать ее, чтобы вызвать явное «обновление». В моем фактическом коде (слишком длинном, чтобы публиковать здесь) я использую переменные tkinter, «установленные» событиями midi, чтобы изменить выбор в списке (через «очистить», «активировать», «selection_set» и «посмотреть») и «обновить» "изображения, отображаемые в метке (которые связаны с индексом выбранного элемента). Насколько я могу судить, автоматически ничего не происходит.

6
задан Jacques René Mesrine 13 April 2009 в 08:47
поделиться

1 ответ

A GoF Façade, much like a real façade, hides the underlying implementation complexity by creating another abstraction; it hides a complex and generally separate system (or subsystem) behind a simple to use interface. For example, façade for a game might have the methods start, update and pause; completely hiding the implementation of the game, but providing a high-level way to interact with it.

The DDD aggregate on the other hand is a way of specifying a "has-a" relation between objects that have a stronger correlation than normal references. They can be seen as nodes in a tree of domain objects and they are generally threated as a single unit in terms of data exchange.

12
ответ дан 9 December 2019 в 20:48
поделиться