Timeline for Calculator with history
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 10, 2020 at 13:24 | history | edited | CommunityBot |
Commonmark migration
|
|
| Feb 12, 2017 at 12:53 | vote | accept | zhanymkanov | ||
| Feb 12, 2017 at 14:24 | |||||
| Feb 12, 2017 at 12:40 | comment | added | oopexpert | My personal opinion is that getting used to design patterns may also help to identify the appropriate usage within a usecase. I am also convinced that in software development I have to expect patterns. I totally agree that patterns "emerge". I do not know if we have a similar word in software engineering but with experience there comes a thing such like "kinesthetic awareness" that will help you to make a shortcut instead of going through the "emerging" process. | |
| Feb 12, 2017 at 12:28 | comment | added | oopexpert | I didn't say that they are a "goal". If someone does then he will end up in the disaster you mentioned. Teaching them is a "good thing" . But teaching them as a "good thing" is saying nuclear power is overall good. I do not go with that either. I only say: Learn them to implement them correctly if their usage within a usecase is appropriate. | |
| Feb 12, 2017 at 12:16 | comment | added | Vogel612 | I kind of disagree on your point 5... In my experience design patterns are "emerging" from well-written code. Having the design pattern as a goal can result in design failures and overdesigned spaghetti code. Example: I worked on production code that used a self-written Tree implementation and a Visitor pattern to calculate business numbers over a flat collection. Basically a simple loop was blown to the size of 4 classes and ca. 3k LoC. That's why teaching "design patterns" as a "good thing" is ... dangerous IMO . | |
| Feb 12, 2017 at 11:56 | history | answered | oopexpert | CC BY-SA 3.0 |