I've actually spent a lot of time thinking about problems like this and there are some rules of thumb I use when I get stuck on some architecture design.
Before typing any code (or thinking about architecture design) make sure you fully understand the problem you're trying to solve and how much that problem can vary. If you don't understand the problem then you can't model the solution right (for instance maybe you think penguins aren't birds because they can't fly). If you don't have a vision on how much a problem can vary you won't know how much flexibility you require. You may overcomplicate.
When not sure how to model a solution try to brute force it. Start typing some code and notice which pieces are appearing over and over and then simply collect those pieces into an abstraction. This way, a good model for your problem will be a bit more clear. You need to make sure abstractions contain only code common to all concrete implementations. This advice sounds silly but it's not always easy to tell what's common and what's specific and sometimes you don't notice you made mistake in that regard.
My advice is to take a step back from this issue. It's imaginary. For instance it's hard to tell do you really require a class for both assembly line and assembly line instructions? Do you need to pass instructions to the assembly line as a parameter (maybe one instruction applies to only one assembly line)? What is a lead engineer class? Is that just data or does it have some complicated methods? Too many foggy questions and ofcourse we will have a hard time thinking of a proper model for this solution.
One more advice and this one sort of comes from 1. and 2. I would suggest you design your models from concrete implementations to their abstractions. This way you won't find yourself in a situation where you require a switch case cast hell. Ofcourse to model like this, rule 1. already needs to be covered.
For the end just a short note. For now I never needed to use generics in my architecture designs. There was always a better alternative (even a small cast can be better). Still generics are awesome when it comes to data structures but how often do you type those?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've actually spent a lot of time thinking about problems like this and there are some rules of thumb I use when I get stuck on some architecture design.
Before typing any code (or thinking about architecture design) make sure you fully understand the problem you're trying to solve and how much that problem can vary. If you don't understand the problem then you can't model the solution right (for instance maybe you think penguins aren't birds because they can't fly). If you don't have a vision on how much a problem can vary you won't know how much flexibility you require. You may overcomplicate.
When not sure how to model a solution try to brute force it. Start typing some code and notice which pieces are appearing over and over and then simply collect those pieces into an abstraction. This way, a good model for your problem will be a bit more clear. You need to make sure abstractions contain only code common to all concrete implementations. This advice sounds silly but it's not always easy to tell what's common and what's specific and sometimes you don't notice you made mistake in that regard.
My advice is to take a step back from this issue. It's imaginary. For instance it's hard to tell do you really require a class for both assembly line and assembly line instructions? Do you need to pass instructions to the assembly line as a parameter (maybe one instruction applies to only one assembly line)? What is a lead engineer class? Is that just data or does it have some complicated methods? Too many foggy questions and ofcourse we will have a hard time thinking of a proper model for this solution.
One more advice and this one sort of comes from 1. and 2. I would suggest you design your models from concrete implementations to their abstractions. This way you won't find yourself in a situation where you require a switch case cast hell. Ofcourse to model like this, rule 1. already needs to be covered.
For the end just a short note. For now I never needed to use generics in my architecture designs. There was always a better alternative (even a small cast can be better). Still generics are awesome when it comes to data structures but how often do you type those?