Need some suggestions on my softwares architecture. [Code review]

Question

I\'m making an open source C# library for other developers to use. My key concern is ease of use. This means using intuitive names, intuitive method usage and s

Answer 1

Here are a couple of suggestions, nothing major, just some things to consider.

1. I understand you wanting to keep the API minimal, thus making the Parser and Downloader private/internal, but you may want to consider making them public anyway. The biggest reason is that since this is going to be an open source project you are most likely going to get folks who are, well, hackers. If by chance they want to do something that isn't directly supported by the API you provide, they will appreciate you making the bits available to them to do it themselves. Make the "standard" use-cases as simple as possible, but also make it easy for folks to do whatever they want with it.

2. It looks like there is some data duplication between your Movie class, and your Parser. Specifically the parser is getting the fields that are defined by your Movie. It seems like it would make more sense to make Movie a data object (just the properties), and have the Parser class operate on it directly. So your parser FromMovieTitle could return a Movie instead of a Parser. Now that brings up the question of what to do with the methods on the Movie class FindMovie and FindKnownMovie. I would say you could create a MovieFinder class which had those methods in it, and they would utilize the Parser to return a Movie.

3. It looks like the parsing tasks could get rather complex since you are going to be scraping HTML (at least based on the comments). You may want to consider utilizing a Chain or Responsibility pattern (or something similar) in the parser with a simple interface that would allow you to create a new implementation for the various data elements your wanting to extract. This would keep the Parser class fairly simple, and also allow other folks to more easily extend the code to extract data elements that you may not support directly (again, since this is Open Source people tend to like easy extensibility).

Generally speaking if you keep the Single Responsibility Principle and Open/Closed Principle in mind along with your goal of keeping the standard usage easy, you should end up with something that people will find easy to use for the things you've thought of supporting, and easy to extend for the things you haven't.