How do I know when to implement an interface or an abstract class? about 2122-s2

[undeser]

Hi there, the main difference between Interface and Abstract classes are that Interface simply specifies the methods to be implemented, with no data, while Abstract class can have some methods defined.

My personal approach is to see if a certain operation functions the same way.

If each subclass has a very different functionality for the same operation, I'll use Interface. For example, Performer class has action perform() which acts very differently based on the subclass, like sing, dance). Whereas for Circle class where getArea() behaves the same regardless of filledCircle or emptyCircle, I'll use the Abstract class.

[teresasee]

Personally for me I use interface more often if it is just to specify that the child classes must implement a certain method. If the method is the same across all the child classes, then I will change the code to use class/abstract class.
Sometimes reading through the question can help as well. For example if a child has to inherit from two parents, then you know that at least one of the parents has to be an interface, and you can go on deciding whether the other is an interface or a class.

[gracelimshiern]

I usually use interfaces when the child classes have the same method but different implementation, but abstract classes when there are a mix of common methods with the same implementation and common methods with different implementations

[ngruiyanrena]

Interface only specifies methods to be implemented with no data. On the other hand, abstract classes contains methods where methods can be defined.

[wk1267]

not too sure if I am wrong (pls let me know !!), but this is how I understand things, using the case of NS:
All enlisted SG guys are NSFs. NSF is an abstract class. In it are methods like uprank(), takeMC(), owadio()
I am in BMT and am a recruit. Recruit is a (concrete) class that extends NSF.
I finished BMT and am now a private. Private can be another class that extends NSF. In this case, recruit.uprank() returns new Private(...).
I am forced to do guard duty. Guard is an interface, that me as a Private will implement. Guard is not an abstract class because people of different ranks still need to do guard duty (except, it seems, some people above a certain rank). It is an interface that sets a contract to the NSF to need to do guard duty, but can be implemented by Privates, LCPs, CPLs etc. (or unless, of course you decide to NSF.takeMC())

[Natalienovaela]

Not too sure as well ._. but I believe it is a matter of preference here. We can use interface if we don't want to define all the methods inside, but we can use abstract class if we still have some methods that we want to implement. In short, interface lets you define, not implement, while abstract class gives you 2 choices, either to implement or override in its subclasses.

[shotnothing]

Apart from what the others have already said, also note that a class can implement multiple interfaces, but can only extend one abstract class. The reason to my understanding is that Java wants to avoid the diamond inheritance problem that plagues multiple inheritance in other languages like C++.

In the diagram above, it is unclear which processDoc() should ComboPrinter use.

Java disallows multiple inheritance in abstract classes but since interfaces do not actually implement anything, they are fine.

[meganparrot889]

I personally chose to use an abstract class for Service class since the different services (JustRide, TakeACab etc) share the same method of computing the fare, whereas an interface is more for if you only want to specify the method to be implemented but not actually implementing it. In this case, I implemented the compute fare method so I felt that an abstract class is better.

[summerthia02]

I would say that there is no right or wrong answer and whether you choose abstract class or interface is entirely up to you. I chose interface for the Services as I felt that the computeFare method is different for each Service and thus it would simply be more convenient to design an interface with the computeFare method. An Abstract Class would be possible as well (but my TA mentioned that it will be more complicated in this case)

However, the main difference between these two are that
abstract class is specifying more of what an object is and you mainly use it when objects are closely related.
take for example, the practice assessment 1, we can see how it is recommended to implement an abstract class "Quiz", that has MCQ,FillInBlank,MRQ as its subclasses. This is because they have a common attribute, that is String question. They have also common methods that you can don't specify (thus, I would say abstract class is extremely flexible).
You can define the methods that MCQ etc uses such as mark( ), answer( ) , without actually specifying them.

interface defines the methods and capabilities of the subsequent subclasses (what the objects can do)- it establishes a contract that all of its subclass must subsequently follow to be a part of that interface.
Interface is also more suited for providing a common functions to objects that are not so highly related to each other.

TLDR: Based on preference, however, interfaces are more general while abstract classes are more specific.
If closely related (esp if have similar attributes) -> can use abstract classes
Otherwise, can use interface as well
hope this helps :)

[loqir]

i think abstract classes are used when the abstract class eg. Driver has attributes and a constructor, and its sub classes are related to one another (different types of drivers) but interfaces are used when there is something intangible eg. Service that has no attributes but only methods to be implemented by more unrelated child classes. Another point is that a child can only extend one super class so if it is already extending a class, the next thing it should inherit from is an interface

[mk2905]

When using abstract classes we are defining characteristics of an object type; specifying what an object is. On the other hand, interfaces are used to define capabilities that we promise to provide, establishing a contract about what the object can do. I would go about implementing it as an interface first if I'm really unsure, and later on, if there are concrete methods that I want to implement then ill consider whether to use an abstract class or a concrete class