Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Creating objects from abstract classes?  RSS feed

 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've seen a number of tutorials that state you can not create and object from an abstract class. So what is happening here? Am I not creating and object from an abstract class?

 
Campbell Ritchie
Marshal
Posts: 55751
163
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch

Are you creating an object of an abstract class? Well, yes and no. Yes, that is an object and it is an instance of the abstract class just an Integer is an instance of Number.
No, that is not an instance directly created from the abstract class, but indirectly via an anonymous class. Anonymous classes are a special type of nested class and you can read about them in the Java™ Tutorials.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the welcome. I'm not nitpicking, just trying to see if I get it. So what is happening is I am creating another class from the abstract class but just going through the formality of naming it? I will get an error if I don't override the methods of the abstract class. So I guess its like creating a new class in the statement, but never naming it (?). Sort of like AbstractClass test = new anonymousClass(); or like you see in many tutorials, Animal fido = new Dog() except all the overrides in my anonymous class are included in the statement (?).
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you look at what is produced by the compiler when you compile that code you will see there is a .class file named something like ATestClass$1.class.

If you then print out the type of test1 you will see that it is an instance of this class.



So anonymous classes are really no different to named classes as far as Java is concerned, and don't violate the rule that you can't instantiate an abstract class directly.
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:Thanks for the welcome. I'm not nitpicking, just trying to see if I get it. So what is happening is I am creating another class from the abstract class but just going through the formality of naming it? I will get an error if I don't override the methods of the abstract class. So I guess its like creating a new class in the statement, but never naming it (?). Sort of like AbstractClass test = new anonymousClass(); or like you see in many tutorials, Animal fido = new Dog() except all the overrides in my anonymous class are included in the statement (?).


Yes this is basically what is happening ;-)
 
Liutauras Vilda
Marshal
Posts: 4650
318
BSD
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:I've seen a number of tutorials that state you can not create and object from an abstract class.
And it is true, an abstract class itself cannot be instantiated. What can be instantiated is a subclass of abstract class, but only if fulfills one requirement, it has to override each method which is declared as an abstract method in your abstract base class, as these are being inherited by subclass, and actually that is why abstract class cannot have private, static or final methods because you couldn't override them by subclass. I know because I have and read Java in a Nutshell book
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Liutauras Vilda wrote:...and actually that is why abstract class cannot have private, static or final methods because you couldn't override them by subclass.


An abstract class can have private, static and final methods. Not all methods in an abstract class need to be overridden in its subclasses, only the abstract methods.

An abstract class doesn't need to have any abstract methods though, so its possible for all methods in an abstract class to be private, final, or static.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well that clears it up for me. I'm coming over from Processing, and someone posted a template of an OOP way of handling the drawing modes. And that's the way I handle all of the drawing modes in that program. They're all made from the abstract class "Mode" , but here are no named classes for "Draw" "Clone" "Blur"
etc. They all have one function- er method , which is declared in the abstract class and its completely different for every Mode. So it was throwing when these tutorials were stating you can't create an object from an abstract class. The compiler is creating yet another class. That clears that up, thank you.
 
Liutauras Vilda
Marshal
Posts: 4650
318
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're of course correct Mike, this is what I meant and yes, missed word abstract. The methods, which are declared as abstract, cannot be private, static or final. Without abstract keyword it is perfectly fine.
 
Liutauras Vilda
Marshal
Posts: 4650
318
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To visualise observation:
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shameless plug - https://gist.github.com/shawnlau/f465a6c17f5fa3fb3fa2

Most of this program is written in a procedural manner. I'm going through the design tutorials to make it OOP. The thing is though, when dealing with graphics its all about performance and I still don't know how OOP stacks up performance wise. I know its easier to maintain, but how is its performance?
 
Campbell Ritchie
Marshal
Posts: 55751
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote: . . . don't know how OOP stacks up performance wise. . . .
The performance is good. There is usually no significant difference between OO performance and procedural performance.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The thing to realise about performance is that you will struggle to reason about it in most cases simply by reading code and trying to guess whether an OO paradigm will be quicker than a procedural one. The compiler, the JVM and even the CPU can apply optimisations, so you really need to run the code and find out.

Even then you have to be careful, profiling software can often lie to you, or at least distort the truth.

 
Paul Clapham
Sheriff
Posts: 22504
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:I still don't know how OOP stacks up performance wise. I know its easier to maintain, but how is its performance?


The question is unfortunately meaningless. You can't realistically talk about performance at such a high level; even talking about the performance of a specific algorithm is often difficult to do given the externalities involved.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well you can certainly talk about performance as a priority.
 
Campbell Ritchie
Marshal
Posts: 55751
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Performance should come after correctness of code, and maintainability, however.
 
Paul Clapham
Sheriff
Posts: 22504
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:Well you can certainly talk about performance as a priority.


