Scribd
Upload
6 views

Core-Java Concepts

An abstract class allows you to provide default functionality for subclasses. If the base class will be changing often, it is best to make it abstract so that changes are inherited by subclasses. An interface should be used if you need to change the design later, as changing an interface can break client code that implements it. Abstract classes are good for application frameworks as they can provide default services while requiring subclasses to implement application-specific functionality.

Uploaded by

Dushyant Sahu
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
6 views

Core-Java Concepts

An abstract class allows you to provide default functionality for subclasses. If the base class will be changing often, it is best to make it abstract so that changes are inherited by subclasses. An interface should be used if you need to change the design later, as changing an interface can break client code that implements it. Abstract classes are good for application frameworks as they can provide default services while requiring subclasses to implement application-specific functionality.

Uploaded by

Dushyant Sahu
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

Abstract class: Abstract classes allow you to provide default functionality for the subclasses.

If you
plan on updating this base class throughout the life of your program, it is best to allow that base class to
be an abstract class. Why? Because you can make a change to it and all of the inheriting classes will now
have this new functionality. If the base class will be changing often and an interface was used instead of
an abstract class, we are going to run into problems. Once an interface is changed, any class that
implements that will be broken. Now if it’s just you working on the project, that’s no big deal. However,
once your interface is published to the client, that interface needs to be locked down. At that point, you
will be breaking the client’s code.

Speaking from personal experiences, frameworks are a good place to show when and where to use both
an abstract class and an interface. Another general rule is if you are creating something that provides
common functionality to unrelated classes, use an interface. If you are creating something for objects
that are closely related in a hierarchy, use an abstract class. An example of this would be something
like a business rules engine. This engine would take in multiple Business Rules as classes perhaps? Each
one of these classes will have an analyze function on it.

public interface BusinessRule {


Boolean analyze (Object o);
}

This can be used ANYWHERE. It can be used to verify the state of your application. Verify data is correct.
Verify that the user is logged in. Each one of these classes just needs to implement the analyze function,
which will be different for each rule.

Interfaces means you are just defining a list of functions and that abstract classes has the option of
providing default functionality.

Interface vs. abstract class

If you need to change your design, make it an interface. However, you may have abstract classes that
provide some default behavior. Abstract classes are excellent candidates inside of application
frameworks.

Abstract classes let you define some behaviors; they force your subclasses to provide others. For
example, if you have an application framework, an abstract class may provide default services such as
event and message handling. Those services allow your application to plug in to your application
framework. However, there is some application-specific functionality that only your application can
perform.

Many developers forget that a class that defines an abstract method can call that method as well.
Abstract classes are an excellent way to create planned inheritance hierarchies. They're also a good
choice for no leaf classes in class hierarchies.
equals() and hashcode() method:

1. Duplicate objects are added in Hashmap as a key (Because we have not overided the hashcode
and equals method)
2. We are not able to get back object from map (Because hashcode is not implemented)
3. Duplicate Keys are not added instead there values are replaced.
4. Now the object is retrieved from the Map.

Override only hashCode()

Imagine you have this

MyClass first = new MyClass ("a","first");


MyClass second = new MyClass ("a","second");

If you only override hashCode then when you call myMap.put (first,someValue) it takes first, calculates
its hashCode and stores it in a given bucket. Then when you call myMap.put (second,someOtherValue) it
should replace first with second as per the Map Documentation because they are equal (according to
our definition).

But the problem is that equals was not redefined, so when the map hashes second and iterates through
the bucket looking if there is an object k such that second.equals (k) is true it won't find any as
second.equals (first) will be false.

Override only equals()

If only equals is overriden, then when you call myMap.put (first,someValue) first will hash to some
bucket and when you call myMap.put (second,someOtherValue) it will hash to some other bucket. So,
although they are equal, as they don't hash to the same bucket (different hashCode) the map can't
realize it and both of them stay in the map.

You might also like