Well, it's brittle because if the name of a class changes, the code breaks -- although it probably still compiles. You find out that the program is broken only when you run it (if you're lucky; you might not find out until a CUSTOMER runs it, which is far worse.)
Generally, brittle code is code that depends on details that shouldnt really matter, especially in ways so that changing one thing breaks a number of really unrelated things.
EFH wrote:Well, it's brittle because if the name of a class changes, the code breaks
"Breaks" in what sense?" It changes, sure. But I had assumed that the intent of the code was to provide the correct class name. Even if the class name changes. Because, after all, that's what the code says to do. So how is that broken? Should we assume the coder was trying to do someting else entirely? Based on what?
paul wheaton wrote:Suppose you want to change the string: do you change your class name?
I would think that depends on the intent of your change. Do you want to change the string, or do you want to change the class name? Is the string intended to reflect the class name, or not? This goes back to my previous comments. To me it seems perfectly reasonable to want to, say, log the actual name of the class that was executing this method. Which this does.
PW wrote:Suppose you want to change the class name: will you remember to change your string? Or will your program still work with the new string?
From what we've seen so far, the original intent of the program was probably to show the actual class name. The string will change automatically in reponse to the change of the class name. And this seems like a good thing. What's the problem?
From what we've seen so far, the original intent of the program was probably to show the actual class name.
And that's where I have advantage over you. BWA HA HA HA HA HA (cough cough) .......
So this is related to an assignment, which we are all trying to not directly discuss.
But I happen to have been the nitpicker for this assignment where it was used.
Suppose you have a shopping cart full of groceries and the user asks for a list of the stuff in the basket. You have a class called Cheese which contains info on variety of cheese, how stinky the cheese is and other interesting cheesy attributes. When asked to list the stuff in the cart, do you report the class name, or would that make the application brittle?
Joined: Jan 16, 2007
I am beginning to understand why the use of this makes for brittle code.
I didn't see this mentioned, but can somebody speak to the question of when its appropriate to use this method?
I know that some people use it for some logging stuff, but the uses I've seen seem stupid to me.
I'm sitting here trying to think of a case ... something to do with debugging or logging something for a developer ... but I cannot help but think all of the exception stuff takes care of any need for that sort of thing.
If nothing else, use of this sort would be rather advanced. I probably wouldn't use it unless there was no other way.
I use it for logging warnings ... in case the customer asks why the "City Name" field is blank in the report ... or whatever ... without throwing an exception and killing the processing of all the other records that follow the one with the blank field (left blank by the customer, not something controlled by my application). This seems to save time particularly in the case where I have subclasses and I want to know which subclass called the shared (superclass) code. An alternative would be to hard code the class name in the logging statement, but then you would need to remember to change the statement (or the String which is assigned to the String variable which holds the class name for multiple logging statements in the same class) if you changed the name of the class.
JavaBeginnersFaq "Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt