This needs to be at the top, in the introduction. Especially in Java and C#, I've seen far too much "over-patterned" code, in contrast to the opposite.
This needs to be at the top, in the introduction. Especially in Java and C#, I've seen far too much "over-patterned" code, in contrast to the opposite.
The thing is, during the class we understood what the patterns were. However, since the actual programming project was comparatively small we didn't actually understand what a need for following these patters looks like. We didn't see a case where the simple way just didn't cut it, we were simply told to use them because they are good. The effect of this is that, unless someone with experience then comes and mentors you, you will overengineer all of your solutions because you don't know any better. We were taught the patterns but didn't understand the reasons. And I suspect many other engineers have had similar experiences
ps: I also forgot to say, even though I'm a fp head these days, imperative C felt fun, that is if you carefully stay into state -> state mindset ;)