what is the correct way to write a meaningful test for extending a class with the super keyword?
class FooBase<T> {
final T data;
const FooBase(this.data);
}
class Foo<T> extends FooBase<T> {
const Foo(T data)
: super(data);
}
I suppose super(data) ist passing the constructor parameter to the constructor of the base class (I do not know a lot about dart).
You can only test if super was called by observing its behavior. You have to check the base classes constructor for what it is doing with the parameter and then see if you can observe if that happened (if possible). Example: If the base class constructor is assigning the parameter to a field that you can access from the outside, you can assert on that parameter being set. This only works if
You can access the field from your test code. Access in this context does not mean to access it directly or via a getter. Any means of observing that the field has been set should be sufficient.
The class under test is not setting the field itself (there is probably no way to decide which constructor set the field).
Related
I'm trying to get a value of a field from inside a nested class in Kotlin, however, I'm having some difficulties with the logic. Somewhere I saw that it is possible through an interface, but I don't know where to start.
A simple sample:
class ExternalClass {
class InternalClass {
val internalValue = 2
}
val externalValue = InternalClass().internalValue
}
fun main(args: Array<String>) {
print(ExternalClass().externalValue)
}
The easiest way (and most obvious) to achieve this would be to instantiate the InternalClass class inside the External, however, in some cases, it would be necessary to pass several parameters in the Internal's constructor, which would not be the case.
So how would it be possible to do this through an interface?
Any idea or insight will be welcome!
Thank you!
Taking a step back, it is nonsensical for the outer class to want to access a stateful property of some arbitrary instance of the nested class. There's no reason for an arbitrary instance's state to be useful. The only reason the outer class would need to access a property of the other class is if it is doing something with a specific instance of the inner class, in which case it would already have an instance of it on which to access its property.
In your example code, the nested class is weird because it defines a property that can only ever hold a value of 2. So every instance of the class is reserving memory for a property to hold a duplicate of that same value, even though it should really be a constant that is shared by all instances.
If the value you want to access is a constant (the same value for all instances), then it would make sense to want to access it regardless of instance because it doesn't have anything to do with a specific instance. To make it constant, it should be defined in a companion object like this. Then it can be accessed through the name of the nested class without creating an instance of it.
class ExternalClass {
class InternalClass {
companion object {
val internalValue = 2
}
}
val externalValue = InternalClass.internalValue
}
An interface would have nothing to do with this kind of thing.
If the base class has an abstract method or property, than these members must be overriden in the child class. The documentation says that i must use key word 'override' every time for such members, because i must implement methods or initialize properties in the child class. For example:
abstract class Dwelling {
abstract val buildingMaterial: String
abstract fun hasRoom() : Boolean
}
class RoundHut : Dwelling() {
override val buildingMaterial = "Stone"
override fun hasRoom() : Boolean {
return true
}
}
If an abstract method and a property must be overriden and implemented in child class any way (and compiler know this), than why we should write 'override' key word every time?
When you find yourself reading and understanding the implementing class, you have the explicit information that you're currently investigating an overridden one as it's explicitly marked as such. Kotlin likes to make things explicit and the documentation states
[...] we stick to making things explicit in Kotlin. So, Kotlin requires explicit modifiers for overridable members (we call them open) and for overrides
Java has an #Override annotation that is optional and not used by everyone although it has been considered a best practice (even as per Effective Java). Kotlin goes one step further by making it a compiler-enforced requirement.
I am trying to call the super constructor from a class using a method. The whole setup looks like this:
class Straight(hand: Hand) extends Combination(Straight.makeHandAceLowIfNeeded(hand), 5)
object Straight {
private def makeHandAceLowIfNeeded(hand: Hand): Hand = {
...
}
}
While this does compile, it has some rather odd runtime behaviour. While debugging, I noticed that the Straight instances have the "hand" property defined twice. Can somebody tell me what is going on, and what the proper way is to call the super constructor with different arguments?
In my use case, I want to call the super constructor with a modified hand in which I replaced a card compared to the original constructor argument.
Debugger screenshot with duplicate field:
.
It's a perfectly fine way to call the superclass constructor. These are two private fields and they don't conflict, though you can rename one of them to avoid confusion during debugging (or if you want to access the superclass' value from the subclass). However, the field should only be generated for a class parameter if it's used outside a constructor, and in your case it doesn't appear to be. Did you simplify the definition of Straight?
I have a C# class called MyCustomRuleTemplate which is inherited from Ektron.Cms.Content.Targeting.Rules.RuleTemplate class. In that I have added a constructor such as below
public MyCustomRuleTemplate(): base("someKey")
{
//Some code here
}
Its working fine without any error. If I given it as
public MyCustomRuleTemplate()
{
//Some code here
}
Im getting error like 'Ektron.Cms.Content.Targeting.Rules.RuleTemplate' does not contain a constructor that takes 0 arguments.
Can anybody help me to know why it is?
The reason you are seeing "does not contain a constructor that takes 0 arguments" when instantiating your class object using the second constructor is because when you call your constructor, c# tries to call the constructor on the base class as well, which in this case takes a parameter.
See this post on msdn:
http://msdn.microsoft.com/en-us/library/ms173115%28v=vs.80%29.aspx
Key parts:
"In this example, the constructor for the base class is called before the block for the constructor is executed. The base keyword can be used with or without parameters. Any parameters to the constructor can be used as parameters to base, or as part of an expression. For more information, see base.
In a derived class, if a base-class constructor is not called explicitly using the base keyword, then the default constructor, if there is one, is called implicitly."
And: "If a base class does not offer a default constructor, the derived class must make an explicit call to a base constructor using base."
I am experiencing a weird behavior by Scala handling of superclass constructors.
I have a really simple class defined in the following way
package server
class Content(identifier:String,content:String){
def getIdentifier() : String = {identifier}
def getContent() : String = {content}
}
and a simple subclass
package server
class SubContent(identifier:String, content:String) extends Content(identifier, content+"XXX")){
override def getContent():String = {
println(content)
super.getContent
}
}
What's really strange is that in the subclass there are duplicates of the superclass attributes, so if i create a new object
var c = new SubContent("x","x")
the execution of
c.getContent
first prints out "x" (The valued provided to the subclass constructor), but returns "xXXX" (The value provided to the superclass constructor).
Is there any way to avoid this behavior? Basically what I'd like to have is that the subclass does not create its own attributes but rather just passes the parameters to the superclass.
It's doing exactly what you told it to do. You augmented the 2nd constructor parameter when passing it on to the superclass constructor and then you used the superclass' getContent to provide the value returned from the subclass' getContent.
The thing you need to be aware of is that constructor parameters (those not tied to properties because they're part of a case class or because they were declared with the val keyword) are in scope throughout the class body. The class' constructor is that part of its body that is outside any method. So references to constructor parameters in method bodies forces the constructor parameter to be stored in a field so it can have the necessary extent. Note that your println call in getContent is causing such a hidden constructor parameter field in this case.
Replying to comment "Is there an alternative way to define it in order to avoid this? Or at least, if I never refer to the parameters of the subclass constructors their fields will be allocated (Wasting memory)?":
If the only references to plain constructor parameters (*) is in the constructor proper (i.e., outside any method body, and val and var initializers don't qualify as method bodies) then no invisible field will be created to hold the constructor parameter.
However, If there's more you're trying to "avoid" than these invisible fields, I don't understand what you're asking.
(*) By "plain constructor parameters" I mean those not part of a case class and not bearing the val keyword.