|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On January 14 2017 04:32 travis wrote:
Well what's the reason I am not supposed to do this again? Because I do want there to be only one of them and I do want to be able to access it from other classes (geesh I don't want to write a thousand getters).
I guess I can make everything non static, but then none of my GUI can be static either. changes my whole design a lot
http://lmgtfy.com/?q=why are global variables bad
Seriously, there's a whole page of people explaining that for you in any language you prefer.
It's not even the static that I object to, although static has all its own problems. It's the combination of public and static (without final), which makes it particularly egregious.
static private fields are not very nice and have their own issues, but they are sometimes the neatest solution (not often).
But okay, I can go along with the above. Experience is the best teacher. There is nothing technically wrong with global variables. They are a fully functioning part of almost all programming languages, often for good reasons. It's just that actually using them almost always leads to problems (sometimes very big problems) down the road, when you "just" want to add some minor functionality.
|
I googled it don't get sassy 
|
On January 14 2017 05:26 travis wrote:
in an unrelated thought, it seems really stupid that java can't cast int to string, I have to use Integer.toString() or some other method, and yet I can simply say that (the string = the int + ""). I'd love to have that one explained to me.
Plenty of reasons why this is terrible.
For one, what is "string = int +'1'" supposed to do? If int = 1, are you getting '11' as the resulting string? '2'? Or what if I want "string = 1+1+'1'"?
Assuming you have a response to those questions which is reasonable and generally accepted by everyone else using your scripting language, how are you going to implement this, and for all other object types you think Strings should account for? Whatever your solution, you're going to add a lot of overhead to the + operator whether it's runtime or compiler.
Obviously with higher level programming languages, there's a lot of shortcuts and behind the scenes thinking that the language does for you. But not wanting to be explicit with your instructions is not a very good reason.
|
On January 14 2017 06:11 WolfintheSheep wrote:Show nested quote +On January 14 2017 05:26 travis wrote:
in an unrelated thought, it seems really stupid that java can't cast int to string, I have to use Integer.toString() or some other method, and yet I can simply say that (the string = the int + ""). I'd love to have that one explained to me. Plenty of reasons why this is terrible. For one, what is "string = int +'1'" supposed to do? If int = 1, are you getting '11' as the resulting string? '2'? Or what if I want "string = 1+1+'1'"? Assuming you have a response to those questions which is reasonable and generally accepted by everyone else using your scripting language, how are you going to implement this, and for all other object types you think Strings should account for? Whatever your solution, you're going to add a lot of overhead to the + operator whether it's runtime or compiler. Obviously with higher level programming languages, there's a lot of shortcuts and behind the scenes thinking that the language does for you. But not wanting to be explicit with your instructions is not a very good reason.
I don't think you are understanding what I am saying. I am saying that java lets you turn an integer into a string by calling it a string and appending "" to the end of it. But it doesn't simply let you call an int a string or even cast an int to a string. To me, this is very silly. Why should I use String = Integer.toString(int), when I can use String = int + "".
I mean, I am sure there are specific times I might want to. But in general, I don't get it. It seems to automatically cast in this specific instance but it won't cast if you actually ask it to cast for you.
|
String a = "" + 5;
works. It's fugly, but it works. The reason it works is because internally some magic happens. That same magic doesn't happen if you simply say:
String a = 5;
and that's a good thing. For that matter, you cannot cast an int to a string in any language I know of. Try in Python:
foo = "hello"
bar = foo + 5
And what your conversion is doing is not casting. It works differently.
|
@travis:
The only reason why you can do one but not the other is that the Java devs decided this way. There is no technical reason. No really convincing arguments. It just is because somebody said so. That will be the answer to many many questions about certain quirks of certain programming languages. Each language has some odd property which can only be explained with personal taste of the devs.
If there is one language you dont think the above rule applies to then you simply think the same way as the devs of that particular language do.
|
On January 14 2017 06:34 travis wrote:Show nested quote +On January 14 2017 06:11 WolfintheSheep wrote:On January 14 2017 05:26 travis wrote:
in an unrelated thought, it seems really stupid that java can't cast int to string, I have to use Integer.toString() or some other method, and yet I can simply say that (the string = the int + ""). I'd love to have that one explained to me. Plenty of reasons why this is terrible. For one, what is "string = int +'1'" supposed to do? If int = 1, are you getting '11' as the resulting string? '2'? Or what if I want "string = 1+1+'1'"? Assuming you have a response to those questions which is reasonable and generally accepted by everyone else using your scripting language, how are you going to implement this, and for all other object types you think Strings should account for? Whatever your solution, you're going to add a lot of overhead to the + operator whether it's runtime or compiler. Obviously with higher level programming languages, there's a lot of shortcuts and behind the scenes thinking that the language does for you. But not wanting to be explicit with your instructions is not a very good reason. I don't think you are understanding what I am saying. I am saying that java lets you turn an integer into a string by calling it a string and appending "" to the end of it. But it doesn't simply let you call an int a string or even cast an int to a string. To me, this is very silly. Why should I use String = Integer.toString(int), when I can use String = int + "". I mean, I am sure there are specific times I might want to. But in general, I don't get it. It seems to automatically cast in this specific instance but it won't cast if you actually ask it to cast for you.
Ah.
Okay, in that case apparently it's because Java uses a StringBuilder with the + operator. So it's basically a hack using Java's backend magick.
|
@travis: If you're concerned about code verbosity (type conversion, not wanting to write getters and setters etc.) then perhaps Java isn't the language for you 
Also, go learn some C (just the basics). It'll shed some light on certain problems and you'll understand some higher-level concepts better (and appreciate/or not how much higher level languages are doing for you).
|
Hyrule19091 Posts
On January 14 2017 06:50 Acrofales wrote:
String a = "" + 5;
works. It's fugly, but it works. The reason it works is because internally some magic happens. That same magic doesn't happen if you simply say:
String a = 5;
and that's a good thing. For that matter, you cannot cast an int to a string in any language I know of. Try in Python:
foo = "hello"
bar = foo + 5
And what your conversion is doing is not casting. It works differently.
I mean...you can in PHP
|
|
|
On January 14 2017 09:50 tofucake wrote:Show nested quote +On January 14 2017 06:50 Acrofales wrote:
String a = "" + 5;
works. It's fugly, but it works. The reason it works is because internally some magic happens. That same magic doesn't happen if you simply say:
String a = 5;
and that's a good thing. For that matter, you cannot cast an int to a string in any language I know of. Try in Python:
foo = "hello"
bar = foo + 5
And what your conversion is doing is not casting. It works differently. I mean...you can in PHP
It works funny in PHP too 
'hello' + 5 = 5
'2' + 5 = 7
'a2' + 5 = 7
'2a' + 5 = 7
'a2a' + 5 = 5
|
https://sourcemaking.com/refactoring/replace-conditional-with-polymorphism
I sometimes try to do the refactoring stated above (replacing if-else or switch with polymorphism) but often one problem remains
when you have different Bird classes like in the example, when appropriate Bird objects are being created, someone has to decide what kind of bird to create. To do it, the creator must use a conditional, like:
if (bla bla bla)
bird = new NorwegianBlue()
else if (bla bla)
bird = new Swallow()
//etc...
it seems like you are just relocating the complexity to somewhere else by doing this refactoring. It is still an improvement though, since you will likely create them in 1-2 place, but use them in many places, you don't have to check the type every time you use them.
A layer has to take the responsibility of creating the correct type of object. Maybe those birds are stored in a db so data access layer can do it.
am I missing something here? any advice to do it better?
|
Yes, at some point you need to differentiate and its usually through an if block or something that is secretly equivalent to that (alternatives usually involve some kind of reflection shenanigans). That piece of code is usually in some kind of factory class or method. You don't repeat it anywhere. Ideally you can even hide that there are multiple subclasses.
If you have the if block in one method of your class, you're likely to have it in a couple of other methods as well. And you don't want the same if block in 10 places.
|
On January 14 2017 21:54 spinesheath wrote:
Yes, at some point you need to differentiate and its usually through an if block or something that is secretly equivalent to that (alternatives usually involve some kind of reflection shenanigans). That piece of code is usually in some kind of factory class or method. You don't repeat it anywhere. Ideally you can even hide that there are multiple subclasses.
If you have the if block in one method of your class, you're likely to have it in a couple of other methods as well. And you don't want the same if block in 10 places.
Cool. I was thinking that I was missing something or doing it wrong.
|
|
|
Really depends on your conditions but you can often use maps with factory objects. Java example:
private final Map<Key, BirdFactory> factMap = new HashMap();
{
factMap.put(keyNo1, () -> new Swallow());
factMap.put(keyNo2, () -> new Raven());
// ...
}
public Bird createBird(Key key) {
BirdFactory fact = factMap.get(key);
if (fact == null) {
return null; //or some default bird implementation perhaps
}
return fact.create();
}
Then, if you need to create birds for different birdcages you can assign a key to each cage (in a database, read from a file, fetch over the internet, whatever) and use that to create the bird completely without any if's.
|
On January 14 2017 21:34 mantequilla wrote:
if (bla bla bla)
bird = new NorwegianBlue()
else if (bla bla)
bird = new Swallow()
//etc...
it seems like you are just relocating the complexity to somewhere else by doing this refactoring. It is still an improvement though, since you will likely create them in 1-2 place, but use them in many places, you don't have to check the type every time you use them.
I think this actually reduces two conditionals to one. The caller already had to decide which type of bird to create:
if (bla bla bla)
bird = new Bird(NORWEGIAN_BLUE)
else if (bla bla)
bird = new Bird(SWALLOW)
So all the refactor does is remove that conditional from the class, which is a Good Thing(tm). (Actually, it doesn't get rid of the conditional - the compiler still has to do the virtual dispatch which is probably a little slower. But it makes the compiler do it for you, which is almost always good.)
|
On January 18 2017 03:57 Cyx. wrote:
So all the refactor does is remove that conditional from the class, which is a Good Thing(tm). (Actually, it doesn't get rid of the conditional - the compiler still has to do the virtual dispatch which is probably a little slower. But it makes the compiler do it for you, which is almost always good.)
Virtual dispatch is pretty damn fast. Especially compared to a conditional with more than 2 branches. Also a conditional messes with branch prediction.
|
|
|
On January 18 2017 04:59 spinesheath wrote:
Virtual dispatch is pretty damn fast. Especially compared to a conditional with more than 2 branches. Also a conditional messes with branch prediction.
Yeah you're right actually, I was thinking there was a test involved in virtual dispatch for some reason but it's just a lookup in an array which is a lot faster than the test every time.
|
|
|
|
|
|
EPT
