Talk:Encapsulate that which varies
(New page: How can it be this simple? If you take this to far don't you just end up running into Big design up front. If you do think about your encapsulations and you get it wrong can't you just...) |
|||
| Line 1: | Line 1: | ||
How can it be this simple? If you take this to far don't you just end up running into [[Big design up front]]. If you do think about your encapsulations and you get it wrong can't you just [[Refactoring|refactor]]. How can we best use our powers of omniscience to structure our code? If we spend enough time building in flexibility for change then read [[Refactoring and design]] we may well need a mental health day to recover. -- [[User:Jason Clutterbuck|Jason Clutterbuck]] 03:12, 21 September 2008 (UTC) | How can it be this simple? If you take this to far don't you just end up running into [[Big design up front]]. If you do think about your encapsulations and you get it wrong can't you just [[Refactoring|refactor]]. How can we best use our powers of omniscience to structure our code? If we spend enough time building in flexibility for change then read [[Refactoring and design]] we may well need a mental health day to recover. -- [[User:Jason Clutterbuck|Jason Clutterbuck]] 03:12, 21 September 2008 (UTC) | ||
| + | |||
| + | ''"When writing software, have a look to see what '''might''' vary in the future"''. Anything that is obvious that it might change would be a good candidate for this. Since OO is about the real world it should be reasonably easy to think "this might change in the future" when you are writing that bit of code, if this is the case, encapsulate it. Encapsulation is generally a good idea anyway, so you arent loosing much. The point is it's much easier to use encapsulation at the start rather than having to refactor at the end. | ||
| + | |||
| + | ''"If you take this to far don't you just end up running into [[Big design up front]]"'' Think of this more from an implementation point of view; if you are implementing something that might change, encapsulate it. This isnt strictly a design issue. Software design isnt meant to be easy and im sure a day spent thinking about your design/implementation and reading online resources would be of good use. If you need a day to recover from that maybe software design isnt for you?? --[[User:David Thomson|David Thomson]] 21:19, 21 September 2008 (UTC) | ||
Revision as of 21:19, 21 September 2008
How can it be this simple? If you take this to far don't you just end up running into Big design up front. If you do think about your encapsulations and you get it wrong can't you just refactor. How can we best use our powers of omniscience to structure our code? If we spend enough time building in flexibility for change then read Refactoring and design we may well need a mental health day to recover. -- Jason Clutterbuck 03:12, 21 September 2008 (UTC)
"When writing software, have a look to see what might vary in the future". Anything that is obvious that it might change would be a good candidate for this. Since OO is about the real world it should be reasonably easy to think "this might change in the future" when you are writing that bit of code, if this is the case, encapsulate it. Encapsulation is generally a good idea anyway, so you arent loosing much. The point is it's much easier to use encapsulation at the start rather than having to refactor at the end.
"If you take this to far don't you just end up running into Big design up front" Think of this more from an implementation point of view; if you are implementing something that might change, encapsulate it. This isnt strictly a design issue. Software design isnt meant to be easy and im sure a day spent thinking about your design/implementation and reading online resources would be of good use. If you need a day to recover from that maybe software design isnt for you?? --David Thomson 21:19, 21 September 2008 (UTC)
