Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33399 > unrolled thread

How to write constructor for an abstarct class?

Back to article view | Back to comp.lang.java.programmer

Contents

  How to write constructor for an abstarct class? Xue Feng <xf.lotus@yahoo.com> - 2015-12-28 20:44 +0800
    Re: How to write constructor for an abstarct class? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-28 08:21 -0500
      Re: How to write constructor for an abstarct class? Jan Burse <janburse@fastmail.fm> - 2015-12-28 19:20 +0100
        Re: How to write constructor for an abstarct class? Jan Burse <janburse@fastmail.fm> - 2015-12-28 19:25 +0100
          Re: How to write constructor for an abstarct class? Jan Burse <janburse@fastmail.fm> - 2015-12-28 19:28 +0100
            Re: How to write constructor for an abstarct class? Lew <lewbloch@gmail.com> - 2015-12-28 10:40 -0800
            Re: How to write constructor for an abstarct class? Eric Douglas <e.d.programmer@gmail.com> - 2015-12-28 10:42 -0800
              Re: How to write constructor for an abstarct class? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-28 14:29 -0500
              Re: How to write constructor for an abstarct class? j4n bur53 <janburse@fastmail.fm> - 2015-12-28 22:26 +0100
                Re: How to write constructor for an abstarct class? Eric Douglas <e.d.programmer@gmail.com> - 2015-12-28 13:37 -0800
                Re: How to write constructor for an abstarct class? j4n bur53 <janburse@fastmail.fm> - 2015-12-28 22:47 +0100
                  Re: How to write constructor for an abstarct class? Eric Douglas <e.d.programmer@gmail.com> - 2015-12-28 13:58 -0800
                    Re: How to write constructor for an abstarct class? j4n bur53 <janburse@fastmail.fm> - 2015-12-28 23:06 +0100
                    Re: How to write constructor for an abstarct class? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-28 17:43 -0500
                      Re: How to write constructor for an abstarct class? Lew <lewbloch@gmail.com> - 2015-12-28 15:14 -0800
                      Re: How to write constructor for an abstarct class? j4n bur53 <janburse@fastmail.fm> - 2015-12-29 15:02 +0100
                    Re: How to write constructor for an abstarct class? Arne Vajhøj <arne@vajhoej.dk> - 2015-12-29 15:37 -0500
                  Re: How to write constructor for an abstarct class? Arne Vajhøj <arne@vajhoej.dk> - 2015-12-29 15:28 -0500
              Re: How to write constructor for an abstarct class? Arne Vajhøj <arne@vajhoej.dk> - 2015-12-29 15:21 -0500
                Re: How to write constructor for an abstarct class? Arne Vajhøj <arne@vajhoej.dk> - 2015-12-29 15:22 -0500
    Re: How to write constructor for an abstarct class? j4n bur53 <janburse@fastmail.fm> - 2015-12-29 16:24 +0100

Page 1 of 2  [1] 2  Next page →

#33399 — How to write constructor for an abstarct class?

I have written a Shape class to test abstract class. My plan is to 
include two fields x and y to represent the coordinate of a shape, and 
add two constructors to initialize the coordinate. In addition, two 
abstract methods, namely getArea() and getPerimeter(), is included to 
calculate the area and perimeter of a shape respectively. The two 
methods will be overrided by subclass of Shape. The code is as follows:

class Shape {
	int x, y;
	
	public Shape(int x, int y) {
		this.x = x;
		this.y = y;
	}
	
	public Shape() {
		this(0, 0);
	}
	
	public abstract double getArea();
	public abstract double getPerimeter();
}

While compiling, the second constructor

	public Shape() {
		this(0, 0);
	}

will cause error. I am aware of that Shape is an abstract class, hence 
can not be instantiated. But, how can I write the constructor 
alternately? Thanks.

[toc] | [next] | [standalone]

#33400

