Timeline for ReportManager design — ownership via move or unique_ptr, SRP concerns, and O(1) lookup strategy
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 19 at 5:47 | comment | added | G. Sliepen | @sam Great! Feel free to create a new question on CodeReview so you can get the new version reviewed as well. | |
| Jun 19 at 2:20 | comment | added | sam | @G.Sliepen I've applied what you guided in the answer: godbolt.org/z/aErxGWEeh | |
| Jun 10 at 16:42 | comment | added | G. Sliepen | @sam If it's just a simple struct then you can get some safety constructing new Reports by using designated initializers: Report report = {.header{"Hello,"}, .body{"Lorem ipsum…"}, .footer{"Bye!"}}; As you can see, while your approach is slightly safer, it adds a lot of complexity to the code which can introduce its own errors. So it's a trade-off. You could also just add a default constructor Result() = default , which will delete the implicit constructor which takes the strings and id as arguments. That way you are forced to write Report report; report.header = "…"; … | |
| Jun 10 at 14:32 | comment | added | sam | Thanks, G. Sliepen, for your thorough explanation. I appreciate your insight. I have a few questions: I learned from Scott Meyers’ book that we should design APIs in a way that makes it hard to use them incorrectly. For example, if all the inputs for generating a report are just std::strings, it's easy to mix up the header, footer, and body. That’s why I wrapped them in a class. What’s your opinion on this? Should I remove the wrappers? Also, adding getters and setters for each field would clutter the Report class—what’s the best approach here? | |
| Jun 10 at 14:21 | comment | added | sam | @indi Thank you! You're probably right! I am working on a side project and kept adding features without knowing where to stop—mainly because there’s no clear requirement, unlike in a real job. I’m currently working as a C++ SE with 1 yr of experience, and I’m trying to improve my skills. My question is: where can I find relevant real-world problems outside of my work projects? Should I just twist or simplify real-world problems I encounter at work and use them as side projects? Sometimes that's hard, since real-world scenarios come with extra requirements I might not want to implement. | |
| Jun 10 at 14:16 | vote | accept | sam | ||
| Jun 9 at 22:07 | comment | added | indi | The bits on whether the ID should be in the widget or widget manager, and what form it should take, really highlight why abstract “theoretical” problems are a terrible way to study software design. If you really want to learn software design, find a real problem, and try modelling it. Working with/around the constraints of reality will always teach you much more about the practical application software design principles than farting around with vague hypotheticals ever will. | |
| Jun 9 at 10:51 | history | edited | G. Sliepen | CC BY-SA 4.0 | added 6 characters in body |
| Jun 9 at 10:32 | history | edited | G. Sliepen | CC BY-SA 4.0 | added 1 character in body |
| Jun 9 at 10:27 | history | answered | G. Sliepen | CC BY-SA 4.0 |