0

I am learning Object Oriented Programming, but I am confused about abstract class and concrete class. Some real world examples would be appreciated. And what are benefits of using one over another? When would one prefer abstract class and concrete class?

If answer is particular to any language than I am asking in context of Ruby

Bhushan Lodha
  • 6,824
  • 7
  • 62
  • 100
  • 2
    This may give you some general idea..not ruby though... http://stackoverflow.com/questions/2149207/what-is-the-difference-between-a-concrete-class-and-an-abstract-class – knurdy May 07 '12 at 06:23

2 Answers2

3

If you have an object which mustn't get instantiated you should use an abstract class. A concrete class, though, should be used if you want to instantiate this class.

Imagine you want several animal classes. But the rule is just to instantiate specific animals like a dog, cat or a mouse. But now all of those animals share some properties and methods - like a name. So you put them in a base class Animal to avoid code duplication. You can't create an instance of Animal though:

public abstract class Animal
{
    public string Name { get; set; }
    public void Sleep()
    {
        // sleep
    }
}

public class Cat : Animal
{
    public void Meow()
    {
        // meooooow
    }
}

public void DoSomething()
{
    var animal = new Animal(); // illegal operation
    var cat    = new Cat();    // works fine
}
Michael Schnerring
  • 3,584
  • 4
  • 23
  • 53
  • Well, does sombebody know, why that code highlighting goes that awfully wrong? I can't find a mistake in my code :S – Michael Schnerring May 07 '12 at 09:22
  • SO thinks it's ruby since the question is tagged as such (I believe). It's interpreting the first slashes of your comments as the beginning of regular expressions, and your capitalized words as constants. – Chris Rice May 08 '12 at 02:13
0

An abstract class is typically the base class for concrete classes. (derived, via OO inheritance) An Abstract class typically enforces an interface for the concrete classes. But an Abstract class could also implement common functionality to be used by the concrete classes via methods and attributes.

You cant ever instantiate an Abstract class, but instead can only instantiate the concrete classes, assuming they implement all of the necessary methods.

Brady
  • 10,207
  • 2
  • 20
  • 59
  • "_but instead can only instantiate the concrete classes, assuming they implement all of the necessary methods_". I think thats right for interfaces. Concrete classes which inherit from a base class don't need to implement the base class' members. That's one of the benefits, as well as one of the curses of inheritance. – Michael Schnerring May 07 '12 at 09:28
  • @ebeeb, You're right, I was referring to implementing the abstract methods. Im not so sure about Ruby, but in other languages like C++ and Java, its possible to inherit from an Abstract class and only implement some of the abstract methods (not all of them), which is why I added that particular comment. But then if you dont implement all of the abstract methods, would that be a Concrete class? Maybe its a nomenclature issue. – Brady May 07 '12 at 09:35
  • It is a concrete class as soon as you are able to instantiate it. Even if you don't implement ("implement" is the wrong word here. The right one'd be "hide") one of the base members. If you "implement" a method in a concrete class and a method with the same signature already exists in the base class, you hide the base class implementation. The common way to do this is via `virtual` members in the base class, which can be overridden with the `override` keyword. – Michael Schnerring May 07 '12 at 09:43
  • @ebeeb, point taken about *concrete class* nomenclature. Regarding using the word *implement*: that's why I said "implementing the abstract methods". I've heard what you mention about *hide* be called *shadowing*. – Brady May 07 '12 at 09:49