We have a project that has behaviours. Normally I try to follow the community guidelines regarding files and folder organizations, but today one of my colleagues made some good points about why this may not be ideal.
Let’s say I have a behaviour called dispatcher, which defines an interface that other modules must implement.
Usually, I place the behaviour at
lib level and then I place the behaviour’s implementations in a folder with the behaviour’s name:
lib |_dispatcher | |_my_dispacther.ex |_dispatcher.ex
Upon checking this my colleague made a remark: “when I look at your organization, I think that dispatcher is actually a module with functionality, i.e., I think it is the real dispatcher.”
I can understand him. The file’s name does not state it is a behaviour, nor a contract nor anything alike. I argued this is the way the community does it (which is a poor argument, I do things because others do it) and I couldn’t really suggest anything better (still have a lot of PragDave’s videos to watch on project organization… )
We decided to come up with some ideas, but to me they all fell short:
i_dispacther. This falls short to me, because behaviours are not interfaces, nor contracts. They are actually a superset of the strategy design pattern.
- Rename to
b_dispatcher. To me this sounds useless. It’s like when someone asks your name and you answer “I’m JohnPerson”, or “I’m TimCat”. The biggest issue I have with this, comes from the arguments given in this talk though: https://youtu.be/ZsHMHukIlJY?t=1422
- Move everything into the
dispatcherfolder. However, doing this means that the convention of
App.FodlerName.Modulenamewould be meaningless. You would aggravate the issue of lego naming by transforming it into
How do you organize your project structure so that behaviour files are clear?