Need some advice on how to struct this program

Well, 3 months ago I took a deep learning dive in golang.
I’ve written a few simple programs, just to feel the language and I liked it.

Unfortunately I had to take a break, but I’m back now…

I already have a lot of code snippets working, so my problem is not the code itself, but is how to structure it.

I think I’m too much in the OO world and I’m not seeing a good way to do it.
So I would like some advice on how you guys, may structure this program.

The basic idea is:
Input: A PDF file in text format
Process: Extract some patterns of that document
Output: Some JSON with the values.

I don’t have any problem with that!

The main problem is: I may have a lot of “kinds/styles” of documents.

So let’s say I have: CompanyA, CompanyB, CompanyC.

Each company has his own text format, so I will need to create specific code for each of them.

I thought: maybe I can just split each company in a package? But It already seems wrong to me…

Besides that, I have another problem.
Each company have different categories of documents, lets say: cars, houses, boats.

Still, it have a status for the document like: new, renew, cancel, etc…

So, my whole idea on structuring this different pieces of code in a package for each company doesn’t seems a good idea anymore.

Summing up: Each document needs to be identified and processed by three characteristics.
Company -> Category -> Status

Is creating a package for each category the best way?
Any brilliant idea on how to struct this in a more “go idiomatic way”?

Thanks.

PS: English is not my native language, so, bear with me :stuck_out_tongue:
If you guys need more details, just let me know.

It is going to be very hard for anyone here to point you to an exact solution because the best solution will likely be one that evolves as you write your code. I would guess that you will end up using either interfaces or functions that are implemented different per document, but how exactly you will use them is hard to say right away.

My advice would be to just start out implementing a solution with a small subset of your data. Maybe limit your self to 2-3 different types of documents and write that code. Then start to add a few more and see how your code evolves. What seems like a bad design? How could you improve it?

Experiment a bit as you go and see what you like vs what doesn’t seem to work well. My guess is that as you do this you will end up with a much better organizational pattern than we could ever suggest with limited knowledge.

2 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.