Design question - methods calling methods
in [Java Programming]
|
From: Tom Anderson on 23 May 2010 06:21 On Sat, 22 May 2010, Lew wrote: > Lew wrote: >> It's a best practice to add a lot of "potentially useful" cruft to a >> type. Implement what you need now, and refactor later if the need arises. > > Darn it! > > It's a best practice NOT to add a lot of cruft. NOT to. > > Somehow I proofread best after I've embarrassed myself. It does seem a lot easier to find mistakes after you've committed them to the internet. Perhaps we should agree that this is our new advanced posting technique - post a rough draft first, then post the edits when you realise what the mistakes are! tom -- One horse laugh is worth a thousand syllogisms. -- H. L. Mencken
From: Arne Vajhøj on 23 May 2010 09:35 On 22-05-2010 23:14, Patricia Shanahan wrote: > Rhino wrote: > ... >> I probably tend to overbuild a lot of the time anyway, in the sense of >> adding functionality that isn't all that likely to be used. My current >> thread about the internationalization/localization is proof of that. I >> tend to anticipate needs that others aren't sure will ever happen. Not >> all the time of course; it's just a tendency, not an obsession ;-) > ... > > I also get tempted to overbuild. When I started programming, there was > some justification, because making design changes in a large program was > difficult and risky. > > These days, it is so easy to refactor that there is generally little > benefit to adding complexity that is not needed for immediate needs. > > The exception is designing APIs that will be used in code outside your > control. API's is a problem because you the most optimal refactoring may expose an incompatible API. But I believe that there are also other cases where refactoring is not so easy. One example is the topic of the thread. Internationalizing an existing app is not difficult, but it is usually a lot of work. I18N is a well-known counter-argument to YAGNI. Arne
From: Arne Vajhøj on 23 May 2010 09:57 On 23-05-2010 06:48, Tom Anderson wrote: > On Sun, 23 May 2010, Rhino wrote: >> I probably tend to overbuild a lot of the time anyway, in the sense of >> adding functionality that isn't all that likely to be used. My current >> thread about the internationalization/localization is proof of that. I >> tend to anticipate needs that others aren't sure will ever happen. Not >> all the time of course; it's just a tendency, not an obsession ;-) > > This is a universal tendency. Everyone has it to some extent. From what > i remember of the dim depths of time, i had it rather strongly when i > was starting out programming, although it manifested itself in writing > overcomplicated class hierarchies and mad epicyclic structures of > composed objects. Kent Beck once accused me of suffering from 'premature > abstraction'. I think it's common to suffer from it strongly when you > first start thinking about design, and to grow out of it in time. http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html I would word it a little bit different: abstraction is good - *IF* it serves a purpose. > Well, > or to become an architect, architects being the Peter Pans of the > programming world. :-) >> I'm not sure how to answer that. I've read formal definitions of both >> and have written both and gotten them to run. But even after all the >> time I've spent writing Java - I started in 1997 but had a 4 year gap >> that ended a few months back where I wrote no Java at all - I don't >> feel solid on a lot of the theory. Maybe I'm expecting too much of >> myself but I feel like I should know instantly and intuitively what >> the key differences are between classes and interfaces and not have to >> wrestle with "should I use an interface or class here". But maybe guys >> like you and Eric and Tom have to think long and hard about that too. >> I really don't know. > > It's unusual to be in a situation where there is a real choice between a > class and an interface. When you're deciding the type of a variable, you > ask, as Lew said, "what is the most general type that guarantees the > behaviour i want from this variable". You don't worry about whether that > type is a class or an interface. > > When you're designing an inheritance hierarchy to exploit polymorphism, > you can choose to make the root type an interface or an exposed base > class. Like: > > public abstract class DataStore { > public abstract Data load(String id); > } > public class RelationalDataStore extends DataStore { > public Data load(String id) { > // code > } > } > > vs > > public interface DataStore { > public Data load(String id); > } > public class RelationalDataStore implements DataStore { > public Data load(String id) { > // code > } > } > > The mainstream modern school of thought is that you should always choose > the interface, so there's no real dilemma there either. I think that is exaggarating. Inheriting from abstract base classes is used all over the Java API. Joshua Bloch used the word "Prefer" in this context. Sometimes is do make sense to reuse implementation functionality (which is what the abstract base class offers). Quite frequently a compromise is used with both an interface and an abstract base class. This means that the 95% can extend and only implement the few methods they need, but still allow the remaining 5% to implement the interface with full flexibility. Arne
From: Rhino on 23 May 2010 14:53 Lew <noone(a)lewscanon.com> wrote in news:hta0s6$dmk$1(a)news.albasani.net: > On 05/22/2010 09:30 PM, >> in >> news:alpine.DEB.1.10.1005222205570.8422(a)urchin.earth.li: > > Rhino wrote: >>>> - Map<String, Locale> sortedLocales = new SortedMap<String, >>>> Locale>(); > > Tom Anderson wrote >>> Illegal. SortedMap is an interface. > > Rhino wrote: >> I didn't actually try that; > > Clearly not. > >> I just threw it out to illustrate how these things >> sort of all blur together in my brain.... > > You were advised not to do that. Strongly. > > I strongly advise you, again!, to stick with SSCCEs until you stop > making that kind of mistake. That you have not learned your lesson > about posting uncompilable code is starting to make you look careless > and lazy. > Honestly, I think you're being just a little too rigid now. I was trying to get across the idea that, at first glance, Map<String, Locale> sorted Locales = new SortedMap<String, Locale>() might be something I would CONSIDER writing to address the suggestion that was made to me. I was trying to get across the idea that these statements all start to look alike and interchangeable at some point, at least to me. I know that this is not actually the case but it SEEMS like it sometimes. Fundamentally, I'm just expressing frustration with myself that it isn't more intuitive by now which of these statements is the one to use and which ones don't even make sense. I know (now) that the statement in question wouldn't actually compile or make sense and I didn't actually try to compile it anywhere. It was strictly a hypothetical and I truly think it is reasonable to toss out a hypothetical now and again even if it is only to dismiss it very quickly as the responders rightly did. I will continue to do that - very sparingly I expect - and do so at my own peril. Maybe some of you will disgusted with me for doing so and stop responding to me. If so, that's life. I'll do what penance is needed to get back into everyone's good graces or move on to some other discussion group if I have to. > (Naturally this does not apply to posts that intentionally illustrate > code that does not compile, but such posts invariably include verbiage > that indicates that the code is intentionally illegal.) > -- Rhino
From: Rhino on 23 May 2010 14:55
Arne Vajh�j <arne(a)vajhoej.dk> wrote in news:4bf92f34$0$273$14726298 @news.sunsite.dk: > On 22-05-2010 23:14, Patricia Shanahan wrote: >> Rhino wrote: >> ... >>> I probably tend to overbuild a lot of the time anyway, in the sense of >>> adding functionality that isn't all that likely to be used. My current >>> thread about the internationalization/localization is proof of that. I >>> tend to anticipate needs that others aren't sure will ever happen. Not >>> all the time of course; it's just a tendency, not an obsession ;-) >> ... >> >> I also get tempted to overbuild. When I started programming, there was >> some justification, because making design changes in a large program was >> difficult and risky. >> >> These days, it is so easy to refactor that there is generally little >> benefit to adding complexity that is not needed for immediate needs. >> >> The exception is designing APIs that will be used in code outside your >> control. > > API's is a problem because you the most optimal refactoring may > expose an incompatible API. > > But I believe that there are also other cases where refactoring > is not so easy. > > One example is the topic of the thread. Internationalizing an > existing app is not difficult, but it is usually a lot of work. > > I18N is a well-known counter-argument to YAGNI. > > Arne > > > YAGNI? Sorry, I don't know that acronym..... -- Rhino |