Introduction to Kotlin | Application of Kotlin Part 4
So how many of you love design patterns? It’s OK.
Singleton, let’s see. Singleton in Java.
Now, this is a singleton in Java, which is fantastic. Not advocating the use of singletons, I’m just saying this is a singleton in Java.
And let’s take a look at the singleton in Kotlin. We’ll go here, and we’ll do a singleton in Kotlin. That’s a singleton in Kotlin, because we essentially have objects.
In Kotlin, we have both. We have objects, which just represent a single value, and classes. So here, I can just create an object, which is a single Kotlin.
And it has a property. And, of course, I can access this by just saying Singleton, Kotlin, and property, and then assign a value. No, you don’t assign a value to global things. You don’t have singletons that you can change values on.
That’s a no-no. For read-only, though, it’s kind of nice. And notice that I’m not advocating, again, saying oh, well, since Kotlin makes singletons so easy.
Let me just create singletons throughout my entire code base. Nope, not saying that either. What else? So one thing that we added to Kotlin is the concept of a type alias.
So here, I have, for instance, a data class, and I have a name, customer name, and an email. Now, notice the customer name is actually the same thing as a string. But it is providing me with more semantics.
Here, I have and I’ve done that using this thing over here called type alias customer name to string, meaning that this property is actually of type string.
But to provide more meaning, to provide more semantics, I’m using the name customer name. But I can pass in. It will verify this at runtimes at string, at compile times at string. You can pass string where it’s customer name.
Now, this comes in useful, actually, sometimes combining this type alias with something else, which is called the deprecated annotations.
And I’ll show you how this works. So let’s say that I have a class, customer, and we’re going to now come here. And I’m going to rename this.
Well, actually, I’ll just comment it out. And what I’ve done here is essentially created a deprecated annotation that comes with Kotlin, that you say a customer is now called awesome customer, and replace with awesome customer. And this actually doesn’t work.
Eventually, it will be implemented so that you can do Alt-Enter and replace that in the IDE. And notice, that now type alias, I’m saying customer is awesome customer, So what happens here is that now when I hover to this, it says awesome customer is deprecated.
I did that the wrong way around. Awesome customer is deprecated, and you should use customer instead.
Now, the good thing about that is that this allows you to refactor things and rename things without potentially breaking people’s codes.
But then you’re probably thinking, why do I care about breaking people’s code? Let me just do that myself.
So it is actually quite useful in that sense. And we use it quite a bit. You can do a multiple phase change.
I’ll rename something, and then issue a warning. And then on the next one, I will remove that, deprecate it, and away we go.
And nobody can complain because we don’t complain as developers. So that was a joke. Here’s another example. Of course, it’s not funny when you say that was a joke.
So I have conditional expressions, Kotlin conditional expressions here. So for now, just let’s focus on this one.