Hello and welcome to our community! Is this your first visit?
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 4 of 4

Thread: Object creation

  1. #1
    New to the CF scene
    Join Date
    Feb 2010
    Thanked 0 Times in 0 Posts

    Object creation


    I have one simple question. Why is it possible the following:

    class Test1{
        public void talk(){
    class Test2 extends Test1{
        public void talk(){
    public class MainTest{
        public static void main(String args) {
            Test1 t = new Test2();
    I don't really get it. We're creating an object called t of type Test1 but it's actually a Test2 object. how come? and what would be a real life purpose of instantiating objects this way?

  2. #2
    New Coder
    Join Date
    Jan 2016
    Thanked 0 Times in 0 Posts
    That's call inheritance
    Here class Test2 extends class Test1 and overrides the method talk(). So, when we run the above code the method that gets called is talk() of class B.

  3. #3
    Regular Coder
    Join Date
    Sep 2014
    Thanked 55 Times in 53 Posts
    It's actually called Polymorphism

    Assume you have a base class of Shapes. Assume also that the class Shapes has a method called draw(). This class has descendants called circle, rectangle, etc. All of those descendants implements the method called draw.

    Now, say you have a class called Canvas. This canvas will have children called Shapes. The canvas does not have to know how the draw method is implemented. All it has to do is to iterate on the children and invoke the function draw(). It will be up to the child to implement the draw function.

    Object oriented implements what is called PIE or in some cases A-PIE.

    See https://beginnersbook.com/2013/03/oo...m-abstraction/

  4. #4
    Senior Coder deathshadow's Avatar
    Join Date
    Feb 2016
    Keene, NH
    Thanked 482 Times in 470 Posts
    See, you're probably butting heads with explanations like the one @josephm provided, that uses all sorts of fancy words (that for someone like me who learned objects in "smalltalk" reeks of throwing new fangled terms at the simplest of concepts) but doesn't actually give you a practical example in plain English.

    In general that was one of the things about Java that always pissed me off -- the concepts are simple, the tutorials, books, and language specification MAKES IT HARD.

    Lemme use the example that was in the Turbo Pascal 5.5 manual. It is far simpler to understand.

    Let's say you're making a game that is going to have four legged animals in it. You make a single parent class that contains all the information common to all four legged animals (properties) as well as basic behaviors (methods) -- like walking, resting, distant sound, angry sound. This gives you all the common code and a single uniform API for accessing an animal.

    You then make a "feline" class that extends "animal" -- it sets the distant sound to a roar and the angry sound to a low growl. This pattern works well for most of the big cats without significant changes.

    But then you want a housecat... changing those sounds to meow and hiss.

    Even with the changes to each and every class along the way, ALL the different objects despite not sharing the same code, share the same API -- the same methods and properties you can look at to find out about the animal, to make it move, or to have it make noise.

    This is why you'll often see base classes -- a "prototype" as it were -- that has all the methods defined, but don't actually do anything... yet. It's partly as a reminder that children of it should implement those methods, and partly as documentation.

    A real world example comes from web browsers -- the DOM. Document Object Model. The core class on the DOM is a 'node'. ALL HTML elements are an extension of type Node, and all plaintext is assigned to an extension of node as well. They share common values like nodeType, firstChild, lastChild, nextSibling, previousSibling, parentNode -- but differ in how information inside them is tracked such element nodes having id, classname, name, etc, which do not exist on text nodes.

    That common ancestry allows you to "walk the DOM tree" consistently even though each of the child nodes are different classes.

    So bottom line the reason is twofold. First to allow for prototyping of future code to a common API, second is to reduce the overall code by sharing like properties and methods when possible.
    “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.” – C.A.R. Hoare, The 1980 ACM Turing Award Lecture


Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts