Short answer: Do whatever you want to, just don't over engineer the software, that is becomes a mess to manage and less useful.
The first thing I would ask myself is, who is going to use the software? A consumer on his own machine, or a bunch of users consuming the API, or my web app? So the first thing comes in, is it a desktop app, or a web app?
The patterns you talk about are to create the objects, and then provide them over. That is merely a part of the "inventory management system". You would require a bunch of provider patterns, inversion of control (or dependency injection at least) to decouple the services and modules, that will help you in order to better test the software later on. The service oriented architecture of the application will help you in case you are going to host it on the web app, the services can scale up/down independent of other modules.
java - What is Dependency Injection? - Stack Overflow[
^] I remember a really useful library was
google/guice: Guice (pronounced 'juice').[
^], you can consider checking it out.
Quote:
I could maybe use a factory pattern so that each specific object is encapsulated so that if I am creating (adding) a monitor, I am not requiring the user to add the OS/RAM/HD size etc.
I think you can just select the hardware component from a service or something, that knows what other hardware components relate—if they choose a RAM of 8 GB, go for a 64-bit CPU, 32-bit won't work and much more stuff. Just a factory will not work and might make things complicated, and contain a bunch of
if...else
, like the one I just mentioned. In this case, a database-like service would be useful that will be able to related the resources and build up the components. It is less about the pattern, more about the business logic.
So, in a nutshell, it is a long list of the patterns that you can check and implement, but remember, only implement if that benefits the software. Do not add every pattern, that will only make it complex.