Timeline for Dealing with class optional dependencies
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 30, 2015 at 1:45 | comment | added | radarbob | You seem to be getting at the Open/Close principle here. Frequent class modification suggests a a design issue of some kind. A coherent class would tend to not change - at best would change for one reason; i.e. it's responsibility changed. | |
| Apr 29, 2015 at 15:26 | comment | added | Dunk | I chose 50 to be extreme on purpose because while it is general practice to "break the rules" for one or two special conditions when it is in the interest of getting the job done. However, the more interesting answer would be the general case. | |
| Apr 29, 2015 at 1:31 | comment | added | radarbob | 50 instead of 1? The answer would not scale per se (I've used 3 in one method so far - 50 method parameters is nonsense), but if 50 implies a whole class then the null object comes to mind. At this scale there must be consideration of overall design, and there are many possibilities. | |
| Apr 28, 2015 at 19:27 | comment | added | Dunk | Your answer focuses on there only being 1 optional parameter. I'm sure the OP is looking for a general answer and is only using 1 parameter in their example to provide something tangible to work with. So what if there were 50 optional parameters instead of 1, would you give the same answers? | |
| Apr 28, 2015 at 12:04 | history | edited | radarbob | CC BY-SA 3.0 |
added 89 characters in body
|
| Apr 28, 2015 at 4:45 | history | answered | radarbob | CC BY-SA 3.0 |