|
It is a
judgment call. My own opinion runs like this:
If the feature (in order of importance): 1 - fits in the
overall design methodology you have adopted
2 - serves a *conceivable* -- even though not foreseeable -- function 3 - adds no new complexity (other than the normal complexity needed to implement any such feature) 4 - does not adversely affect performance then do
it.
Some might argue with number one being more important than the others. In my not insignificant experience, the leading cause of design flaws is "shortcutting" the design methodology because either the module is considered to be too trivial to warrant the additional effort or the module is not expected to ever experience/contribute to the problem(s) solved by the design feature(s). It's a simple cost/benefit analysis issue. If you implement the feature and it turns out never to be needed, you have lost very little in the way of wasted effort. If you don't implement the feature and it turns out to be needed, there could be a massive cost to make the correction, depending on where in the design process the need was finally discovered. But no matter how early the need is discovered, the cost/effort will always be higher than implementing it in the first place. There is also human psychology to consider. Once you break your design discipline, breaking it a second time comes easier, a third time even easier. It is best never to even start down that road. For all these reasons, there should be a process of justification for bypassing any normal design feature. And "no foreseeable need" is explicitly NOT a valid justification. Tomm -- It's hard to read through a book on the principles of magic without glancing at the cover periodically to make sure it isn't a book on software design. - Bruce Tognazzini ____________________________________________________ To change your JDJList options, please visit: http://www.sys-con.com/java/list.cfm Be respectful! Clean up your posts before replying ____________________________________________________ |
Title: interface for only 1 class
- [jdjlist] interface for only 1 class James Stauffer
- [jdjlist] Re: interface for only 1 class Joseph Ottinger
- Tomm Carr
