I have a medium sized project (~10,000 lines) that runs on Windows and Linux. However it is only specific components of the program that are platform dependent and are located in a folder called event_producers
.
Now my main concern is to how go about organizing this folder since the project starts becoming more complicated and I would like to keep the organization at an optimal level.
Organization based on platform:
'-- event_producers
|-- Linux
| '--- monitoring.py
'-- Windows
'--- monitoring.py
This looks more implementation agnostic which is a bonus since someone can change things in the future without creating any new files. The main problem is that no one can guarantee that every programmer follows the pattern of having a file with the same name in each platform folder.
Organization based on design:
'-- event_producers
'-- Monitoring
|-- linux.py
'-- windows.py
This doesn’t leave much space from the programmer to organize things in the wrong way. What bothers me is that I have a module called linux.py
and windows.py
, something I never came across in any other project. Also if in the future a new folder (say Activator
) needs to be created, no one can guarantee that the programmer will follow the pattern of naming files according to the platform.
Questions
- How would you organize the project and why?
- Is there some other advantages/disadvantages with each way that I missed?
Good for you for factoring out the platform specific bits from the bulk of the code. I bet this helps keep the overall project manageable. I think your organization based on platform is the way to go. Platform-specific files go in platform-specific directories, and the files themselves can have names that match what they do. This keeps things very clear, which is a feature of a good design, IMO.
Yes, there is risk of someone omitting platform support when a new file/feature/event producer is added. You can mitigate this by adding a consistency check to your test suite that confirms that each platform has a corresponding set of files. This could be added to your build process so problems can be detected and surfaced early.
Alternatively, you could have a helper script that generates stub files for each (known) platform which are then edited to provide real functionality. You’ll also need to replicate all files when a new platform is added, but that’s a big job no matter how you approach it.
I think you are on the right track.