Return to Answer

I'm sort of watching the answers to this question myself, to see what other people have to say, but I will say three things that I'm inclined to think about this:

1. People put way too much faith into interfaces, and too little faith into classes. Interfaces are essentially very watered down base classes, and there are times when using something lightweight can lead to things like excessive boilerplate code.

2. There is nothing wrong at all with overriding a method, calling super.method() within it, and letting the rest of its body just do things that don't interfere with the base class. This does not violate the Liskov Substitution Principle.

3. As a rule of thumb, being this rigid and dogmatic in software engineering is a bad idea, even if something generally is a best practice.

So I would take what was said with a grain of salt.

I'm sort of watching the answers to this question myself, to see what other people have to say, but I will say three things that I'm inclined to think about this:

1. People put way too much faith into interfaces, and too little faith into classes. Interfaces are essentially very watered down base classes, and there are occasions when using something lightweight can lead to things like excessive boilerplate code.

2. There is nothing wrong at all with overriding a method, calling super.method() within it, and letting the rest of its body just do things that don't interfere with the base class. This does not violate the Liskov Substitution Principle.

3. As a rule of thumb, being this rigid and dogmatic in software engineering is a bad idea, even if something generally is a best practice.

So I would take what was said with a grain of salt.

I'm sort of watching the answers to this question myself, to see what other people have to say, but I will say three things that I'm inclined to think about this:

1. People put way too much faith into interfaces, and too little faith into classes. Interfaces are essentially very watered down base classes, and there are occasions when using something lightweight can lead to things like excessive boilerplate code.

2. There is nothing wrong at all with overriding a method, calling super.method() within it, and letting the rest of its body just do things that don't interfere with the base class. This does not violate the Liskov Substitution Principle.

3. As a rule of thumb, being this rigid and dogmatic in software engineering is a bad idea, even if something generally is a best practice.

So I would take what was said with a grain of salt.

I'm sort of watching the answers to this question myself, to see what other people have to say, but I will say three things that I'm inclined to think about this:

1. People put way too much faith into interfaces, and too little faith into classes. Interfaces are essentially very watered down base classes, and there are times when using something lightweight can lead to things like excessive boilerplate code.

2. There is nothing wrong at all with overriding a method, calling super.method() within it, and letting the rest of its body just do things that don't interfere with the base class. This does not violate the Liskov Substitution Principle.

3. As a rule of thumb, being this rigid and dogmatic in software engineering is a bad idea, even if something generally is a best practice.

So I would take what was said with a grain of salt.

I'm sort of watching the answers to this question myself, to see what other people have to say, but I will say three things that I'm inclined to think about this:

1. People put way too much faith into interfaces, and too little faith into classes.

2. There is nothing wrong at all with overriding a method, calling super.method() within it, and letting the rest of its body just do things that don't interfere with the base class.

3. As a rule of thumb, being this rigid and dogmatic in software engineering is a bad idea, even if something generally is a best practice.

So I would take what was said with a grain of salt.

I'm sort of watching the answers to this question myself, to see what other people have to say, but I will say three things that I'm inclined to think about this:

1. People put way too much faith into interfaces, and too little faith into classes. Interfaces are essentially very watered down base classes, and there are occasions when using something lightweight can lead to things like excessive boilerplate code.

2. There is nothing wrong at all with overriding a method, calling super.method() within it, and letting the rest of its body just do things that don't interfere with the base class. This does not violate the Liskov Substitution Principle.

3. As a rule of thumb, being this rigid and dogmatic in software engineering is a bad idea, even if something generally is a best practice.

So I would take what was said with a grain of salt.