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

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

Object orientation question

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

Contents

  Object orientation question mike <mikaelpetterson@hotmail.com> - 2014-10-27 13:26 -0700
    Re: Object orientation question Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-27 16:51 -0400
      Re: Object orientation question Robert Klemme <shortcutter@googlemail.com> - 2014-10-27 23:51 +0100
        Re: Object orientation question Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-10-28 09:45 +0000
          Re: Object orientation question Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-28 08:29 -0400
            Re: Object orientation question Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-10-28 08:33 -0400
              Re: Object orientation question Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-10-28 16:26 +0000
          Re: Object orientation question Robert Klemme <shortcutter@googlemail.com> - 2014-10-29 08:35 +0100
            Re: Object orientation question Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-10-30 00:32 +0000

#30214 — Object orientation question

Hi,

Let me take an example.

We have an interface called BaseIface and then we have a BaseImpl. Then we have AddtionInterface and AdditionImpl. AdditionInterface is a BaseInterface.



Now if we have the following:

public class AdditionImpl implements AdditionInterface, BaseInterface {


}

or

public interface AdditionInterface extends BaseInterface {

}

And then have

public class AdditionImpl implements AdditionInterface {


}

I think the first option is more clear. Since when I look at the class I can see that it has a AdditionInterface and a BaseInterface. Then I know what the class is.

I would like to hear if this approach is correct or how do you view it?

br,

//mike

[toc] | [next] | [standalone]

#30215

On 10/27/2014 4:26 PM, mike wrote:
> Hi,
>
> Let me take an example.
>
> We have an interface called BaseIface and then we have a BaseImpl. Then we have AddtionInterface and AdditionImpl. AdditionInterface is a BaseInterface.
>
>
>
> Now if we have the following:
>
> public class AdditionImpl implements AdditionInterface, BaseInterface {
>
>
> }
>
> or
>
> public interface AdditionInterface extends BaseInterface {
>
> }
>
> And then have
>
> public class AdditionImpl implements AdditionInterface {
>
>
> }
>
> I think the first option is more clear. Since when I look at the class I can see that it has a AdditionInterface and a BaseInterface. Then I know what the class is.
>
> I would like to hear if this approach is correct or how do you view it?

     Clearly, the generated code is the same: AdditionInterface extends
BaseInterface, therefore any class implementing AdditionInterface also
necessarily implements BaseInterface.  If the class fails to provide a
method specified by BaseInterface, the code won't compile.  So the
question is purely about readability and style.

     Unless there's something rather unusual going on, I'd tend to favor
brevity: Just say `class AdditionImpl implements AdditionInterface' and
let it go at that.  Anyone who's curious about exactly what classes are
extended and which interfaces are implemented can always consult the
Javadoc, where it's all spelled out in gory detail.

     Let me pose a counter-question: What would you think of

	public class AdditionImpl extends JFrame
	    implements AdditionInterface
	{ ... }

versus

	public class AdditionImpl extends JFrame
	    implements AdditionInterface, BaseInterface,
	    ImageObserver, MenuContainer, Serializable,
	    Accessible, RootPaneContainer, WindowConstants
	{ ... }

?  Is readability improved by the extra detail?

-- 
esosman@comcast-dot-net.invalid

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

#30217

On 27.10.2014 21:51, Eric Sosman wrote:

 >      Clearly, the generated code is the same: AdditionInterface extends
 > BaseInterface, therefore any class implementing AdditionInterface also
 > necessarily implements BaseInterface.  If the class fails to provide a
 > method specified by BaseInterface, the code won't compile.  So the
 > question is purely about readability and style.

This is not fully correct: if you check with reflection you will see 
that there is a difference in what Class.getInterfaces() returns.

   public static void main(String[] args) {
     for (final Class<?> cl : Arrays.asList(Single.class, Both.class)) {
       System.out.println("Class name: " + cl.getName());

       for (final Class<?> ifac : cl.getInterfaces()) {
         System.out.println("  " + ifac.getName());
       }
     }
   }

yields in my test case

Class name: iface.inherit.Single
   iface.inherit.DerivedI
Class name: iface.inherit.Both
   iface.inherit.BaseI
   iface.inherit.DerivedI


>      Unless there's something rather unusual going on, I'd tend to favor
> brevity: Just say `class AdditionImpl implements AdditionInterface' and
> let it go at that.  Anyone who's curious about exactly what classes are
> extended and which interfaces are implemented can always consult the
> Javadoc, where it's all spelled out in gory detail.

