I have difficulty understanding the concept of Abstraction. By definition abstraction is the process of hiding certain details and showing only essential information to the user from w3schools.
So below is my class -
open class SimpleClass {
fun engine() {}
}
class ChildSimpleClass : SimpleClass()
abstract class AbstractClass {
abstract fun engine()
}
class AbstractClassImpl : AbstractClass() {
override fun engine() {}
}
interface Interface {
fun engine()
}
class InterfaceImpl : Interface {
override fun engine() {}
}
fun main(){
//first case
val simpleClass: SimpleClass = ChildSimpleClass()
simpleClass.engine()
//second case
val abstractClassImpl:AbstractClass = AbstractClassImpl()
abstractClassImpl.engine()
//third case
val interfaceImpl: Interface = InterfaceImpl()
interfaceImpl.engine()
}
1.Does the first case qualify to be abstraction ?
2.If yes, then why do we say we achieve abstraction using "interfaces and abstract classes" and why not using normal classes ? from here and many other sources which I went through
3.If not, then why does it not qualify to be abstraction as my class only knows about ChildSimpleClass and not about the SimpleClass is this not hiding details about SimpleClass ?
you have multiple choices to do abstraction with. the first choice must be interface because you can implement multiple interfaces but not more than one class. for example, you can have a class that implements both a Driver and an Eater interface. but can't do that with classes. and then you can use an instance of your class as either one.
the second choice must be abstract classes. the difference between an abstract class and an interface is state. abstract classes can have state. and if you need state in your abstraction you should consider using abstract classes. for example a Driver might not need state, but a Car might need it to know if it's started or not(totally depends on your requirements)
the problem with an open class is that you can't force subclasses to implement a method. and also you always need to have implementations for your methods.
also, abstraction is not only about hiding details. it's also about setting rules for your class. for example a class Engine should always have a name and that changes when the type of engine changes. and a start() method that works based on name:
abstarct class Engine {
var isStarted = false
abstract val name: String
fun start() {
isStarted = true
println("engine $name started")
}
}
so as long as you can't define rules with open classes, you should not consider it an abstraction. but as Tenfour04 said in comments, This is just a semantic argument about the word abstraction. but it's important to know the difference.
Related
The simplest code to demonstrate the issue is this:
Main interface in Kotlin:
interface Base <T : Any> {
fun go(field: T)
}
Abstract class implementing it and the method:
abstract class Impl : Base<Int> {
override fun go(field: Int) {}
}
Java class:
public class JavaImpl extends Impl {
}
It should work, but it doesn't. The error is
Class 'JavaImpl' must either be declared abstract or implement abstract method 'go(T)' in 'Base'
If the JavaImpl class was in Kotlin, it would work. Also if the T was cast to String or Integer or any object, it would work too. But not with Int.
Is there any clever solution apart from using Integer and suppressing hundreds of warnings in Kotlin subclasses?
Update: created the issue.
Looking at the byte code we can see, that the Impl-class basically has produced the following function:
public go(I)V
where the parameter is a primitive integer. Also a synthetic bridge-function (go(Object)) is generated, which however would also be generated on the Java-side for such generic functions.
On the Java side however it doesn't suffice to have something like public void go(int field) in place. Now we need that go(Integer field)-function, which isn't present.
For me that sound's like an interop-problem that should probably be reported and linked back here again. Actually having had some time to investigate, there seem to be some issues already: KT-17159 and KT-30419, but also KT-5128 seem to relate to this problem. The kotlin compiler knows how to deal with this and doesn't need any further information about it in the class-file (i.e. the implementing Kotlin class knows, that it doesn't need to implement something like fun go(field : Int?)). For the Java-side such counterpart does not exist. I wonder whether this could even be fixed nicely with the compiler/byte-code or whether this will remain a specific interop-problem.
Some workarounds to deal with that problem (in case this is deliberate and not a real problem):
Add an additional function as follows to Impl:
fun go(field : Int?) = go(field ?: error("Actually the given field should never be null"))
// or simply:
fun go(field : Int?) = go(field!!)
That way you would not need to implement it. However then you would also expose that nullable function to the Kotlin side, which you probably don't want.
For that specific purpose it may seem more convenient to do it the other way around:
declare the class and the interface in Java and use it on the Kotlin side. That way you could still declare something like
abstract class KotlinClass : JavaInterface<Int> {
override fun go(field : Int) { // an IDE might suggest you to use Int? here...
// ...
}
}
You can use javap to analyze the problem, showing members of compiled interface and classes.
javap Base
public interface Base<T> {
public abstract void go(T);
}
javap Impl
public abstract class Impl implements Base<java.lang.Integer> {
public void go(int);
public void go(java.lang.Object);
public Impl();
}
So, the problem is exactly that pointed out by #Roland: in order to satisfay the contract requested by the Base interface, the Java compiler needs a public void go(java.lang.Integer) method but the method generated by Kotlin compiler has int as parameter.
If you implement the interface in Java, with something like
class JI implements Base<Integer> {
#Override
public void go(#NotNull Integer field) {
}
}
you can analyze its compiled version with javap obtaining
javap JI
class JI implements Base<java.lang.Integer> {
org.amicofragile.learning.kt.JI();
public void go(java.lang.Integer);
public void go(java.lang.Object);
}
So, if you plan to use Kotlin class Impl as superclass of Java classes, the solution is simply to use <Integer>, not <Int>, as type parameter: Int is a Kotlin class, translated to int by the compiler; Integer is the Java class you usually use in Java code.
Changing your example to
abstract class Impl : Base<Integer> {
override fun go(field: Integer) {}
}
public class JavaImpl extends Impl {
}
the JavaImpl Java class compiles without errors.
I am using a Java library in Scala that generates D-Bus interfaces from class definitions. It works fine with a simple Scala class:
#DBusInterfaceName("me.TestInterface")
trait TestInterface extends DBusInterface {
def changeSomething(thing: String): Unit
}
I need to add a sub-class in order to implement a D-Bus Signal:
#DBusInterfaceName("me.TestInterface")
trait TestInterface extends DBusInterface {
def changeSomething(thing: String): Unit
final class SomethingChanged(thing: String) extends DBusSignal("SomethingChanged")
}
When I do this I get an extrat method $init$ on my D-Bus interface, presumably because this is being added by Scala.
Is it possible to generate a class with a sub-class in Scala that does not have this extra $init$ method?
I can clearly just write this in Java and import it, but I would rather stick to pure Scala.
I found a solution. I realised that Java uses a static class as the inner class. The equivalent in Scala is to put the class in the companion object:
#DBusInterfaceName("me.TestInterface")
trait TestInterface extends DBusInterface {
def changeSomething(thing: String): Unit
}
object TestInterface {
case class SomethingChanged(thing: String) extends DBusSignal("/me/Test")
}
This does work in Scala 2.13, but I am not sure whether this is behaviour that I can rely on or just a feature of the current implementation.
I have an interface defined as follows:
public interface Cache {
}
Then an abstract class implementing the above:
public abstract class AbstractCache implements Cache {
}
Then a concrete class inheriting from above:
public class RealTimeCache extends AbstractCache {
}
Then another class defined as follows:
public class CacheProbe {
public static <T> T probe(T base) {
return (T) Proxy.newProxyInstance(
base.getClass().getClassLoader(),
new Class[]{Cache.class},
new MethodCountInvocationHandler(base) // I am not mentioning this class as it's irrelevant
);
}
}
I have a class as follows which is using all of the above:
public class CacheLoader<T extends Cache> {
public T load() {
T result = getResult(...);
CacheProbe x = new CacheProbe(result);
return x.probe();
}
}
Lastly, the lines causing the issue (located outside above classes):
final CacheLoader<RealTimeCache> cacheLoader = getNewLoader(); //Method of this method is irrelevant and unchangeable
RealTimeCache x = cacheLoader.load(); //This is the line which is causing a runtime issue
Problem is, at run time the following exception is thrown at the last line mentioned above:
java.lang.ClassCastException: com.sun.proxy.$Proxy57 cannot be cast to RealTimeCache
However I don't see how this is possible because the dynamic proxy class generated is based on Cache.
How do I fix this ?
Please note that I can only change CacheProbe class in order to fix this. Cache, AbstractCache, RealTimeCache, CacheLoader and those last two lines are unchangeable.
However I don't see how this is possible because the dynamic proxy class generated is based on Cache.
Yes, the docs for java.lang.reflect.Proxy say
Proxy provides static methods for creating dynamic proxy classes and instances, and it is also the superclass of all dynamic proxy classes created by those methods.
(emphasis added)
Thus, you cannot use Proxy to create (an instance of) a subclass of an arbitrary class of your choice.
How do I fix this ?
You can create an ordinary subclass of RealTimeCache, and return an instance of that. Proxy is meant primarily to serve for interfaces that are not known until runtime, and in that case the only way to interact with them anyway is the interface type. That's not your scenario.
If necessary, you can implement such a subclass in terms of a MethodCountInvocationHandler, just as your proxy class uses, but I'm sure it would be easier to implement whatever tooling that is supposed to provide directly.
We can define Scala companion object for an abstract class:
object CompanionAbstractClass {
def newInstance():CompanionAbstractClass = CACChild("companion abstract class")
}
//sealed trait TestQ{
sealed abstract class CompanionAbstractClass{
val name:String
}
case class CACChild(name:String) extends CompanionAbstractClass
From Scala code, I can use it as:
val q1 = CompanionAbstractClass.newInstance.name
From Java code, it can be used as:
CompanionAbstractClass.newInstance().name();
For better composition in Scala we prefer to use traits:
object CompanionTrait {
def newInstance():CompanionTrait = CTChild("companion trait")
}
sealed trait CompanionTrait {
val name:String
}
case class CTChild(name:String) extends CompanionTrait
From Scala it can be used in a similar way as previously:
CompanionTrait.newInstance().name
But now from Java I cannot invoke it in the same way as:
CompanionTrait.newInstance().name();
I can do it only via:
CompanionTrait$.MODULE$.newInstance().name();
To improve the previous syntax and get rid of this "$" I can create a wrapper in Scala or in Java (which is not good from my optionion):
object CompanionTraitFactory {
def newInstance():CompanionTrait = CompanionTrait.newInstance()
}
Now from Java I can use it also as:
CompanionTraitFactory.newInstance().name();
Can you please explain, why in case a companion object is defined for a trait, I cannot use it from Java in the ways, how it can be used when it is defined either for abstract class (CompanionAbstractClass case), or even as a usual singleton (CompanionTraitFactory case). Guys, I more or less understand the difference between scala traits and abstract classes. I want to understand, why it was implemented this way and is there a chance that it will be supported in Scala in future.
In the working case, you're calling a static forwarder added to your abstract class. You didn't used to get a static forward on your interface, but you do in 2.12.
I am creating a Java library, as a final product in intend to distribute this .jar to developers.
I am "translating" my library from Objective-C where I control which classes header files are available to the developer. In other words I am only exposing to the developer a few classes they can handle.
In my Java library I am using packages and my package has grown quite big. So I decided to separate into different packages my models and controllers. But now the models I wanted to keep private I need to mark as public in order to use from the main package.
My question is does this go against what I was doing in Objective-C ?
For example I have an Event class which is really only used internally and I don't want the user to know about it or think about it. I have another class TimedEvent, which the user can get an instance of an manage.
In my Objective-C, I simply excluded Event class from the library public scope, allowing TimedEvent.
If I am making things more tidy in my library then it seems packages aren't the way. Since now, my main controller is in the main package and all the models are in another package - forced to have a public scope.
Opinions ?
This is possible with Java but there are reasons why (almost) no one does it...
If you put the implementation and the interface into the same package, then you can omit all access modifiers (private, protected, public) from classes and methods to give them "default" or "package" visibility: Only classes in the same package are allowed to see/use them.
Drawback: You'll have to mix API and implementation.
The other approach is to move the implementation into a package *.private.*. No more mixing of API and implementation but malicious users can easily access the implementation - it's just a naming convention. Like a STOP sign: It means something ("be careful") but doesn't actually stop you.
Lastly, you can implement the interface inside of the interface. For example:
public interface IFoo {
String getName();
private static class Foo implements IFoo {
public String getName();
}
public static class FooFactory {
public static IFoo create() { return new Foo(); }
}
}
Ugly, ain't it?
The common approach to controlling exposure of your classes to the world is hiding implementations behind interfaces and factories.
Create an interface for your TimedEvent, and a class for creating instances of TimedEvent interface
Put the interface in the main package, and the factory in a sub-package
Give the factory public visibility
Implement the interface in the sub-package, giving it package visibility
Create an instance of the class implementing the TimedEvent interface in the factory
Here is an example of how you can do it:
package com.my.main;
public interface TimedEvent {
void fire();
}
package com.my.main.events;
import com.my.main;
public class EventFactory {
public TimedEvent makeTimedEvent() { return new TimedEvent (); }
}
// TimedEventImpl has package visibility - it is not public.
class TimedEventImpl implements TimedEvent {
public void fire() {
// Fire a timed event
}
}
The users would access TimedEvent like this:
com.my.main.events.EventFactory f = new com.my.main.events.EventFactory();
com.my.main.TimedEvent evt = f.makeTimedEvent();
evt.fire();