Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #24653
| From | Jim Janney <jjanney@shell.xmission.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: multiple inheritance in Java |
| Date | 2013-07-05 10:04 -0600 |
| Organization | bilaterally symmetric |
| Message-ID | <ydnip0pyow1.fsf@shell.xmission.com> (permalink) |
| References | <multiple-inheritance-20130702024630@ram.dialup.fu-berlin.de> |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> Supersedes: <multiple-inheritance-20130702021857@ram.dialup.fu-berlin.de>
> [edited first »r = 72« to »setR( 72 )« and so on for the next four lines]
>
> Assume you needed a class ColorPoint in Java:
>
> class ColorPoint extends Position, Color;
>
> . Would it be so bad to implement this using public fields
> instead of classical delegation? Public fields:
>
> { public final Color color;
> public final Position position; ... }
>
> , usage:
>
> point.color.setR( 72 );
> point.color.setG( 65 );
> point.color.setB( 41 );
> point.position.setX( 212 );
> point.position.setY( 117 );
>
> . Classical delegation style:
>
> point.setR( 72 );
> point.setB( 65 );
> point.setC( 41 );
> point.setX( 212 );
> point.setY( 117 );
>
> . I only ask, because public fields usually are frowned upon
> in OOP, but what would be the drawback here, especially when
> those fields are final?
In theory, if this is a simple aggregation of data, with no relationship
between the various parts, then you might as well just make them public.
If there is some meaning beyond simple aggregation, in particular if you
can define one or more invariants for the class, then you need to
encapsulate the fields so that the class can maintain those invariants.
On the other hand, and this is probably more important, the Java
community sets great store on always doing things the usual way, and
this has turned into a strength for the language: you can pull a
third-party library library into a project and expect that it will work
with and follow the same conventions as the rest of the code. There are
languages that encourage the programmer to express his or her
individuality (Lisp comes to mind). Java is not one of them.
--
Jim Janney
Back to comp.lang.java.programmer | Previous | Next — Next in thread | Find similar | Unroll thread
Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 10:04 -0600
Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 11:17 -0600
Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 17:10 -0400
Re: multiple inheritance in Java Lew <lewbloch@gmail.com> - 2013-07-05 12:26 -0700
Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 16:22 -0600
Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 21:52 -0400
Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 17:09 -0400
Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 16:29 -0600
Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-05 21:53 -0400
Re: multiple inheritance in Java Jim Janney <jjanney@shell.xmission.com> - 2013-07-05 22:31 -0600
Re: multiple inheritance in Java Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-07-18 22:48 -0300
csiph-web