-1

I haven't done OOP in a while so I'm a bit rusty. For an example, i have a client with a rental subscription, and it exist 3 type of subscription. How can i choose between abstract class and interface for my "Subscription" class?

Each subscription must have the price, maximum Rental Duration and maximum Rental Count.

From what I remember, I would use interface here but how can I force other classes that implements subscription to specify the value(constant) of these 3 properties?

Lynct
  • 201
  • 1
  • 4
  • 10
  • It all comes down to how you see it growing. Does your API only care that some object is a basic concept of a "subscription" or does it want a finer granularity? In general, I prefer to use interfaces, this allows me to define the basic contract that any implementation is expected to have and allows me to generalise the API to accept the interface in question, meaning I can pass what ever implementation I want without exposing it's implementation to parts of the API that simply don't need it. – MadProgrammer Jan 22 '15 at 21:21
  • Abstract class are then used to provide common "base" implementations that helps reduce code duplication and help improve the time it takes to generate custom implementations...but that's just me. This then supports the concept of ["program to interface not implementation"](http://www.fatagnus.com/program-to-an-interface-not-an-implementation/) – MadProgrammer Jan 22 '15 at 21:22

3 Answers3

1

If you're thinking of defining fields that are common to all implementations, you can't use an interface, because an interface does not contain state. It can just declare methods and constants. State is considered part of an implementation, not type information.

You could, however, define three abstract getter methods - getPrice(), getDuration() and getCount() or something like that, and leave the actual implementation of how those work to the implementing classes. In that case, you could use either an interface or an abstract class.

You'd choose an abstract class if you have some implementation that you want to have which is common to all subclasses. For example, if you have a specific way to perform "rent out", or "send reminder to renter" or other operations. Those methods will be concrete, and only the above three getters will be abstract.

If you don't have any common operations, and you find yourself just having the abstract methods and nothing else, an interface will probably serve you best, especially so because Java is single-inheritance, and using an interface will allow you to extend another class when you are creating your concrete classes.

These are just rules of thumb, though, not rules set in stone.

RealSkeptic
  • 32,074
  • 7
  • 48
  • 75
0

I think an abstract class makes more sense in this case. Use abstract classes when your classes all deal with the same data/methods but may slightly differ in method logic.

Interfaces may be more useful when you have several classes which have large differences but should always be constrained to a set of methods(the interface methods)

james
  • 25,347
  • 17
  • 92
  • 109
  • IMHO I'd favour `interface` first to describe the basic contract of a `Subscription`, this means that you can pass any class that implements the interface to the whole API without the API suddenly having to make decisions about what type of subscription it needs to handle. You could use additional interfaces extending from this to narrow it down if you have to. You would then use abstract classes to fill out the common code, making it easier to develop actual implementations and doesn't tie you down at the start to a limit number of subscriptions...but that's just me – MadProgrammer Jan 22 '15 at 21:17
0

In general you use abstraction in case of inheritance and polymorphism. When you have an object that can have different behavior based on its internal type. Interfaces are used when there is a need for a contract. In general abstraction is best for objects that are closely related, while interfaces are chosen for their functionality.

In your case abstraction makes sense. You can keep the mutual properties in your base class and derive other classes from it. Eliminates some redundant code.

Here is what MS suggested:Here are some recommendations to help you to decide whether to use an interface or an abstract class to provide polymorphism for your components.

*If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.

*If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.

*If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.

*If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.

https://msdn.microsoft.com/en-us/library/scsyfw1d(v=vs.71).aspx

KevinSP
  • 113
  • 10