In terms of abstraction, I will create the all new acronym PAPAGO - pick a paradigm and go. If you plan to write something that has the same lifestyle compared to others, you should probably box that in some guiding interface - pick a paradigm. How should I represent this code?
This way you not only have a structure to build off of, but it greatly reduces the amount of code. Otherwise, every other class is going to have a Load function. Some named differently. Especially if said code doesn't use the Load function in the first place. A nice interface to a class like this would be would be ILoadable and you can separate the loadables from the unloadables.
Having a neat structure means you can easily batch things together and have a fairly nice stack unwrap when something bad happens. I stay away from abstract classes as much as possible in place for interfaces. They bridge the gap of 'Mandatory research before new feature' by having something you can easily walk through not only in code, but again the stack unwrap.
There is a difference between 'oh one of my classes failed to load' and 'oh one of my loadable classes failed to load' that only experience can make you appreciate.
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.
In terms of abstraction, I will create the all new acronym PAPAGO - pick a paradigm and go. If you plan to write something that has the same lifestyle compared to others, you should probably box that in some guiding interface - pick a paradigm. How should I represent this code?
This way you not only have a structure to build off of, but it greatly reduces the amount of code. Otherwise, every other class is going to have a Load function. Some named differently. Especially if said code doesn't use the Load function in the first place. A nice interface to a class like this would be would be ILoadable and you can separate the loadables from the unloadables.
Having a neat structure means you can easily batch things together and have a fairly nice stack unwrap when something bad happens. I stay away from abstract classes as much as possible in place for interfaces. They bridge the gap of 'Mandatory research before new feature' by having something you can easily walk through not only in code, but again the stack unwrap.
There is a difference between 'oh one of my classes failed to load' and 'oh one of my loadable classes failed to load' that only experience can make you appreciate.