Forum

Community Coding : Design Patterns

vl

#1

hei all,

I started reading this book (Head First Design Patterns, O’Reilly) that gives an introduction to design patterns and thought it would be a nice exercise to try to implement those in VL. Then, @sebl suggested it could be a cool communitythingy on the forums, so let’s do it :)

I’ve set-up a repo so anyone can contribute and see what’s going on. The idea would be to produce a series of documented patches that could serve as a learning resource for anyone interested in the topic.

Also, you can check out Christopher Okhravi’s YouTube channel where he (brilliantly) explains in details the patterns of the book.

Any comments/suggestions welcome!

cheeerz

seb


#2

first pattern is very simple in vl, i can try to patch something if no one is working on it already.


#3

working on it but i’d be curious to see how you handle it :)


#4

here is a patch that implements some ducks from the first video with the strategy pattern and draws them with skia. also made a pull request (edit: now merged): https://github.com/sebescudie/VL.HeadFirstDesignPatterns/tree/master/01_StrategyPattern

there is a Root and DuckManager patch to actually make some different ducks and manage them:
image

the output looks a bit silly tho, but i didn’t want to clutter it with too much functionality:
image


#5

Thanks @tonfilm, merged !
A bit busy these days but I should be able to study it and maybe come up with something by the end of the week.


#6

great, so next up, observer pattern! this is basically two nodes in vl, who is up for it? … hint hint:


#7

Ok, not really sure where I’m going with this, so I’ll post here first.

I was trying to patch the thing with ToObservable nodes when I remembered something @Elias showed at LINK about Subjects. Despite the OnNext node being a bit counter intuitive at first, it seems pretty straightforward now, almost feels “too easy” to be the right thing to do :)

What would you think about that approach ?

image

VVVV.DesignPatterns.Observer.vl (49.2 KB)


#8

i’ve watched the video about observer pattern and the explanations are nice, but in VL you don’t really need to know most of it, because IObservable is already the optimal implementation of the conclusion he makes at the end of the video. it’s even much more, the reactive nodes are thread safe and packed as a library to use the observer pattern as a tool in your patches.

i can only see minor improvements in your patch and hope to find some time at the weekend to make a few suggestions.


#9

thanks tebjan, i’ll annotate a bit more an push to a branch before this weekend.

the video is pretty interesting indeed but that’s what I thought when I tried to patch it : the implementation of the pattern felt a bit overkill in VL :)

on another note, I started looking at the Decorator pattern and as he says in the video, the example from the book is not that suitable … I’d like to find something a bit more related to our interactiverealtimemultimedia stuff :) I’ll try to come up with something !

EDIT : pushed to a new branch. One thing though, when I re-opened the patch, the Draw (WeatherStation) node was pink because Object Reference not set to [...], even though the inputs from the Cache region were changing.
Also, the Has Changed output of the region was not reacting. I had to delete the Draw node for the Cache region to react again and then re-create it. Moving the Draw node inside the ForEach did the trick but I wonder if it’s the way to go here.
Why does the fact that the Draw node has nothing to operate on blocks things upstream ?


#10

there was an on open bug recently, was fixed yesterday. could be the issue. did you try with latest alpha?


#11

yep, just installed alpha c848148d6a and moved Draw outside Foreach, Draw is pink again on startup.


#12

in the first frame there is the data that is provided on the (white) create pin of HoldLatest. the patch doesn’t guarantee the order of execution so that the OnNext is definitely called before Draw.

so if you put some meaningful default on the create pin it should work. you should do that anyways, because you never know when the wheather station will send something.


#13

on a second look, i think the WindowDisplay should be connected directly to the Draw. It’s always the same reference, regardless of whether there is any data or not. the observable just needs to update the internal data, Draw should not depend on the update via SetData.


#14

Ok, thanks for the pointer !

Makes more sense indeed, I wouldn’t have think of that since you need to connect something to the output of ForEach for it to evaluate. It kinda makes you assume that you have to link things from the output of the region for further processing. But yeah, that makes sense now :)

I’ve updated the patch with your suggestions, thanks !