I like this article for what you are trying to do.
Those principles are tricky to teach/show/learn because you always run into the problem of "How am i going to show this". What often happens is either:
You showcase the principle in a big application, where it could be useful but then your readers need to know a lot about the business logic of that application. This hinders learning
You showcase the principle in a small, trivial application (what you did) but then people will complain your solution is "a typical case of over-engineering" and "a clear example of why OOP is ugly".
Oliver mentions that we should "try as much as possible to identify some patterns in our code when solving new requirements and find out what principles could be useful in improving the codebase".
The main principle I follow is KISS => Keep it Stupid Simple. Following that principle, I always go for String Concatenation for the FizzBuzz problem. See: itnext.io/fizzbuzzbazz-how-to-answ...
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 like this article for what you are trying to do.
Those principles are tricky to teach/show/learn because you always run into the problem of "How am i going to show this". What often happens is either:
Oliver mentions that we should "try as much as possible to identify some patterns in our code when solving new requirements and find out what principles could be useful in improving the codebase".
The main principle I follow is KISS => Keep it Stupid Simple. Following that principle, I always go for String Concatenation for the FizzBuzz problem. See: itnext.io/fizzbuzzbazz-how-to-answ...