Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Jim Janney Newsgroups: comp.lang.java.programmer Subject: Re: multiple inheritance in Java Date: Fri, 05 Jul 2013 10:04:14 -0600 Organization: bilaterally symmetric Lines: 51 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: mx05.eternal-september.org; posting-host="c75a2e3068ccf6c98395286f3e40b97d"; logging-data="14564"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX198Vm4vQH/9ZnhlsUTi5oar" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Cancel-Lock: sha1:6VPSNYqRpkpsVdBmxm9pjfZ96xY= sha1:vmKTYLO52E/c1YjJ079YvglMVsE= Xref: csiph.com comp.lang.java.programmer:24653 ram@zedat.fu-berlin.de (Stefan Ram) writes: > Supersedes: > [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