I'm all with you on the readability through brevity here.  There is one 
more thing: by making AdditionInterface inherit BaseInterface the author 
clearly stated the intend that anything which implements 
AdditionInterface *is a* (or comprises) BaseInterface.  There is no need 
to express that again.  Since that inheritance is not likely to go away 
(such an interface change potentially affects a lot code and should thus 
not be done easily) there is no need to care for the case that the 
"extends" clause goes away leaving @Override dangling in AdditionImpl.

Kind regards

	robert

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

#30221

Robert Klemme <shortcutter@googlemail.com> wrote:
> On 27.10.2014 21:51, Eric Sosman wrote:
> >      Clearly, the generated code is the same: AdditionInterface extends
> > BaseInterface, therefore any class implementing AdditionInterface also
> > necessarily implements BaseInterface.  If the class fails to provide a
> > method specified by BaseInterface, the code won't compile.  So the
> > question is purely about readability and style.
> This is not fully correct: if you check with reflection you will see 
> that there is a difference in what Class.getInterfaces() returns.

You don't even need reflection to notice a difference:

interface A { ... }               |  interface A { ... }
interface B { ... }               |  interface B extends A { ... }
class C implements A,B { ... }    |  class C implements B { ... }
...                               |  ...
   B foo = new C();               |     B foo = new C();
   A bar = foo;  // barf!         |     A bar = foo; // ok

Instead of the second assignment you could have a call to a
method that takes an A and gets passed B-typed reference foo.

So, it is merely a question of whether "every B is also an A", or not.
If it is, then have the one interface extend the other.

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

#30222

