From an OOP point of view is there any difference between a derived class and an inherited class? Or is it simply terminology?
When using inheritance, the inherited class is called the base class, and the inheriting class is called the
derived class.
The term derived class is preferred C++ parlance for a class that inherits from another class, which in C++ parlance is called a base class. So in C++ the terms you ask about are identical.
Neil's answer confused me a bit, and so I checked some public sources.
Consider a Base Class and a Sub Class (SubClass extends BaseClass in Java terminology), than
the Sub Class derives Base Class (Sub Class is a derived class of Base Class) and
the Sub Class inherits from Base Class (Base Class is a/the inherited class of Sub Class)
So in my opinion both terms define the same relationship between to classes but from different perspectives.
Inheritance terminology by Bertran Meyer (Object-Oriented Software Construction, p.464):
Basic conventions and terminology
The following terms will be useful in addition to “heir” and “parent”.
A descendant of a class C is any class that inherits directly or indirectly from
C, including C itself. (Formally: either C or, recursively, a descendant of an
heir of C.)
An ancestor of C is a class A such that C is a descendant of A.
In the literature you will also encounter the terms “subclass” and “superclass”, but
we will stay away from them because they are ambiguous; sometimes “subclass” means
heir (immediate descendant), sometimes it is used in the more general sense of proper
descendant, and it is not always clear which. In addition, we will see that the “subset”
connotation of this word is not always justified.
maybe interesting, if you override a method, in Delphi you write:
inherited; // so "inherited" is the base class
instead of
base.BaseImplementation(); // C#
Related
Dart Example.
abstract class Figure{
final int numberOfCorners;
Figure(this.numberOfCorners);
}
class Square extends Figure{
Square():super(4);
}
class Triangle extends Figure{
Triangle():super(3);
}
It confuses me that this is actually a narrowing. Derived classes
finally define base class field. It is the opposite of extending (adding new methods\fields). But I see this pattern regularly.
Which architectural pattern would make more sense?
There are many opinions about declaration fields in base class. In my view, it makes very tight coupling between base and derived classes. It creates a fragile and rigid relationship between classes. So I would create these fields in classes and avoid inheritance here. Read more about when your inheritance is all about attributes.
Inheritance can be violated very easily. It works fine, if it is used appropriately.
Let me show an example where inheritance misused. For example, there is a base class called “Duck” and you have method “Fly()” in base class. But not all ducks can fly. But our derived class “NotFlyingDuck” inherits method “Fly()”. And by creating derived classes “NotFlyingDuck”, we violate Liskov substitution principle.
The general rule I met is that inheritance should be used to declare behaviour in base class and all derived classes should implement this behaviour. You can read more here. So if all public methods in derived classes should be taken from base class, then it means that it is possible to use inheritance.
I was going through the differences between Interface versus Abstract class on MSDN but got some confusion on below difference:
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
I have confusion on this line
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**
Could you help explain?
methodes you write in the interface you should obligatory put it in your class Which implements in the iterface
and the abstract class is the opposit of interface the methodes you put in class abstract you can use it in your class or not.
An abstract base class is a class whose sole intent is to be derived. An interface is the set of public methods of a concrete class.
While they differ very little in actual functionality, I like to think of interfaces as an adjective while an abstract class is a noun. For the classic instance of an animal, an interface is used do describe attributes, like pet-able, friendly, dangerous. On the other hand, an abstract class would describe the thing itself more narrowly, like canine, feline or human.
Is there any difference between a parent class and a super class? Is a super class simply a parent class that doesn't inherit from other classes?
This is more of a terminology difference, the idea of parent and child classes or super and subclasses. It seems to depend on programming language experience and application domain as to which one you use as well as when you first began getting into Object Oriented Programming.
In both cases there is a class, the parent class or super class or base class, from which is derived other classes, the child class or subclass. The child class or subclass extends the parent class or super class by adding some capability to the existing capability of the class being extended.
super() is how the parent or super class constructor for a Java class is invoked in a derived class.
There was a fair amount of churn in the terminology during the first years of object oriented programming as various people worked in the area and published papers and books and developed Object Oriented Languages. It was all quite new and exciting and people were trying to decide the proper vocabulary to use so they were trying out various words and phrases to express Object Oriented concepts.
And with a number of Object Oriented Programming languages that have been developed and gained popularity, a community developed around the language with a particular vocabulary. So older and more experienced programmers who were into object oriented early on may call things a bit different.
Parent and child is also used in describing other kinds of Is-A or Has-A relationships. For instance Parent window and Child window is also used for windowing systems in which a window, the Child, is contained within another window, the Parent. So the Parent window Has-A Child window.
I'd say it's the same.
You might want to differentiate between a direct and indirect parent or super class, but I guess the two terms are not clear enough on this, either. So if this is what you are trying to express, better be explicit.
Also, many programming languages have the "super" keyword used to refer to the (single) direct parent class. But even there, if you call a "super" method and the direct parent does not implement it, it also bubbles up.
They are different terms to address the same OOP concept: inheritance. If class ChildClass extends ParentClass you can say:
ChildClass parent class is ParentClass
ParentClass is the super-class of ChildClass
Inheritance levels have nothing to do there, it doesn't matter if a Super-Class itself extends another class.
They are essentially the same. Depending on the language, the terminology changes. Parent may mean the immediate parent, while Super class may mean any of the ancestor classes. In addition, in java, there is the super() method, which calls the parent's constructor.
In Ruby language we have both the concepts meaning different things.
ParentClass -> ChildClass -> this is used for namespacing
and
SuperClass -> SubClass -> this is used for inheritance
Examples below:
ParentClass -> ChildClass:
class A
def self.f1
puts "A -> #{self.name}.f1 called"
end
# B is childclass of A
class B
def self.f2
puts "B -> #{self.name}.f2 called"
end
end
end
# C is subclass of A
class C < A
def self.f3
puts "C -> #{self.name}.f3 called"
B.f2
end
end
See the output below:
C.f1
A -> C.f1 called
C.f3
C -> C.f3 called
B -> A::B.f2 called
Im trying to understand the various definitions, other students do not quite agree with me.
My definitions, please correct them if wrong:
Base class is the top most class in the hierarchy.
Super and Ancestor class, any class higher up in the hierarchy (including the base class)
Parent class, the next class up in the hierarchy.
Yes. Parent Classes are the direct superclasses (up to one level in the hierarchy) of your class. Depending on your programming language, a class can have multiple parents.
While an ancestor class, is any superclass of your class (a parent class, a parent of a parent class and so on).
According to the wikipedia definition a base class is any class from which another class inherits one or more properties or methods. If you accept this definition, it means that super, ancestor, parent and base class are all synonymous with each other in terms of describing the relationship of a class with a particular sub-class.
One of the interview questions which they asked me very recently.
What is an abstract class in C#?
Abstract Class - is a class which cannot be instantiated & can include abstract or instance methods, constructors etc.
Instance methods can be used for implementing common functionality for all derived classes which inherits this abstract class.
Ok...Now the question is why we need an abstract class here for implementing the common functionality. The same common functionality i can put in a base class and let the derived class can access the base class methods..right?? if thats the case, instead of having an abstract class.. can i go for base class?? or to put the common functionality in abstract class and let the derive class do access those methods?
If my base class can solve the implementing of common functionality, then why do we need an abstract class for common functionality???
Need help in proper understanding....
An abstract class is a base class - but it's a base class which typically has some abstract members. This allows you to write code in the abstract class which calls those abstract members, but without any implementation... it then forces concrete classes deriving from the abstract class to implement those members.
The benefits of having an abstract class rather than just a concrete base class where some members throw NotImplementExceptions are:
Derived classes are forced (at compile-time) to implement the relevant members
Clients can't just create an instance of the base class; they have to use a concrete class which provides the appropriate "missing" members.
As an example, the other day I wrote an abstract class class extending JsonConverter in Json.NET. The aim was for it to be a base class for any converters for structs within my project - it would handle all the nullable type conversions (and deserializing empty JSON to a null value), leaving the derived classes free to just concentrate on the type-specific part. Have a look at it (NodaConverterBase) and see if it makes things any clearer.
An Abstract Class is used as a Base class. There are times when you may want to have common functionality be implemented but not directly instantiate an instance of your Base Class Type so you would use an Abstract Class instead.
Look at it this way, if you were writing an app to keep track of zoo animals you would have classes for Monkey, Elephant, Crocodile, etc... They are all animals, so you would have them inherit a base class of Animal (because they all need basic functionality like eating, breathing, etc...). But you would never have an animal that's just an animal, so you would make Animal abstract because you would never need an instance of it.
The tricky phrase is
"partial implementation."
In addition to what you mention in your post, the abstract class does not have to implement all the functions AND the children MUST implement the unimplemented functions or be themselves declared abstract.