xmlvm-users

[xmlvm-users] Interface vs abstract classes

[Panayotis K. <pan...@pa...>]

For quite some time there is no decision whether it is preferable to
use abstract classes or interfaces.
With this email I'd propose to use only abstract classes instead of
interfaces and I hope I will convince you :)

First of all I know the disadvantages. By using interfaces we can not
reuse the same objects and thus we usually create inner classes (so we
create one class more).
A second problem has to do with concept: in ObjC there is a use of
protocols and not interfaces.

The problem is, although it looks like we make economy by reusing the
same object, in reality under the current xmlvm implementation, this
is not the case. In order to properly support java interfaces, a
"secret" glue object is used in every case (in which object we have
absolutely no control upon).

When using abstract classes there is 1-1 correspondence. Even if we
use inner classes (which is a common and well known technique), we
have absolute control on this object. In any case, worst case
scenario, we have to define/use one (an only one) object of this
abstract class.

Back to the interface implementation, the minimum number of objects is
one: the glue object. Though, in the case of an inner object (or any
time we don't reuse a given object) , the number of objects rises to
two!

In all cases, interface implementation is more demanding than abstract
classes, and more complex. For this reason I propose to use everywhere
in XMLVM compatibility library abstract classes instead of interfaces
- even for trivial cases.

--
Panayotis

Re: [xmlvm-users] Interface vs abstract classes

[Leo I. <leo...@gm...>]

Java doesn't support multiple inheritance the way C++ does. This means that
If you want your class to extend multiple types, you have to use interfaces.


On Sat, Sep 11, 2010 at 8:17 AM, Panayotis Katsaloulis <
pan...@pa...> wrote:

> For quite some time there is no decision whether it is preferable to
> use abstract classes or interfaces.
> With this email I'd propose to use only abstract classes instead of
> interfaces and I hope I will convince you :)
>
> First of all I know the disadvantages. By using interfaces we can not
> reuse the same objects and thus we usually create inner classes (so we
> create one class more).
> A second problem has to do with concept: in ObjC there is a use of
> protocols and not interfaces.
>
> The problem is, although it looks like we make economy by reusing the
> same object, in reality under the current xmlvm implementation, this
> is not the case. In order to properly support java interfaces, a
> "secret" glue object is used in every case (in which object we have
> absolutely no control upon).
>
> When using abstract classes there is 1-1 correspondence. Even if we
> use inner classes (which is a common and well known technique), we
> have absolute control on this object. In any case, worst case
> scenario, we have to define/use one (an only one) object of this
> abstract class.
>
> Back to the interface implementation, the minimum number of objects is
> one: the glue object. Though, in the case of an inner object (or any
> time we don't reuse a given object) , the number of objects rises to
> two!
>
> In all cases, interface implementation is more demanding than abstract
> classes, and more complex. For this reason I propose to use everywhere
> in XMLVM compatibility library abstract classes instead of interfaces
> - even for trivial cases.
>
> --
> Panayotis
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Interface vs abstract classes

[Panayotis K. <pan...@pa...>]

On 11 Σεπ 2010, at 5:44 μ.μ., Leo Izen wrote:

> Java doesn't support multiple inheritance the way C++ does. This means that If you want your class to extend multiple types, you have to use interfaces. 

I know, I am not talking about general Java programming, but the specific implementation of ObjC library under Java.

Re: [xmlvm-users] Interface vs abstract classes

[Arno P. <ar...@pu...>]

right now we map Objective-C protocols to Java interfaces, except if 
there are optional methods in the protocol. In that case we map it to an 
abstract class.

Using Java interfaces and being able to make use of multiple inheritance 
leads to better designs, IMHO. Of course you can mimic it with abstract 
classes only but the resulting design is not as 'natural'. As far as I 
can tell, the majority of the Cocoa protocols do not have optional 
methods, so making abstract base classes the default seems like a 
drastic decision.

As a compromise, since you have mentioned a 'support' package that 
houses non-standard API, it would be possible to do both: Java 
interfaces and abstract base classes. This way the developer could 
choose which to use. There would be some redundancy, but if would offer 
developers a choice.

Thoughts, anyone?

Arno


On 9/11/10 1:51 PM, Panayotis Katsaloulis wrote:
> On 11 Σεπ 2010, at 5:44 μ.μ., Leo Izen wrote:
>
>> Java doesn't support multiple inheritance the way C++ does. This means that If you want your class to extend multiple types, you have to use interfaces.
>
> I know, I am not talking about general Java programming, but the specific implementation of ObjC library under Java.
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Interface vs abstract classes

[Leo I. <leo...@gm...>]

Do you mean:

public interface FirstOption {
 public void someMethod();
}

public abstract class SecondOption implements FirstOption {
}

Because that would be a good idea. I support it.

On Sun, Sep 12, 2010 at 6:33 AM, Arno Puder <ar...@pu...> wrote:

>
> right now we map Objective-C protocols to Java interfaces, except if
> there are optional methods in the protocol. In that case we map it to an
> abstract class.
>
> Using Java interfaces and being able to make use of multiple inheritance
> leads to better designs, IMHO. Of course you can mimic it with abstract
> classes only but the resulting design is not as 'natural'. As far as I
> can tell, the majority of the Cocoa protocols do not have optional
> methods, so making abstract base classes the default seems like a
> drastic decision.
>
> As a compromise, since you have mentioned a 'support' package that
> houses non-standard API, it would be possible to do both: Java
> interfaces and abstract base classes. This way the developer could
> choose which to use. There would be some redundancy, but if would offer
> developers a choice.
>
> Thoughts, anyone?
>
> Arno
>
>
> On 9/11/10 1:51 PM, Panayotis Katsaloulis wrote:
> > On 11 Σεπ 2010, at 5:44 μ.μ., Leo Izen wrote:
> >
> >> Java doesn't support multiple inheritance the way C++ does. This means
> that If you want your class to extend multiple types, you have to use
> interfaces.
> >
> > I know, I am not talking about general Java programming, but the specific
> implementation of ObjC library under Java.
> >
> ------------------------------------------------------------------------------
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Interface vs abstract classes

[Arno P. <ar...@pu...>]

I think its a clever idea to have SecondOption implement FirstOption!

Arno


On 9/12/10 6:55 AM, Leo Izen wrote:
> Do you mean:
>
> public interface FirstOption {
>   public void someMethod();
> }
>
> public abstract class SecondOption implements FirstOption {
> }
>
> Because that would be a good idea. I support it.
>
> On Sun, Sep 12, 2010 at 6:33 AM, Arno Puder <ar...@pu...
> <mailto:ar...@pu...>> wrote:
>
>
>     right now we map Objective-C protocols to Java interfaces, except if
>     there are optional methods in the protocol. In that case we map it to an
>     abstract class.
>
>     Using Java interfaces and being able to make use of multiple inheritance
>     leads to better designs, IMHO. Of course you can mimic it with abstract
>     classes only but the resulting design is not as 'natural'. As far as I
>     can tell, the majority of the Cocoa protocols do not have optional
>     methods, so making abstract base classes the default seems like a
>     drastic decision.
>
>     As a compromise, since you have mentioned a 'support' package that
>     houses non-standard API, it would be possible to do both: Java
>     interfaces and abstract base classes. This way the developer could
>     choose which to use. There would be some redundancy, but if would offer
>     developers a choice.
>
>     Thoughts, anyone?
>
>     Arno
>
>
>     On 9/11/10 1:51 PM, Panayotis Katsaloulis wrote:
>      > On 11 Σεπ 2010, at 5:44 μ.μ., Leo Izen wrote:
>      >
>      >> Java doesn't support multiple inheritance the way C++ does. This
>     means that If you want your class to extend multiple types, you have
>     to use interfaces.
>      >
>      > I know, I am not talking about general Java programming, but the
>     specific implementation of ObjC library under Java.
>      >
>     ------------------------------------------------------------------------------
>      > Start uncovering the many advantages of virtual appliances
>      > and start using them to simplify application deployment and
>      > accelerate your shift to cloud computing
>      > http://p.sf.net/sfu/novell-sfdev2dev
>      > _______________________________________________
>      > xmlvm-users mailing list
>      > xml...@li...
>     <mailto:xml...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>     ------------------------------------------------------------------------------
>     Start uncovering the many advantages of virtual appliances
>     and start using them to simplify application deployment and
>     accelerate your shift to cloud computing
>     http://p.sf.net/sfu/novell-sfdev2dev
>     _______________________________________________
>     xmlvm-users mailing list
>     xml...@li...
>     <mailto:xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
>
>
>
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Interface vs abstract classes

[hassan k. <has...@gm...>]

Actually Interfaces are used to declare your first high level types in the
project while building skeleton, later you might need to (most of the time,
you should) use abstract classes since you will end up with common
methods\blocks ... you have a better chance to apply good technical designs
such as using template design pattern.


for example ;

IDataStore   (interface)
---- AbstractDataStore   (abstract)
-------- XmlDataStore      (concrete)
-------- TextFileDataStore (concrete)
-------- DBDataSource    (concrete)

The other use of interfaces is to have tagged interfaces, but I guess you do
not use it that much.

your comments are appreciated :) ...