On 10/28/2014 5:45 AM, Andreas Leitgeb wrote:
> Robert Klemme <shortcutter@googlemail.com> wrote:
>> On 27.10.2014 21:51, Eric Sosman wrote:
>>>       Clearly, the generated code is the same: AdditionInterface extends
>>> BaseInterface, therefore any class implementing AdditionInterface also
>>> necessarily implements BaseInterface.  If the class fails to provide a
>>> method specified by BaseInterface, the code won't compile.  So the
>>> question is purely about readability and style.
>> This is not fully correct: if you check with reflection you will see
>> that there is a difference in what Class.getInterfaces() returns.
>
> You don't even need reflection to notice a difference:
>
> interface A { ... }               |  interface A { ... }
> interface B { ... }               |  interface B extends A { ... }
> class C implements A,B { ... }    |  class C implements B { ... }
> ...                               |  ...
>     B foo = new C();               |     B foo = new C();
>     A bar = foo;  // barf!         |     A bar = foo; // ok
>
> Instead of the second assignment you could have a call to a
> method that takes an A and gets passed B-typed reference foo.

     My Java compiler (Oracle's 1.8.0_20 on 64-bit Windows 7)
doesn't "barf" as you report.  Has something changed?  Are you
using a different javac?  Here's the code; I've fleshed out
the ellipses and changed one name:

	interface A {
	   void aMethod();
	}

	interface B extends A {
	   void bMethod();
	}

	class C implements A, B {
	   public void aMethod() {
	   }

	   public void bMethod() {
	   }

	   void foo() {
	      B foo = new C();
	      A bar = foo;   // fine
	   }
	}

	class D implements B {
	   public void aMethod() {
	   }

	   public void bMethod() {
	   }

	   void foo() {
	      B foo = new D();
	      A bar = foo;   // fine, no "barf"
	   }
	}

I put all this in a file called "Andreas.java", ran javac on it,
and got four class files and no complaints.

-- 
esosman@comcast-dot-net.invalid

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

#30223

On 10/28/2014 8:29 AM, Eric Sosman wrote:
> On 10/28/2014 5:45 AM, Andreas Leitgeb wrote:
>> Robert Klemme <shortcutter@googlemail.com> wrote:
>>> On 27.10.2014 21:51, Eric Sosman wrote:
>>>>       Clearly, the generated code is the same: AdditionInterface
>>>> extends
>>>> BaseInterface, therefore any class implementing AdditionInterface also
>>>> necessarily implements BaseInterface.  If the class fails to provide a
>>>> method specified by BaseInterface, the code won't compile.  So the
>>>> question is purely about readability and style.
>>> This is not fully correct: if you check with reflection you will see
>>> that there is a difference in what Class.getInterfaces() returns.
>>
>> You don't even need reflection to notice a difference:
>>
>> interface A { ... }               |  interface A { ... }
>> interface B { ... }               |  interface B extends A { ... }
>> class C implements A,B { ... }    |  class C implements B { ... }
>> ...                               |  ...
>>     B foo = new C();               |     B foo = new C();
>>     A bar = foo;  // barf!         |     A bar = foo; // ok
>>
>> Instead of the second assignment you could have a call to a
>> method that takes an A and gets passed B-typed reference foo.
>
>      My Java compiler (Oracle's 1.8.0_20 on 64-bit Windows 7)
> doesn't "barf" as you report.  Has something changed?  Are you
> using a different javac?  Here's the code; I've fleshed out
> the ellipses and changed one name:
>[...]

     Ah, but I mis-read your post! On the left you have A and B as
completely independent interfaces, whereas on the right one is a
sub-interface of the other.  The O.P. wrote (emphasis mine)

	We have an interface called BaseIface and then we have a
	BaseImpl. Then we have AddtionInterface and AdditionImpl.
	*AdditionInterface is a BaseInterface.*

... so your left-hand case is different from the situation he
asked about, and which I was addressing.  Sorry for the confusion.


-- 
esosman@comcast-dot-net.invalid

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

#30226

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> ... The O.P. wrote (emphasis mine)
>
> 	We have an interface called BaseIface and then we have a
> 	BaseImpl. Then we have AddtionInterface and AdditionImpl.
> 	*AdditionInterface is a BaseInterface.*
>

Ok, sorry, *I* misread that, and took "is a BaseInterface" much
too verbally (to the meaning: "an interface that doesn't inherit
anything") rather than recognizing the "is a"-pattern for the name
of the other mentioned interface.

Well, consider this subthread closed. Nothing more to see here. ;-)

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

#30231

On 28.10.2014 10:45, Andreas Leitgeb wrote:
> Robert Klemme <shortcutter@googlemail.com> wrote:
>> On 27.10.2014 21:51, Eric Sosman wrote:
>>>       Clearly, the generated code is the same: AdditionInterface extends
>>> BaseInterface, therefore any class implementing AdditionInterface also
>>> necessarily implements BaseInterface.  If the class fails to provide a
>>> method specified by BaseInterface, the code won't compile.  So the
>>> question is purely about readability and style.
>> This is not fully correct: if you check with reflection you will see
>> that there is a difference in what Class.getInterfaces() returns.
>
> You don't even need reflection to notice a difference:
>
> interface A { ... }               |  interface A { ... }
> interface B { ... }               |  interface B extends A { ... }
> class C implements A,B { ... }    |  class C implements B { ... }

That is not the situation I was referring to.  In both _my_ cases B 
extends A.  The difference is just in the declaration what C implements.

Cheers

	robert

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

#30243

Robert Klemme <shortcutter@googlemail.com> wrote:
>> interface A { ... }               |  interface A { ... }
>> interface B { ... }               |  interface B extends A { ... }
>> class C implements A,B { ... }    |  class C implements B { ... }
>
> That is not the situation I was referring to.  In both _my_ cases B 
> extends A.  The difference is just in the declaration what C implements.

Yep, Eric Sosman has already pointed that out.

[toc] | [prev] | [standalone]

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

csiph-web