|
"Ah, hello there."
;
initialString.toUpperCase();
System.
out
.println(initialString);
--> “Ah, hello there.”
See? The string didn’t change to be in all upper-case. Were you expecting
Obi-Wan to be screaming “AH, HELLO THERE.”? Too bad.
Sure, we called the
toUpperCase()
method. But that does not modify the
existing String we made; it makes a new one with those modifications.
And what did we do with the String that was created when we called
toUpperCase()
? Nothing! It vanished into the ether. We didn’t assign it to a
variable or use it inside a conditional.
Another failure:
String sillyString =
"haha dank memerinos!"
;
sillyString.substring(
5
);
System.
out
.println(sillyString);
> “haha dank memorinos!”
Please kill me.
But again, that String method did not change the value of our String, it
created a new one that we ignored. We did not change sillyString to be
“dank memerinos!”
In fact, if you look at the methods available on the String class, none of the
ones that “change” or “modify” the String are void . Instead, Java creates a
new String based off the original one and returns that for you to use.
Basically, you don’t need to worry about why strings are “immutable”; just
ensure you don’t find yourself trying to change a String instead of creating
new ones based off the original.
Oh, and here’s how you’d properly write those examples:
String initialString =
"Ah, hello there."
;
String initialStringUpper = initialString.toUpperCase();
String sillyString =
"haha dank memerinos!"
;
//Reusing the same variable
sillyString = sillyString.substring(
5
);
CHAPTER 12: THE JAVA
CINEMATIC UNIVERSE
"I know what it's like to lose. To feel so desperately that you're right, yet to
fail nonetheless. It's frightening. Turns the legs to jelly. I ask you, to what
end? Dread it. Run from it. Destiny arrives all the same. And now, it's here.
Or should I say, I am." – Thanos
In Java, the big bad isn’t Thanos. It’s complexity.
Complex code is the enemy of all programmers. At least the good ones. The
more complex your source code, the harder it is to fix issues, to add new
functionality to it, to hand it off to someone else to work on, you name it.
And it only makes it easier to introduce bugs, confuse yourself, and regret
ever starting the project at all.
There are a lot of ways to battle complexity. You can have small, well
named methods. Straightforward and meaningful property and variable
names. Comments on particularly tricky portions of code.
But I’m moreso talking about complexity at scale .
We’ve really only seen one or two classes at a time so far in my little
examples. But other than superman (yawn), no superhero can or should try
do everything .
That’s why it’s important for Java superheroes to band together and take on
complexity as a team. Many times you can recruit classes from Java to help
you out, rather than writing that code in your current classes, or writing new
classes on your own.
Need to store data in a file?
Need to connect to a database
Need to generate a random number?
Need to make a network call?
Need to display a user interface with buttons, input fields, widgets,
and that kinda jazz?
Java has a lot of premade classes available to us to help with common tasks
like these.
These are all part of the “Java standard library” that I mentioned at the
beginning of the book. Basically, they’re ready-to-go when you need them,
as part of Java itself.
They might not be the sexiest superheroes around, but they are there for
you. Unlike your father that left for milk in the middle of the night and
never returned. I miss you, dad.
Packages
One way to reduce complexity and keep things tidy is to organize your
classes into “packages.”
If you don’t specify a package at the top of your class, you’re considered to
be in the “default” package. Never do this unless you’re just messing
around. Even then, stop it. Get some help.
What is a package, though?
You can think of it like a literal brown box package that contains your
classes. When boxing things up for storage or for a move in real life, you
probably have some rhyme or reason to how they’re grouped together.
That’s what a package is for.
Logically, it’s a way to group together related classes; bundling like classes
with other like classes.
In practice, it’s the folder that your Java file is in, combined with a package
declaration at the top of your Java file.
For example, here’s an example, so you can view an example:
Note that I’m using IntelliJ because I’m not a serial killer.
I have a big daddy folder for my project called MemeStore. That’s just what
I wanted to call it, the name doesn’t matter in the slightest.
I then have a folder called “src” that will contain alllllll my Java stuff. This
is just a standard thing for most Java developers to do, but it’s not
mandatory.
Then my package! I just called it “app” because I’m creating an application.
Not very creative, I realize.
Note: A package is just a folder! You could make the directories manually
inside Windows Explorer, or from your command prompt. Doesn’t matter. I
used IntelliJ because I’m not a sociopath.
Then, like I mentioned, the class declares its package at the very top of the
file.
Do'stlaringiz bilan baham: | 
