Timeline for Rock, Paper, Scissors - Applying OOP Principles
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 14, 2021 at 4:16 | comment | added | the VBE - it's right for me | I do get the principle of course. I just have noticed that worrying about a class or function name not being correct can stall my flow and thought it more efficient to get down something and keep going. | |
| May 14, 2021 at 2:10 | comment | added | the VBE - it's right for me | Yeah, but how you do know they didn't refactor it for Apollo 12? :-p | |
| May 13, 2021 at 23:23 | comment | added | Greg Burghardt |
If you're curious, that link in my previous comment was to the Apollo 11 lunar landing module code. The comment on that line of code reads # TEMPORARY, I HOPE HOPE HOPE and here we are 60 years later reading a "temporary" line of code. :)
|
|
| May 13, 2021 at 23:20 | comment | added | Greg Burghardt | @theVBE-it'srightforme: The earlier stages of a project are where names and coding idioms are established, and these features spread throughout the code. If you cannot come up with a good name, it might indicate a design problem with the class, or a need to understand the problem domain better. To be fair, this is a stage we all go through, but this should not be a stage we keep going through. Temporary code becomes permanent all too often. | |
| May 13, 2021 at 22:54 | comment | added | the VBE - it's right for me | Reading the link about naming classes with "Manager" suffix I think it would be fair to say it that it is still acceptable to do so as a placeholder while someone is in the earlier stages of the project? I mean if it serves some useful purpose for them making sense of what they are trying to do they shouldn't obsess about finding a better name at that moment because they know they aren't "supposed" to name things that way. | |
| May 13, 2021 at 11:37 | comment | added | Greg Burghardt |
@ImNotThatCSharp: The getter returns an IEnumerable<Move> which does not allow you to add items to the collection. This is in case you want to loop over the moves that this move defeats. The private field is a List<Move>, which allows you to add or remove items from the collection. We want to restrict who can decide which moves are defeated to enforce the business rules of your game (rock beats scissors and lizzard).
|
|
| May 13, 2021 at 9:35 | comment | added | ImNotThatCSharp | Thanks, Greg. A lot of good suggestions here - I agree coupling is definitely something I need to work on reducing. Static constructors also seem very handy! Why do you have a getter on what looks like a private field, defeatedMoves? | |
| May 12, 2021 at 18:08 | history | answered | Greg Burghardt | CC BY-SA 4.0 |