I'm fiddling around with this code where I have a base class Node which can be extended:
open class Node
class SubNode : Node()
Now, I have a Behavior class that can be attached to a node, and when this attachment happens, the behavior object is invoked:
open class Behavior {
fun attach(node: Node) {
println("Behavior was attached to a node")
}
}
open class Node {
var behavior: Behavior? = null
set(value) {
field = value
value.attach(this)
}
}
This works, but could this be generified in such way that the type of the attach method would always refer to the actual type of the attached Node? For instance, if the Behavior class was extended like this:
open class Behavior<NodeType: Node> {
open fun attach(node: NodeType) {
}
}
class SubBehavior : Behavior<SubNode>() {
override fun attach(node: SubNode) {
}
}
I've tried various ways of setting up the types in Node class, but can't figure any other way than passing the actual subclass type to the base class (which seems rather cumbersome):
open class Node<SubType: Node> {
var behavior: Behavior<SubType>? = null
}
class SubNode : Node<SubNode>()
Is there a way to do this in any other way?
I think what you need are self types, which don't exist in Kotlin (at least, not yet).
Using recursive generics like you did is the most common way around the problem.
That said, I have trouble understanding your use case here for intertwining these 2 classes together this way. Like how is behaviour used inside your node, etc.
Related
I'm making a simple game to learn some kotlin, and I'm a little confused on the best way to change this around using OOP.
I have a class for backpack setup so that it has another class called items that will be different types of items. Below I've recreated a simple version of what I have.
class backPack {
private val item: Item
init { item = Item() }
fun display() {
item.display()
}
}
class Item {
fun display() { println("Your item!") }
}
fun main() {
val examplePack = backPack()
examplePack.display()
}
I want to change the backPack class to allow for different types of items. For example, health potions and mana potions. I considered making the item an open class, then having something like this:
class healthPotion : Item() {
override fun display() {
println("health potion!")
}
}
class manaPotion : Item() {
override fun display() {
println("mana potion!")
}
}
which seems correct, but I'm a little stuck on how to refactor the backpack class to allow different types of items and I want to make sure this seems like a proper way to do this. Any assistance is very appreciated, thank you!
That's basically the idea! If your BackPack class (it should start with a capital by convention) handles Items, then any class that has that type will work. You have two options - inheritance, and composition.
Inheritance is where you build a hierarchy of classes, e.g.:
open class Item {
val weight: Int
fun Describe()
}
open class Potion : Item() {
fun drink() {}
}
// this is a Potion, and a Potion is an Item, meaning this is an Item
class ManaPotion : Potion() {
override fun drink() {
println("whoa!")
}
}
// etc
The problem there is you're locked into a rigid hierarchy - what if you had a StaleBread that's a Food, but you also want it to be a Weapon? You can use interfaces to compose your object by giving it multiple types, not just a parent:
open class Item
interface Food {
fun eat() {
println("yum")
}
}
interface Weapon {
fun attack() {
println("RARGH")
}
}
class StaleBread : Item(), Food, Weapon
Because StaleBread has all of those types, you can treat it as any of them, because it is all of them. Because it's a Weapon, it's guaranteed to have an attack() method, etc. You can add it to a List<Food>, because it is a Food. Being able to treat objects as different types is called polymorphism. So you're able to compose an object from different types, to give it certain properties, certain behaviours, etc
Your example should work as-is because you're handling Items in your backpack, and your two potion classes are both Items (descendants of that class, specifically, since you're inheriting from the Item class). There are lots of ways to organise it - if you get into some tutorials about inheritance, composition and polymorphism (this is only a simple overview that skips over a bunch of things) you'll start to get some ideas about how to move forward
oh yeah, for the actual backpack, you probably want something like this:
class BackPack {
private val items = mutableListOf<Item>()
fun addItem(item: Item) {
// here you could do things like check it doesn't exceed the allowed weight
// or capacity of the backpack
items.add(item)
}
}
This way, your backpack can contain multiple Items, and you can control how those are accessed through the class's functions and properties. Anything which is an Item type can go in there!
If you want to be able to change which item is in the bag, the property should be a var. If you want the bag to be able to be empty, then it should be a nullable property (declared with a ? after the type so it can hold null).
By the way, class names should always start with a capital letter so your code will be easier to read. And you can initialize properties at the declaration site instead of using a separate init block.
class Backpack {
var item: Item? = null
fun display() {
item?.display()
}
}
Your generic Item() doesn't seem like it would be useful in practice. Therefore, Item should probably be either an abstract class or an interface. A general OOP principle is that you should avoid deep class hierarchies. If your superclass doesn't contain logic that must be shared by all its children, it should probably be an interface instead.
I have the following code setup;
abstract class GenericQuestionEditor() {
protected abstract var data: GenericQuestionData
}
but then when I create EditorSimple() it throws an error when I try to set data to DataSimple(), why?
class EditorSimple(): GenericQuestionEditor() {
override var data = DataSimple()
}
my GenericQeustionData and DataSimple() are setup like this;
abstract class GenericQuestionData {}
class DataSimple: GenericQuestionData() {}
it doesn't complain if I create this function in GenericQuestionEditor()
fun test() {
data = DataSimple()
}
Why do I get an error on data in EditorSimple()? It should recognize it as a subtype and it should be allowed as I understand.
I feel like the answer is found in the kotlin documentation but i'm not sure how to configure it in this case since they are not passed values or part of a collection.
You need to specify the type explicitly:
class EditorSimple(): GenericQuestionEditor() {
override var data: GenericQuestionData = DataSimple()
}
Without the type annotation, the type of data would be inferred to be DataSimple, which doesn't match the type of its super class' data. Even though the types are related, you can't override writable a property with a subtype. Imagine if I did:
class SomeOtherData: GenericQuestionData()
val editor: GenericQuestionEditor = EditorSimple()
editor.data = SomeOtherData() // data is of type GenericQuestionData, so I should be able to do this
But, editor actually has a EditorSimple, which can only store DataSimple objects in data!
I have a class as below
open class KotlinBase {
companion object {
const val TAG = "testing"
}
}
And a child of it as
class KotlinChild : KotlinBase()
When I try to access TAG from a Java class, I could either
public class JavaOther {
String test1 = KotlinBase.TAG; // This is okay
String test2 = KotlinChild.TAG; // This is okay
}
However, when accessing from Kotlin class, I can't access through the Child.
class KotlinOther {
val test1 = KotlinChild.TAG // Compile/Syntax error
val test2 = KotlinBase.TAG // This is okay
}
Why can't my Kotlin class access the inherited variable TAG through KotlinChild?
It's a design decision allowing you to avoid ambiguities. - child classes can have their own companion objects with fields/methods having same names as those in the parent.
By restricting access to companions only through the actual class, problems with ambiguous field/method shadowing do not exist anymore.
Also, companion objects are not static members known from other languages. Although, the majority of use cases overlap.
Additionally, remember that
KotlinBase.TAG
is a shortcut for:
KotlinBase.Companion.TAG
I'm trying to understand why the following code throws:
open class Base(open val input: String) {
lateinit var derived: String
init {
derived = input.toUpperCase() // throws!
}
}
class Sub(override val input: String) : Base(input)
When invoking this code like this:
println(Sub("test").derived)
it throws an exception, because at the time toUpperCase is called, input resolves to null. I find this counter intuitive: I pass a non-null value to the primary constructor, yet in the init block of the super class it resolves to null?
I think I have a vague idea of what might be going on: since input serves both as a constructor argument as well as a property, the assignment internally calls this.input, but this isn't fully initialized yet. It's really odd: in the IntelliJ debugger, input resolves normally (to the value "test"), but as soon as I invoke the expression evaluation window and inspect input manually, it's suddenly null.
Assuming this is expected behavior, what do you recommend to do instead, i.e. when one needs to initialize fields derived from properties of the same class?
UPDATE:
I've posted two even more concise code snippets that illustrate where the confusion stems from:
https://gist.github.com/mttkay/9fbb0ddf72f471465afc
https://gist.github.com/mttkay/5dc9bde1006b70e1e8ba
The original example is equivalent to the following Java program:
class Base {
private String input;
private String derived;
Base(String input) {
this.input = input;
this.derived = getInput().toUpperCase(); // Initializes derived by calling an overridden method
}
public String getInput() {
return input;
}
}
class Derived extends Base {
private String input;
public Derived(String input) {
super(input); // Calls the superclass constructor, which tries to initialize derived
this.input = input; // Initializes the subclass field
}
#Override
public String getInput() {
return input; // Returns the value of the subclass field
}
}
The getInput() method is overridden in the Sub class, so the code calls Sub.getInput(). At this time, the constructor of the Sub class has not executed, so the backing field holding the value of Sub.input is still null. This is not a bug in Kotlin; you can easily run into the same problem in pure Java code.
The fix is to not override the property. (I've seen your comment, but this doesn't really explain why you think you need to override it.)
The confusion comes from the fact that you created two storages for the input value (fields in JVM). One is in base class, one in derived. When you are reading input value in base class, it calls virtual getInput method under the hood. getInput is overridden in derived class to return its own stored value, which is not initialised before base constructor is called. This is typical "virtual call in constructor" problem.
If you change derived class to actually use property of super type, everything is fine again.
class Sub(input: String) : Base(input) {
override val input : String
get() = super.input
}
Kotlin enables me to implement an interface by delegating to a primary constructor argument like so:
class Foo(xs : ArrayList<Int>) : List<Int> by xs { }
But this exhibits the backing implementer to the user. Delegating to an anonymous also seems to be ok:
class Foo() : List<Int> by ArrayList<Int>() { }
This hides the implementation details, but we loose access to features not provided by the interface, which in this case is mutability.
I would therefore like to delegate the implementation to a property that is not in the primary constructor. What I would like to have is similar to
class Foo() : List<Int> by xs {
val xs : List<Int> = ArrayList<Int>()
}
which doesn't compile.
Is it possible to have a property defined explicitly in the class body and still be able to delegate implementation to it?
This is not currently possible. The expression in the by-clause is computed only once before the construction of the class, so you cannot reference symbols of that class.
There is a request in the issue tracker to allow this, although it's almost definitely not going to be supported in Kotlin 1.0.
One funny workaround that sometimes works is to make the property which you want to be a delegate, a constructor parameter with the default value instead. That way it'll be accessible both in the by-clause and in the class body:
class Foo(val xs: List<Int> = ArrayList<Int>()) : List<Int> by xs {
fun bar() {
println(xs)
}
}
Keep in mind though that xs in by xs is still calculated only once here, so even if xs is a var property, only the default value provided in the constructor will be used. It's not a universal solution, but sometimes it can help.
Expanding on the answer of Alexander Udalov, I came up with a solution using a private base class
private open class FooBase(protected val xs : MutableList<Int>) : List<Int> by xs { }
class Foo() : FooBase(ArrayList()) {
fun bar() {
xs.add(5)
}
}
Now I can have access to the property backing my interface implementation but am not restricted to operations provided by that interface while still hiding the actual implementation from the user.
Note: Although it works, I get the following warning from IntelliJ IDEA 15 CE which arises from EXPOSED_SUPER_CLASS inspection: Deprecated: subclass effective visibility 'public' should be the same or less permissive than its superclass effective visibility 'private'. I'm not quite sure what the deprecated part here means – whether the warning will be removed in the future or this won't compile at some point. Anyway, we don't really have to use a private open class, abstract or simply open will do, because even if the user is allowed to create an instance of FooBase, there is not much he can do with it.
Update:
There is actualy a simple and compact solution that does not use any suspicious behaviour:
class Foo private constructor(private val xs: ArrayList<Int>) : List<Int> by xs {
constructor() : this(ArrayList<Int>()) { }
}