Of course. But then you should continue by asking meaningful questions about it.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well sometimes. If something is too slow to implement, and that can very well happen in graphics, its not worth anything. You can't be calling array.sort to sort a median array. It would be too slow for real time use. I'm all for easy to maintain code, but some things in graphics just have to made to run fast, and maintenance is of a lower priority. Anyway, I received two good answers, so I don't think the question was "meaningless." I'm a procedural programmer. Its a tough change to OOP. I like it, I love the idea of encapsulation. I like the idea of polymorphism ( we used pointers to functions in C - instead of draw.currentmode() it was simply *draw()). But what I do most is graphics so speed is the highest priority in a lot of real time actions. GUI and stuff like that, speed is no issue.
 
Campbell Ritchie
Marshal
Posts: 55751
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no need to be rude, thank you very much.
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Shawn Lau wrote: . . . don't know how OOP stacks up performance wise. . . .
The performance is good. There is usually no significant difference between OO performance and procedural performance.


You would actually need to benchmark to have a say. Sorry, I am busier these days ;-)
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike. J. Thompson wrote:

Even then you have to be careful, profiling software can often lie to you, or at least distort the truth.



Very true indeed, I have rewritten benchmark tests several times because I suspected that and indeed, my suspicions were founded.
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:Well sometimes. If something is too slow to implement, and that can very well happen in graphics, its not worth anything. You can't be calling array.sort to sort a median array. It would be too slow for real time use. I'm all for easy to maintain code, but some things in graphics just have to made to run fast, and maintenance is of a lower priority. Anyway, I received two good answers, so I don't think the question was "meaningless." I'm a procedural programmer. Its a tough change to OOP. I like it, I love the idea of encapsulation. I like the idea of polymorphism ( we used pointers to functions in C - instead of draw.currentmode() it was simply *draw()). But what I do most is graphics so speed is the highest priority in a lot of real time actions. GUI and stuff like that, speed is no issue.


I understand very well. The trick is to find out where you need to optimize first. The real truth is that if you write code with a knowledge of performance impacting style in the first place, your code will probably not need to be optimized ever. But again, sometimes I give up on performance in complex cases when the code is ran less often.

These days, too many devs eat the "cohesive code" pill without any knowledge nor concerns on how the squirrel wheel that the hardware constitute works.

The most common case I have encountered is the big java party where over-creation of Objects bring an application to its knees. Those who write such code will say that garbage collector impact on an application is negligible and that it is all abstracted ;-)

 
Shubhendu Pramanik.
Greenhorn
Posts: 14
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
See if below link could help you on this...

http://www.programmerinterview.com/index.php/java-questions/interface-vs-abstract-class/
 
Campbell Ritchie
Marshal
Posts: 55751
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is performance impacting style? Does over‑creation of objects still bring apps to their knees?
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:What is performance impacting style? Does over‑creation of objects still bring apps to their knees?


Here is the simplest example. Yet, I see plenty of code doing exactly the same in more complex ways.

In this case, the performance penalty factor is 21848, meaning 1 takes 21848 more time to run (or ~6 hours versus 1 second).

1 creates loops objects while 2 creates 1 object. 1 has gc running crazy while 2 has no gc.

You can easily make your applications run 100 or 1000 times faster if you keep that simple principle in mind instead of pretending everything is abstracted and that the jvm can always be optimized and should take care of everything by itself. I even saw a post here against returning nulls suggesting to create a dummy Object and return it instead ;-))

output:
21848

>
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is a good idea not to return null and it is a good idea to use the Null Object pattern instead, but that doesn't mean it should be applied religiously. There are always exceptions.
 
Stephan van Hulst
Saloon Keeper
Posts: 7817
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A.J., the performance impact has nothing to do with Object creation, but with the time-complexity of the algorithm. The code using StringBuilder runs in O(n), while the code using String runs in triangular time, or O(n^2).
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:A.J., the performance impact has nothing to do with Object creation...


See this post then:
http://www.coderanch.com/t/656528/java/java/Alternatives-null-checks-statements#3043741
 
Stephan van Hulst
Saloon Keeper
Posts: 7817
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What happened when you reversed the two loops? Did you take JIT compilation into account? VM warmup times? Benchmarking Java is notoriously difficult.
 
A.J. Côté
Ranch Hand
Posts: 417
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:What happened when you reversed the two loops? Did you take JIT compilation into account? VM warmup times? Benchmarking Java is notoriously difficult.


See here:
http://www.coderanch.com/t/656528/java/java/Alternatives-null-checks-statements#3043757
 
Campbell Ritchie
Marshal
Posts: 55751
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A.J. Côté wrote:. . . Here is the simplest example. . . .
Agree. Repeated String catenation is notorious for poor performance.
 
Stephan van Hulst
Saloon Keeper
Posts: 7817
142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aye, because it runs in O(n^2). If you performed the same algorithm while reusing the original character array, it would still be slow, even if you didn't create new objects.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!