Timeline for String Encoder with lower-case output
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 20, 2018 at 16:09 | comment | added | jpmc26 | @t3chb0t As for your example about rules, that just sounds like nonsense. Your rules can interact in weird ways you didn't expect. A later rule might fail if you remove the rule that handled a type of input. So you'll need to debug and test. I can't see how storing them as a list of objects is much better than a well organized sequence of code statements; you can even get just as much reusability by factoring them out to functions. Where it has an advantage is if the rule list needs to be based on user input, but that really only requires dynamically chosen functions, not stateful objects. | |
| Nov 20, 2018 at 15:55 | comment | added | jpmc26 | @t3chb0t Let me clarify: a procedurally minded approach doesn't mean no objects. It means that that the objects created are primarily simple data containers or only exist to provide late binding of functions. OO doesn't magically make anything "modular" or "future proof" or "maintainable." I have the opposite experience: a massive OO system that's tied into knots by shared state (injected via IoC container) and poor choice of abstraction. We need to stop touting these vague notions as magical incantations that fix everything and focus on the concrete problems they solve well, if any. | |
| Nov 17, 2018 at 8:45 | comment | added | JanDotNet | @jpmc26: the good thing of that solution is: you dont have to understand the complex part (Process method) if you need to modify / extend the business logic. :) | |
| Nov 17, 2018 at 7:10 | comment | added | t3chb0t | @jpmc26 [..] procedural approach works only at the beginning. As soon as you start extending it and adding new features it's about time and the last call to make it OO, modular and future-proof. That's why I find if this was a service processing products or orders etc, it must be maintainable and this one is. You need a new rule? You just add it to the list. You want to disable one? You remove it from the list. No debugging... no crossed fingers. The only thing you need to test is the new module. The core-logic does not change. | |
| Nov 17, 2018 at 7:09 | comment | added | t3chb0t | @jpmc26 I have to maintain a piece of $%&§ software that has been build procedurally and implement changes that the business requires every couple of weeks or months... you have to spend hours making sure you're doing the right thing in the right place and then another couple of hours making sure you did it right because every change can break everything else... and it already happened multiple times. Nobody understands that this needs to be rewritten to a more OO solution where we just could put the modules together or create new ones easily. [..] | |
| Nov 16, 2018 at 23:06 | comment | added | jpmc26 | No. Just no. Do not create a ton of objects just to make your code "object oriented." It does not help and makes the code much harder to understand. I look at this and my immediate thought is, "What in the heck is any of this doing?" I look at t3chb0t's procedural approach and don't even have to wonder. Also, why are you iterating over an enumerator manually? | |
| Nov 16, 2018 at 20:45 | comment | added | t3chb0t | I like this edition and usually this kind of approach pays off. Especially in large projects where you already can anticipate changes that will come. This could be the second part of the interview for a senior position where you could ask them about the design. It might however be very difficult to come up with somethig like this and make it work during a 60 minutes interview ;-) | |
| Nov 16, 2018 at 19:55 | comment | added | JanDotNet | I think it is OK to ask the interviewer what exactly she intends with the question. Should the solution be optimized for performance, development speed, following clean code principles... what ever. That shows also, that you are able to clarify unclear requirements in advance - a very importent ability for software developers ;) | |
| Nov 16, 2018 at 19:40 | comment | added | whiteshooz | I love the OO approach! Maybe in the future, I should flex this type of answer. I have the ability, but I've always feared it would send a signal that I create over engineered solutions to simple problems. Next time, I will make sure to ask the technical stakeholders these sort of questions. Thank you immensely for taking the time to provide such a cool solution. | |
| Nov 16, 2018 at 19:27 | history | answered | JanDotNet | CC BY-SA 4.0 |