Naive questions about textures and delegates

Hi, in regards to what you were trying to achieve in your first post. This is called “Strategy Pattern”, @sebescudie made an example here :

Also what you refer to as " naively perceived it somehow like the opposite of the concept of input and output pins" is called “Inversion Of Control”.

Anyway, here is how you could do something similar to what you were trying with Delegates but with Interface : TextureFXStrategy.vl (22.5 KB)

You wrap each TextureFX inside a class that implement a common interface. In my patch that interface is called ITextureFX and define one input and one output both of type Texture for one operation called Filter.

Every class that implement this interface MUST have the process Filter with one input and one output of type Texture. Think about an interface as a contract.

Now because both BlurFX and EdgeFX are of the same type (ITextureFX) and FXProcessor is using the operation Filter (common to all ITextureFX) you can swap BlurFX and EdgeFX easily.

Finally you have the FXProcessor node using the Filter operation.

Biggest advantage here is that FXProcessor doesn’t care about what specific you input, as long as it is of type ITextureFX it is the guarantee that it as the Filter operation, so you can create new TextureFX class, FXProcessor remains untouched.

FXProcessor could also be modified, the ITextureFX remains the same, so both part of the system aren’t tightly coupled and can grow separately. This would make sense later as the system gets bigger.

5 Likes