Hassan


2010/9/12 Arno Puder <ar...@pu...>

>
> I think its a clever idea to have SecondOption implement FirstOption!
>
> Arno
>
>
> On 9/12/10 6:55 AM, Leo Izen wrote:
> > Do you mean:
> >
> > public interface FirstOption {
> >   public void someMethod();
> > }
> >
> > public abstract class SecondOption implements FirstOption {
> > }
> >
> > Because that would be a good idea. I support it.
> >
> > On Sun, Sep 12, 2010 at 6:33 AM, Arno Puder <ar...@pu...
> > <mailto:ar...@pu...>> wrote:
> >
> >
> >     right now we map Objective-C protocols to Java interfaces, except if
> >     there are optional methods in the protocol. In that case we map it to
> an
> >     abstract class.
> >
> >     Using Java interfaces and being able to make use of multiple
> inheritance
> >     leads to better designs, IMHO. Of course you can mimic it with
> abstract
> >     classes only but the resulting design is not as 'natural'. As far as
> I
> >     can tell, the majority of the Cocoa protocols do not have optional
> >     methods, so making abstract base classes the default seems like a
> >     drastic decision.
> >
> >     As a compromise, since you have mentioned a 'support' package that
> >     houses non-standard API, it would be possible to do both: Java
> >     interfaces and abstract base classes. This way the developer could
> >     choose which to use. There would be some redundancy, but if would
> offer
> >     developers a choice.
> >
> >     Thoughts, anyone?
> >
> >     Arno
> >
> >
> >     On 9/11/10 1:51 PM, Panayotis Katsaloulis wrote:
> >      > On 11 Σεπ 2010, at 5:44 μ.μ., Leo Izen wrote:
> >      >
> >      >> Java doesn't support multiple inheritance the way C++ does. This
> >     means that If you want your class to extend multiple types, you have
> >     to use interfaces.
> >      >
> >      > I know, I am not talking about general Java programming, but the
> >     specific implementation of ObjC library under Java.
> >      >
> >
> ------------------------------------------------------------------------------
> >      > Start uncovering the many advantages of virtual appliances
> >      > and start using them to simplify application deployment and
> >      > accelerate your shift to cloud computing
> >      > http://p.sf.net/sfu/novell-sfdev2dev
> >      > _______________________________________________
> >      > xmlvm-users mailing list
> >      > xml...@li...
> >     <mailto:xml...@li...>
> >      > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >
> >
> ------------------------------------------------------------------------------
> >     Start uncovering the many advantages of virtual appliances
> >     and start using them to simplify application deployment and
> >     accelerate your shift to cloud computing
> >     http://p.sf.net/sfu/novell-sfdev2dev
> >     _______________________________________________
> >     xmlvm-users mailing list
> >     xml...@li...
> >     <mailto:xml...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing
> > http://p.sf.net/sfu/novell-sfdev2dev
> >
> >
> >
> > _______________________________________________
> > xmlvm-users mailing list
> > xml...@li...
> > https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>

Re: [xmlvm-users] Interface vs abstract classes

[Panayotis K. <pan...@pa...>]

On 13 Σεπ 2010, at 10:06 π.μ., hassan kalaldeh wrote:

> Actually Interfaces are used to declare your first high level types in the project while building skeleton, later you might need to (most of the time, you should) use abstract classes since you will end up with common methods\blocks ... you have a better chance to apply good technical designs such as using template design pattern.
> 
> 
> for example ;
> 
> IDataStore   (interface)
> ---- AbstractDataStore   (abstract)
> -------- XmlDataStore      (concrete)
> -------- TextFileDataStore (concrete)
> -------- DBDataSource    (concrete)   
> 
> The other use of interfaces is to have tagged interfaces, but I guess you do not use it that much.
> 
> your comments are appreciated :) ...
> 
> Hassan
> 


The reason I started this thread is to make XMLVM as "light" as possible.
Especially when event or delegate classes are needed (when a lot of inner classes are defined by  definition).

Having both, an interface and an abstract/concrete class (like what it is now) I think will solve this problem, even if the author of XMLVM support library will have to double his work.