Is this a valid abstract class?
I know that abstract classes cannot be instantiated, so I'm suspicious of the instance variable language and constructor Programmer. It also implements a writeCode method that is not declared as default. If I recall correctly, the only methods that can be implemented in an abstract class are those with default implementations.
public abstract class Programmer {
private String language;
public Programmer (String language) {
this.language = language;
}
public void writeCode() {
System.out.println("Written in " + language);
}
}
If it is a valid abstract class, can someone explain why it contains a constructor?
Also, more broadly speaking, can abstract classes have instance variables? If so, why? Doesn't that seem counter to the idea that abstract classes cannot be instantiated?
Finally, I would love it if someone addresses the writeCode method. Why is it implemented, without a default modifier?
Thanks!
Yes, this is a valid abstract class.
Abstract classes can have constructors, instance variables and concrete methods.
The main difference with regular classes is that they can also declare abstract methods, delegating implementation to the non-abstract child classes (this is not the case here, you have no abstract methods).
Another difference is that they cannot be initialized directly, even if they do provide an accessible constructor.
The constructor(s) of an abstract class are typically used to initialize values internally, and to invoke from child classes or anonymously.
See documentation here.
Example
Given...
public abstract class Programmer {
private String language;
public Programmer(String language) {
this.language = language;
}
public void writeCode() {
System.out.println("Written in " + language);
}
}
... and...
public class JavaProgrammer extends Programmer {
public JavaProgrammer() {
super("Java");
}
}
Concrete child class
new JavaProgrammer().writeCode(); // prints "Java"
Anonymous class (note the empty class body {})
new Programmer("JavaScript"){}.writeCode(); // prints "JavaScript"
As you say, abstract classes cannot be instantiated. However, when a subclass of any abstract class is created, the first sentence in its constructor is a call to super(), which is nothing but a representation of the constructor of its parent class, the abstract class.
An abstract class can have instance variables and methods. It is even possible to have an abstract class without any abstract method. However, an abstract method can only be declared in an abstract class.
You are mixing abstract classes and interfaces concepts. An interface cannot have instance variables, and any implemented method must be prefixed with the static or default modifier.
This is correct example of abstract class. Answering your questions:
default keyword is used (as of java 8) in interfaces, where you can implement default method implementation, abstract class can have a method implementation just as any normal java class
having constructor in abstract class imposes having a constructor in extending class so that the underlying abstract class can be properly constructed (e.g. fields instantiated etc)
abstract class cannot be instantiated but as any other class can have private fields and internally make use of them, should they be protected then extending classes will also be able to directly access them.
It seems to me you're confusing abstract class with interface.
The abstract class contains a constructor because when the instantiated class based on the abstract class is created it will call super() to execute the code from the abstract class.
The instance variable is a similar thing. The class that is developed from the abstract class would then have access to the language and be able to work with it.
In terms of the default, that would be best practice but there is no absolute requirement for it to be there.
Abstract classes are partial implementations. Sometimes, as in the case above, the only thing that prevents the class from being instantiated is the abstract modifier itself!
If an abstract class has constructors then it means that subclasses must invoke one of the constructors (by calling super(...) in their constructor.
More broadly it seems that you're confusing Interfaces and Abstract Classes. Interfaces are a contract, they specify how a class should behave but provide no implementation whatsoever. Abstract Classes are a specific partial implementation of some code.
Interfaces are used (broadly) when you require someone else to provide behaviour but you don't care how it works. Abstract Classes are used when you want to assist people in providing behaviour, but you still require them to provide some details.
Since these definitions overlap, it's not unusual to see both Abstract Classes and Interfaces provided, e.g. the various Adapters in java.swing.*.
Related
In context of Java, could a class replace the need of extending an abstract class by extending another non-abstract class and implementing an interface together, both of which combined have all the methods(abstract and implemented), of an abstract class?
In context of Java, could a class replace the need of extending an
abstract class by extending another non-abstract class and
implementing an interface together, both of which combined have all
the methods(abstract and implemented), of an abstract class?
Can it? Yes
Should it? No
An abstract class can be replaced by a concrete one, but you will be altering your system.
Do remember: an abstract class can not be instantiated, nor should it be, since it's not 'concrete enough' to make sense for your business. (If it does, it shouldn't have been an abstract class to begin with)
If you make it concrete, you risk that developers will use instances of the (what-should-be) abstract class.
If you change it the way you propose:
public void doSomething(MyAbstractClass instance){
// here we know there is an implementation provided by a subclass
}
would become
public void doSomething(MyShouldBeAbstractClass instance){
// here they can pass instances of the base class, which might have unsupported methods
}
For instance:
public String getConcreteInformation(){
throw new UnsupportedOperationException("Should be called on a child class");
}
and could lead to a lot of nasty bugs
I want to declare a couple of abstract methods (so the implementation is required in the classes that inherit from this one) to fit my situation, which is:
I am making a puzzles solver program. So far I have 3 packages:
games.puzzles
games.puzzles.rivercrossing
games.puzzles.rivercrossing.wolfgoatcabbage
I don't want to get too specific but in the games.puzzles.rivercrossing package I have two classes that represent a bank and a state: GenericBank and GenericState.
Now, they define some behavior, but there are some methods that the classes that inherit from these must have, like move() to move one element from one bank to the other or isPermitted() and isFinal() to check the states.
For example, in the last package I have the WolfGoatCabbageGame class and it must have its own Bank and State classes which will inherit from the generic ones. These particular Bank and State classes must implement the methods I mentioned above, for example in the Wolf, Goat and Cabbage game, to check if the goat and the wolf are not in the same bank, etc.
So initially I declared the generic classes as abstract, and these methods to be implemented abstract as well:
public abstract class GenericBank {
// more members ...
public abstract boolean move(Element element, GenericBank dst);
// more members...
}
public abstract class GenericState {
// more members...
public abstract boolean isPermitted(GenericBank bank);
public abstract boolean isFinal(GenericBank bank);
// more members...
}
And this looked like it'd work until I found out I had to instantiate GenericBank and GenericState objects, which of course can't be done if these classes are abstract.
So I had to remove the abstract qualifier from the classes.
So... what can I do? How can I declare abstract methods (or achieve the same behavior) in a non-abstract class?
How to declare abstract method in non-abstract class?
Answer: You can't. It's kind of the definition of abstract. It's the same reason you can't instantiate an object as an abstract class.
Either:
A) You need to use Interfaces
B) Leave the methods empty in the parent class:
//technically this needs to return a value, but it doesn't need to *do* anything
public boolean isPermitted(GenericBank bank){ return false; }
C) Refactor your code so that you aren't instantiating abstract objects. I cannot advise how to do this as you haven't provided any code regarding this.
You could replace the abstract methods with empty methods that do nothing and return the default value of their respective return type (and, if necessary, make it part of the generic classes contract, that subclasses must override these methods).
Alternatively, you could keep your abstract Generic*-classes and add Null*-classes with abovementioned empty implementations, following the Null object pattern.
You cannot declare abstract methods in a non-abstract class, final dot.
That would simply defile the concept of abstract methods.
What you can do is have your class hierarchy implement interfaces dictating the required methods to implement.
If you found your formerly abstract classes were actually better designed as concrete classes, do convert them to concrete classes and implement the methods, even with a default, general implementation.
You can then fine-tune the overrides in your child classes.
Remove the abstract qualifier and add a empty body, or throwing some runtime exception.
Or instantiate these generic classes as anonymous sub classes
You cannot, the very definition of an abstract class is that it has abstract methods.
What you can do, is define default behaviour, that can be overruled by subclasses.
However, I would carefully consider your class hierarchy before doing this. The fact that you need to instantiate some classes before their actual implementations are known, suggests that your design may need re-thinking.
If you're going to re-design, you will want to look at the time of instantiation - and underlying that, the reasons for instantiating.
Right now, you want to use some of the common behaviour of a class, before the actual instance of that class is known.
It goes a bit beyond the scope of answering the question, but: consider explaining the design of the code to a friend. Or to a rubber duck. This may help you to find a fresh approach.
You can use Virtual instead!
internal class ClassA
{
public void Print()
{
Console.WriteLine("A");
PrintVirtual();
Console.WriteLine("--------------------------------------------------");
}
protected virtual void PrintVirtual()
{
Console.WriteLine("Virtual");
}
}
internal class ClassB : ClassA
{
protected override void PrintVirtual()
{
Console.WriteLine("B");
}
}
internal class ClassC : ClassA
{
protected override void PrintVirtual()
{
Console.WriteLine("C");
base.PrintVirtual();
}
}
and you can run the test
new ClassA().Print();
new ClassB().Print();
new ClassC().Print();
I'm really confused, and I've read a TON of questions on this topic and I have not been able to pinpoint anything specifically that an interface can do that an abstract class cannot do.
A class can implement multiple interfaces, but it cannot implement multiple abstract classes.
Interface itself cannot do anything. It just defines kind of contract between the class(es) that provide some functionality and the caller.
Abstract class is the class that defined as abstract. If class has at least one abstract method (i.e. method without implementation) it must be defined as abstract. But abstract class can contain implementations as well.
Interface cannot contain implementation. Only abstract methods and constants (static final fields).
Class can implement several interfaces and extend only one class (including abstract class).
I hope this helps.
Abstract class can also contain function implementation rather than just defining the functions that have to be implemented by inheriting classes
Abstract classes are partially implemented classes, that will be extended by concrete classes(non-abstract), to be implemented.
Example:
This example does not mean that the sub classes must implement those methods(as it happens when implementing an interface). You can declare a subclass abstract, and the implementation will be done later by annother sub-sub-class. (For example: Boat can have subclasses "SpeedBoat" and FisshingBoat, and the may implement honk() in different ways)
The interface are the eyes of class to the outside world. What classes can do is declared in the interface, but implemented in the class.
A class can implement many interfaces, but can extend only one class.
See this little example of interfaces:
As you can see when we use interfaces we can have a lot of flexibility. Some Enemies can do things that some Heroes can do too(DarkKnight can throw arrows).
I hope you now feel the difference between the abstract classes and interfaces.
Remember this about interfaces and Abstract classes:
Interfaces dont have variables, just non implemented methods(abstract methods implicitly)
Classes that implement interfaces must have all the methods of the interface in its body
One class can extend only one class but implement more than one interface
If a class has an abstract method, it must bee declared as abstract.
Abstract classes can implement interfaces
Interfaces can extend other interfaces(more than one)
I dont know if i forget something, i hope this information helps.
An abstract class can everything that a Interface can do. However inverse of this is not correct.
Abstract class can contain abstract methods, abstract property as well as other members (just like normal class).
Interface can only contain abstract methods, properties but we don’t need to put abstract and public keyword. All the methods and properties defined in Interface are by default public and abstract.
We can see abstract class contains private members also we can put some methods with implementation also. But in case of interface only methods and properties allowed
Interface and abstract class almost both are same the major difference is using interface we are not able to define the body of the method but using abstract class we can define the body of the method inside the abstract class or while implementing it.
e.g
Interface abc()
{
string xyz();
}
abstract abc()
{
string xyz()
{
// define body
}
}
or
abstract abc()
{
string xyz();
}
An abstract class is a class - it defines all or part of an implementation of some behaviour for a class of objects, but with some extension points for concrete subclasses to provide.
An interface is a type - it defines the set of operations which are provided by any class implementing the interface.
You're almost asking whether there is anything that a candidate can do that the job description can't. Creating an abstract class says 'here is a template for some implementation'. Creating an interface says 'I expect an object to provide these capabilities'. You can use virtual methods in an abstract class to implement some aspects of a type, but the intention is different.
It is not possible to create an object by directly calling the constructor of an abstract class. The constructor of an abstract class can be called only from a derived class. It therefore seems to me that constructors of an abstract class must be either protected or package-private (the latter for the unusual cases of restricting use of a constructor to derived classes within the package). Yet Java allows the constructor of an abstract class to be public.
Are there any circumstances in which it is useful to declare the constructor of an abstract class to be public, rather than protected or package-private?
This is not quite a duplicate of the question "Abstract class constructor access modifier": clearly you can declare a constructor to be public; I want to know whether there is ever any good reason to do so. It seems to me that there is not. I see that C# has a similar peculiarity.
The answer is the same for java:
THere's no reason for a public constructor for an abstract class. I'd assume that the reason that the compiler doesn't complain is as simple that they just didn't spend time covering that since it really doesn't matter if it's public or protected. (source)
You can't call a constructor of an abstract class from anything other than a direct subclass.
So adding a special rule for access modifiers of constructors of abstract classes wouldn't add something useful to the language.
One thing that looks like an exception from this rule - if the abstract class only defines a default constructor, then the subclass does not have to implement a constructor: this is legal:
public abstract class A {
public A() {}
}
public class B extends A {}
So we can create a B by calling new B() - but note, that we still create a B and not an A. And, again, it doesn't matter if the constructor in A is public or protected. It just shouldn't be private, but the compiler will notice and complain...
Actually we invoke an "invisible" public default constructor on B which does a simple super() call...
The visibility also infuences what is shown in the javadoc (if it's selected to exclude certain visibility levels). As it doesn't matter otherwise, that could be a usage for a public constructor of an abstract class.
If you provide no constructor, then the default constructor is public if the class is public. Easiest option would be to allow that, rather than forcing protected constructors.
In that sense the reverse question may make it clear: why didn't they force protected constructors in abstract classes? Because public constructors won't change anything, so it would just take time and add complexity.
Call me a heretic, but ... I see at least one use for a constructor in an abstract class.
That is: to specify what the constructor parameters look like.
Specify an abstract constructor (thus making the class abstract). Derived classes have to implement this constructor with its specific signature to lose abstract status.
I see no other way to specify mandatory constructor signatures (help me out if you do).
You can have a public constructor if you do not define in a constructor in the sub-class.
example
abstract class Animal {
String name;
public void Animal(String name) {
this.name = name;
}
}
class Cat extends Animal{
public String sayMayName() {
return this.name;
}
}
myCat = new Cat("tester");
name = myCat.sayMyName();
if no constructor is defined the parent class constructor will be called, if it is not public it will not work. This I think is more elegantly done with a factory pattern, but I used it in practice in PHP and it works fine.
Can I define an abstract class without adding an abstract method?
Of course.
Declaring a class abstract only means that you don't allow it to be instantiated on its own.
Declaring a method abstract means that subclasses have to provide an implementation for that method.
The two are separate concepts, though obviously you can't have an abstract method in a non-abstract class. You can even have abstract classes with final methods but never the other way around.
Yes you can. The abstract class used in java signifies that you can't create an object of the class. And an abstract method the subclasses have to provide an implementation for that method.
So you can easily define an abstract class without any abstract method.
As for Example :
public abstract class AbstractClass{
public String nonAbstractMethodOne(String param1,String param2){
String param = param1 + param2;
return param;
}
public static void nonAbstractMethodTwo(String param){
System.out.println("Value of param is "+param);
}
}
This is fine.
Yes you can do it. Why don't you just try doing that?
YES You can create abstract class with out any abstract method the best example of abstract class without abstract method is HttpServlet
Abstract Method is a method which have no body, If you declared at least one method into the class, the class must be declared as an abstract its mandatory BUT if you declared the abstract class its not mandatory to declared the abstract method inside the class.
You cannot create objects of abstract class, which means that it cannot be instantiated.
Yes we can have an abstract class without Abstract Methods as both are independent concepts. Declaring a class abstract means that it can not be instantiated on its own and can only be sub classed. Declaring a method abstract means that Method will be defined in the subclass.
Yes, you can declare a class you cannot instantiate by itself with only methods that already have implementations. This would be useful if you wanted to add abstract methods in the future, or if you did not want the class to be directly instantiated even though it has no abstract properties.
yes, we can declare an abstract class without any abstract method. the purpose of declaring a class as abstract is not to instantiate the class.
so two cases
1) abstract class with abstract methods.
these type of classes, we must inherit a class from this abstract class and must override the abstract methods in our class,
ex: GenricServlet class
2) abstract class without abstract methods.
these type of classes, we must inherit a class from this abstract class,
ex: HttpServlet class
purpose of doing is although you if you don't implement your logic in child class you can get the parent logic
please check the HttpServlet source code
You can, the question in my mind is more should you. Right from the beginning, I'll say that there is no hard and fast answer. Do the right thing for your current situation.
To me inheritance implies an 'is-a' relationship. Imagine a dog class, which can be extended by more specialized sub types (Alsatian, Poodle, etc). In this case making the dog class abstract may be the right thing to do since sub-types are dogs. Now let's imagine that dogs need a collar. In this case inheritance doesn't make sense: it's nonsense to have a 'is-a' relationship between dogs and collars. This is definitely a 'has-a' relationship, collar is a collaborating object. Making collar abstract just so that dogs can have one doesn't make sense.
I often find that abstract classes with no abstract methods are really expressing a 'has-a' relationship. In these cases I usually find that the code can be better factored without using inheritance. I also find that abstract classes with no abstract method are often a code smell and at the very least should lead to questions being raised in a code review.
Again, this is entirely subjective. There may well be situations when an abstract class with no abstract methods makes sense, it's entirely up to interpretation and justification. Make the best decision for whatever you're working on.
yes you can do that.
declaring class abstract means that class will not be instantiated by any other class.
and there should be at least one abstract method inside that and meaning of that you can declare abstract method in that class if you are not declaring method than its ok.
example:
public abstract class abs {
protected int cx = 0, cy = 0;
public void p() {
System.out.print("hello");
}
}
this will work for sure.
Yes you can. Sometimes you may get asked this question that what is the purpose doing this?
The answer is: sometimes we have to restrict the class from instantiating by its own. In that case, we want user to extend our Abstract class and instantiate child class
Actually there is no mean if an abstract class doesnt have any abstract method . An abstract class is like a father. This father have some properties and behaviors,when you as a child want to be a child of the father, father says the child(you)that must be this way, its our MOTO, and if you don`t want to do, you are not my child.
Yes, you can define an abstract class without an abstract method. However, if there is no method inside you might better go with an interface