On 12/28/2015 7:44 AM, Xue Feng wrote:
> I have written a Shape class to test abstract class. My plan is to
> include two fields x and y to represent the coordinate of a shape, and
> add two constructors to initialize the coordinate. In addition, two
> abstract methods, namely getArea() and getPerimeter(), is included to
> calculate the area and perimeter of a shape respectively. The two
> methods will be overrided by subclass of Shape. The code is as follows:
>
> class Shape {
>      int x, y;
>
>      public Shape(int x, int y) {
>          this.x = x;
>          this.y = y;
>      }
>
>      public Shape() {
>          this(0, 0);
>      }
>
>      public abstract double getArea();
>      public abstract double getPerimeter();
> }
>
> While compiling, the second constructor
>
>      public Shape() {
>          this(0, 0);
>      }
>
> will cause error. I am aware of that Shape is an abstract class, hence
> can not be instantiated. But, how can I write the constructor
> alternately? Thanks.

     I see no problem with the constructor.  What is "error" you get?

     However, the code you posted has a problem: The class itself must be
declared `abstract' if it has abstract methods, as in

	abstract class Shape { ...

     Are you sure that the code you posted is the same code that gives
you trouble?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33402

Hi,

One of the effects of the abstract modifier for a class
is that you cannot instantiate the class. You can
also place the modifier for a class that has no
abstract member.

Means you wont be able to call either new Shape() or
new Shape(x,y).

Sometimes a similar effect can be created by declaring
the constructur itself private or package local, so
that outside of the package, the class can also not
be instantiated.

Further you are required to place the abstract modifier
for a class that has at least one abstract member. So
basically the class will not compile, since you have
getArea() and getPerimeter() abstract.

Bye


Eric Sosman schrieb:
>      I see no problem with the constructor.  What is "error" you get?
>
>      However, the code you posted has a problem: The class itself must be
> declared `abstract' if it has abstract methods, as in
>
>      abstract class Shape { ...
>
>      Are you sure that the code you posted is the same code that gives
> you trouble?

[toc] | [prev] | [next] | [standalone]

#33403

Jan Burse schrieb:
> Further you are required to place the abstract modifier
> for a class that has at least one abstract member. So
> basically the class will not compile, since you have
> getArea() and getPerimeter() abstract.

I get the following error:
Error: java: Shape is not abstract and does not override abstract method 
getPerimeter() in Shape

The text is tailored towards a class that inherits abstract
members, which should then be overridden. But since
Shape does neither extend an other class or implement
an other interface, this is not the real cause.

The real cause here is just the presence of an abstract
member in the class, and not having the modifier abstract
for the class. The error text is a little bit misleading,
not very well chosen.

Bye

[toc] | [prev] | [next] | [standalone]

#33404

Jan Burse schrieb:
> I get the following error:
> Error: java: Shape is not abstract and does not override abstract method
> getPerimeter() in Shape

The IDE, for example IntelliJ, shows better errors.

Hover over the class:
     Class 'Shape' must either be declared abstract or implement
     abstract method 'getArea()' in Shape.

Hover over the abstract member:
     Abstract method in non-abstract class.

Bye

[toc] | [prev] | [next] | [standalone]

#33405

On Monday, December 28, 2015 at 10:29:01 AM UTC-8, Jan Burse wrote:
> Jan Burse schrieb:
> > I get the following error:
> > Error: java: Shape is not abstract and does not override abstract method
> > getPerimeter() in Shape
> 
> The IDE, for example IntelliJ, shows better errors.
> 
> Hover over the class:
>      Class 'Shape' must either be declared abstract or implement
>      abstract method 'getArea()' in Shape.
> 
> Hover over the abstract member:
>      Abstract method in non-abstract class.

To help get the best feedback from online questions, follow the advice at 
http://sscce.org/
and
http://www.catb.org/esr/faqs/smart-questions.html 

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#33406

On Monday, December 28, 2015 at 1:29:01 PM UTC-5, Jan Burse wrote:
> Jan Burse schrieb:
> > I get the following error:
> > Error: java: Shape is not abstract and does not override abstract method
> > getPerimeter() in Shape
> 
> The IDE, for example IntelliJ, shows better errors.
> 
> Hover over the class:
>      Class 'Shape' must either be declared abstract or implement
>      abstract method 'getArea()' in Shape.
> 
> Hover over the abstract member:
>      Abstract method in non-abstract class.
> 
> Bye

I thought Eric S' answer was clear enough.  The class compiles fine, just needs keyword abstract in front of keyword class.
The real question is why would you want an abstract Shape?  java.awt has a Shape, which is an interface.

[toc] | [prev] | [next] | [standalone]

#33407

On 12/28/2015 1:42 PM, Eric Douglas wrote:
> On Monday, December 28, 2015 at 1:29:01 PM UTC-5, Jan Burse wrote:
>> Jan Burse schrieb:
>>> I get the following error:
>>> Error: java: Shape is not abstract and does not override abstract method
>>> getPerimeter() in Shape
>>
>> The IDE, for example IntelliJ, shows better errors.
>>
>> Hover over the class:
>>       Class 'Shape' must either be declared abstract or implement
>>       abstract method 'getArea()' in Shape.
>>
>> Hover over the abstract member:
>>       Abstract method in non-abstract class.
>>
>> Bye
>
> I thought Eric S' answer was clear enough.  The class compiles fine, just needs keyword abstract in front of keyword class.
> The real question is why would you want an abstract Shape?  java.awt has a Shape, which is an interface.

     The O.P. says it was written "to test abstract class."  I imagine
this means that he or she is new to Java, and is trying things out
to learn how they work (and has, indeed, learned something).  If I'm
right, the Shape class as posted is a learning exercise rather than a
"serious" program.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33415

Eric Douglas schrieb:
> The real question is why would you want an abstract Shape?

The real question do we see the spaghetti monster in the shape.

[toc] | [prev] | [next] | [standalone]

#33416

On Monday, December 28, 2015 at 4:26:35 PM UTC-5, j4n bur53 wrote:
> Eric Douglas schrieb:
> > The real question is why would you want an abstract Shape?
> 
> The real question do we see the spaghetti monster in the shape.

If you have a bunch of abstract Shapes can you create a Picasso?

[toc] | [prev] | [next] | [standalone]

#33417

No, putting trolling aside.
There are a couple of reasons for abstract classes.

1) There is a certain design school which says base
    classes should be always abstract, only non-base
    classes should not be abstract.

    Example from Swing (didn't check): Shape, it
      has subclasses like Ellipse2D, Rectangle2D etc..

    The design rule is often broken, like we might
    have Point2D, and then suddently a NamedPoint2D,
    without a common abstract super class.

2) Prior to default methods in interfaces, an abstract
    class could be used in place of an interface,
    provided extending this abstract class is all that
    is needed.

    Example from Swing (didn't check): AbstractButton
       Could also go with an interface that specifies
       what a button is, could then create hermaphrodites
       like a table which is also a button (well, probably
       doesn't make sense, but anyway)

    The error message of the compiler is both an advantage
    and drawback. The advantage is that the developer is
    reminded what methods need to be implemented.

    The disadvantage is that the design is rendered fragile.
    If I decide to add one more abstract method, all sub-
    classes don't compile anymore.

3) Spaghetti Monster, is it abstract or concrete?
    if it is abstract, no instances would exist, but we
    can see it. Its a knawel of spaghetti with two meat
    balls. So I guess its not abstract.

Bye

j4n bur53 schrieb:
> Eric Douglas schrieb:
>> The real question is why would you want an abstract Shape?
>
> The real question do we see the spaghetti monster in the shape.

[toc] | [prev] | [next] | [standalone]

#33418

On Monday, December 28, 2015 at 4:48:02 PM UTC-5, j4n bur53 wrote:
> No, putting trolling aside.
> There are a couple of reasons for abstract classes.
> 
> 1) There is a certain design school which says base
>     classes should be always abstract, only non-base
>     classes should not be abstract.
> 
>     Example from Swing (didn't check): Shape, it
>       has subclasses like Ellipse2D, Rectangle2D etc..
> 
>     The design rule is often broken, like we might
>     have Point2D, and then suddently a NamedPoint2D,
>     without a common abstract super class.
> 
> 2) Prior to default methods in interfaces, an abstract
>     class could be used in place of an interface,
>     provided extending this abstract class is all that
>     is needed.
> 
>     Example from Swing (didn't check): AbstractButton
>        Could also go with an interface that specifies
>        what a button is, could then create hermaphrodites
>        like a table which is also a button (well, probably
>        doesn't make sense, but anyway)
> 
>     The error message of the compiler is both an advantage
>     and drawback. The advantage is that the developer is
>     reminded what methods need to be implemented.
> 
>     The disadvantage is that the design is rendered fragile.
>     If I decide to add one more abstract method, all sub-
>     classes don't compile anymore.

Previously an abstract class was intended for partial coding, if we have a class which has multiple subclasses which have at least one abstract method which will need different implementations in the subclasses and at least one concrete method which can have common code for all subclasses.  If everything was abstract it probably made more sense to begin with to make it an interface, which is what java.awt did with Shape.  Now that interfaces can contain the methods with the common code, what advantage do you get for making the abstract class, when as you say there is the disadvantage that you can never add another abstract method to it without modifying all subclasses?  The same would be true for the interface but you could always add a second interface to implement, while the subclasses can only extend one class.

[toc] | [prev] | [next] | [standalone]

#33419

Eric Douglas schrieb:
> The same would be true for the interface but you
> could always add a second interface to implement,
> while the subclasses can only extend one class.

I noticed such a coding practice in Android. There are a hell
many interfaces, just adding a little bit more of functionality.
Like every new Android release is just encapsulated in a set
of new interfaces, attached to classes such as View etc..

Of course behind these interfaces are also concrete method
implementations in the various classes that implement the
interfaces, but one first sees is a cascade of interfaces
over the time line of releases.

But I guess for the implementors of the various releases
of Android, the fragility is only delayed, and maybe pushed
from the compile time to the runtime. It depends on how
an object is handled that not yet implements a certain
interface.

In best case, just some functionality is missing, like
for example a certain touch functionality is not working
if the object doesn't implement this and that interface.
In the worst case the application wont work at all.

Bye

[toc] | [prev] | [next] | [standalone]

#33420

On 12/28/2015 4:58 PM, Eric Douglas wrote:
>
> Previously an abstract class was intended for partial coding, if we have a class which has multiple subclasses which have at least one abstract method which will need different implementations in the subclasses and at least one concrete method which can have common code for all subclasses.  If everything was abstract it probably made more sense to begin with to make it an interface, which is what java.awt did with Shape.  Now that interfaces can contain the methods with the common code, what advantage do you get for making the abstract class, when as you say there is the disadvantage that you can never add another abstract method to it without modifying all subclasses?  The same would be true for the interface but you could always add a second interface to implement, while the subclasses can only extend one class.

     Interfaces with default method implementations cannot completely
replace abstract classes, as the latter can do a few things that the
former cannot:

     - An abstract class can declare a final method, but an interface
       cannot declare a final method, default or otherwise.

     - An abstract class can declare a non-final data element, but all
       data elements of an interface are final.

     - An abstract class can declare non-static data elements, but all
       data elements of an interface are static.

     - An abstract class can override a method of Object and provide
       an implementation, but an interface's override must be abstract
       (e.g., `public String toString() {...}' works in an abstract
       class, but `default public String toString() {...}' is impossible
       in an interface).

     - An abstract class can declare private, package-private, and
       protected methods and data elements, but everything in an
       interface must be public.

... and there are probably additional differences I've overlooked.
Some of the differences might be regarded as advantages of interfaces
over classes (e.g., non-final non-private fields are dubious at best),
but for some it seems to me that classes offer more flexibility and
perhaps more power.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33422

On Monday, December 28, 2015 at 2:44:06 PM UTC-8, Eric Sosman wrote:
> ... and there are probably additional differences I've overlooked.
> Some of the differences might be regarded as advantages of interfaces
> over classes (e.g., non-final non-private fields are dubious at best),
> but for some it seems to me that classes offer more flexibility and
> perhaps more power.

They serve different purposes, so it isn't fair to say an abstract class has more or less flexibility or power than an interface. Interfaces define type; abstract classes define partial implementation. Both are needed, for example, in the 'List<E>' -> 'AbstractList<E>' -> [various implementations] taxonomy.

The interface provides the contract for implementers. The abstract class provides a single root for a hierarchy that adheres to the contract, usually with some implementation provided.

Variables should be defined with the interface type, where available and when you don't need a narrower type. This is more flexible than using an abstract class, because you can assign instances of more subtypes to that variable. So interfaces are more flexible than abstract classes. You can provide any needed functionality with an interface-compliant type without being limited to a single implementation, so interfaces are also more powerful than abstract classes. Looked at as an interaction between pure types expressed as interfaces, a program structure is more clear and expansion is easier, again being more powerful and flexible than an abstract-class based implementation. 

That said, there are ways to give abstract classes the advantage for power and flexibility if you focus on different values. So you have to decide in the moment whether the relative strengths and weaknesses of one merit its choice over the other for that situation.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#33428

Eric Sosman schrieb:
>
>      Interfaces with default method implementations cannot completely
> replace abstract classes, as the latter can do a few things that the
> former cannot:

Thanks for the list. Quite accurate and a good remainder.

Bye

[toc] | [prev] | [next] | [standalone]

#33435

On 12/28/2015 4:58 PM, Eric Douglas wrote:
> Previously an abstract class was intended for partial coding, if we
> have a class which has multiple subclasses which have at least one
> abstract method which will need different implementations in the
> subclasses and at least one concrete method which can have common
> code for all subclasses.  If everything was abstract it probably made
> more sense to begin with to make it an interface, which is what
> java.awt did with Shape.  Now that interfaces can contain the methods
> with the common code, what advantage do you get for making the
> abstract class, when as you say there is the disadvantage that you
> can never add another abstract method to it without modifying all
> subclasses?  The same would be true for the interface but you could
> always add a second interface to implement, while the subclasses can
> only extend one class.

1) There are limitations on what you can do with default methods in
    interfaces - actually rather strict limitations. So often it is not
    possible to just use interface and default methods.

2) But even if it is possible then it is not necessarily appropriate
    to do it. Interface default methods exist to make it possible to
    add new methods to existing interfaces and keep existing classes
    implementing those interfaces compiling. As an extra bonus
    the default method may actually do the operation in a working but
    possible non-optimal way. Interface default methods does not exist
    to allow multiple implementation inheritance in Java. Use them
    for what they are intended for and not for more.

