Timeline for Decoupling classes from the user interface
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 3, 2011 at 12:35 | vote | accept | Pete | ||
| Aug 3, 2011 at 12:35 | history | bounty awarded | Pete | ||
| Aug 2, 2011 at 16:15 | comment | added | kevin cline | @Magnus - yes, designing a library in a some languages, planning for backward binary compatibility, is tricky. One is forced to write all sorts of currently unneeded code to allow for future extension. This may be reasonable for languages that compile to the metal. It's silly for languages that compile to a virtual machine. | |
| Aug 1, 2011 at 14:38 | comment | added | Magnus Wolffelt | @kevin cline that's awesome unless you are designing a publicly available library with an API that needs to conform to previous behaviour and interfaces. | |
| Jul 30, 2011 at 13:43 | history | edited | Falcon | CC BY-SA 3.0 | added 61 characters in body |
| Jul 29, 2011 at 4:53 | comment | added | kevin cline | Good answer, but extreme programmers don't 'put in abstractions where we expect things to change'. We put in abstractions where things are changing, to DRY up the code. | |
| Jul 27, 2011 at 14:24 | history | edited | Falcon | CC BY-SA 3.0 | added 596 characters in body |
| Jul 27, 2011 at 9:04 | history | edited | Falcon | CC BY-SA 3.0 | added 89 characters in body |
| Jul 27, 2011 at 8:53 | history | edited | Falcon | CC BY-SA 3.0 | added 1 characters in body |
| Jul 27, 2011 at 8:46 | history | answered | Falcon | CC BY-SA 3.0 |