Arne

[toc] | [prev] | [next] | [standalone]

#33434

On 12/28/2015 4:47 PM, j4n bur53 wrote:
> There are a couple of reasons for abstract classes.
>
> 1) There is a certain design school which says base
>     classes should be always abstract, only non-base
>     classes should not be abstract.

>     The design rule is often broken,

It is one of those "90% rules" that one should
follow when not thinking about it but be ready to
skip after having thought about it.

The general rule is: only extend classes that has
been written to be extended.

That is obviously the case for abstract classes.

For a concrete class one has to be careful - some
classes has been written to be extended but a lot has not.

Joshua Bloch has some examples in hos Effective Java book
about how bad it can turn out when trying to extend
concrete classes in java.util.

Arne

[toc] | [prev] | [next] | [standalone]

#33432

On 12/28/2015 1:42 PM, Eric Douglas wrote:
> The real question is why would you want an abstract Shape?  java.awt has a Shape, which is an interface.

Shape should obviously not be a concrete class.

So either abstract class or interface.

Which depends on whether you need functionality (beyond what
is appropriate for interface default methods).

java.awt.Shape is an interface.

javafx.scene.shape.Shape is an abstract class.

Arne

[toc] | [prev] | [next] | [standalone]

#33433

On 12/29/2015 3:21 PM, Arne Vajhøj wrote:
> On 12/28/2015 1:42 PM, Eric Douglas wrote:
>> The real question is why would you want an abstract Shape?  java.awt
>> has a Shape, which is an interface.
>
> Shape should obviously not be a concrete class.
>
> So either abstract class or interface.
>
> Which depends on whether you need functionality (beyond what
> is appropriate for interface default methods).
>
> java.awt.Shape is an interface.
>
> javafx.scene.shape.Shape is an abstract class.

If one google:
    abstract class Shape
then it look like an abstract class Shape is part of a ton
of Java OOP introductory lessons.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web