We are having a UML course. The teacher said:
Every class should be declared as abstract if it serves as base class for
its derived classes.
In the following figure suppose that we want to derive class german shepherd and class labrador from class chien (Dog woof woof). Is it an obligation for class chien to become an abstract class or not?
Not necessarily.
That statement isn't necessarily true. A more correct statement would be:
Every class should be declared as abstract if it cannot be instantiated without referring to a concrete derived class.
In your example, it makes sense that Dog and Animal would be abstract, because you have more specific classes that likely fill out details that the base classes do not.
However, it is certainly possible to have a class which is concrete and can be instantiated, (and therefore not abstract), but still serve as the base for another class.
It should be abstract if it's a generalization and cannot exist on it's own.
Look at this situation:
In the image above Relation is abstract. It can't exist by it's own. Customer and Employee are normal classes who extend Relation. But Trainee is a Employee.
You could create a Employee, but also a trainee which is a Employee as well.
Related
https://dart.dev/guides/language/language-tour#implicit-interfaces
I've seen code that uses "implements", so I'm looking into "implements".
But I can't really tell the difference from extends by looking at the official docs.
Looking at the sample code in the official documentation (page above), it looks like it is just doing what it can do with extends with implements.
Then I wonder if it should use "extends".
I think I've understood about inheritance (extends) and mixins (with) so far.
The word "interface" is also mentioned in the Dart documentation, but there is a clear definition of "interface".
I can't even find where it is.
I don't have much knowledge about interfaces in other languages, so it's hard to get an image.
What exactly is the difference between inheritance and implementation?
Because of the difference, when do you use the inheritance "extends" and when do you use the implementation "implements"?
Is there somewhere in the sample that makes a clear difference?
Given class MyClass:
MyClass extends Foo is classic inheritance. MyClass is a Foo
MyClass implements Bar is declaring that the implementer conforms to the Bar interface. MyClass "looks" like a Bar
MyClass with Batz is "mixing" in the interface and implementation. MyClass "acts" like a Batz.
MyClass can implement and mixin as many interfaces as needed (some limitations apply) but can only extend from one interface.
Besides other explanations, dart does not let developers to use multiple inheritance so there can be only one extends, however there can be more than one implements.
Therefore a class can be subtype of only one class(except parents of parent class) but interfaces defines behaviour of the class which implements it and one class can have different behaviours.
A simple analogy is from animals. If we assume there is different behaviours for animals like swimming interface as ISwimmer, running interface as IRunner and flying interface as IFlyer. For example a Fish class is an Animal. Which makes it extends Animal class. Additionally a Fish has behaviour of swimming so it implements ISwimmer interface in that purpose.
If you just want to understand how they are different concept-wise then,
You extend a class. Think of it as you extended your father or your father is your base class.
You implement an interface(which is just a purely abstract class). Like Ferrari implements a car.
An interface cannot have an instance. For example - Have you seen any CAR? The answer is no, you have seen types of car i.e, Ford, Toyota which implements the CAR so the car acts as an interface which other companies or you can say, classes(Ferrari) implements.
You have to implement every feature of a car to be called a car that's why every method of an interface needs to be implemented and we say x "implements" y.
In extending you can override something and skip another , suppose your nose may look like your father but your ears do not.
Think of an interface as a skeleton or just an empty class.
I was reading an article about composition vs inheritance and the article uses the terms "domain class" and "implementation class". The author specifically says "Domain classes should use implementation classes, not inherit from them". Please explain the difference between a domain class and an implementation class.
The example of an implementation class given in the article is ArrayList. It's not part of the code describing business entities, it's just a commonly-used general purpose class.
This contrasts with the Customer class that they mention. Customer would be a class that is part of the domain, where it is describing an entity specific to the business.
The article is telling you not to extend from utility classes like this when creating domain classes.
How to Misuse Inheritance - Example 2
Creating a domain-concept class by inheriting from an implementation class is a common misuse of inheritance. For example, suppose we want to do something with a certain segment of our customers. The easy and obvious thing to do is to subclass ArrayList, call it CustomerGroup, and start coding, right?
Wrong. That would be a cross-domain inheritance relationship, and those should be avoided:
1) ArrayList is a subclass of list already, a utility collection - an implementation class.
2) CustomerGroup is another subclass - a domain class.
3) Domain classes should use implementation classes, not inherit from them.
If you need to implement a CustomerGroup class it could have an ArrayList as an instance member, like this:
public class CustomerGroup {
private List<Customer> customers = new ArrayList<>();
public List<Customer> getCustomers() {return customers;}
}
but you wouldn't make the class itself be a subclass of ArrayList.
The reason is that when you subclass something the users of your class get all the functionality of the superclass even if it isn't appropriate. You don't really need a domain class to see this in action, just go check out the source for java.util.Properties, which is badly designed, extending java.util.Hashtable. When you use a Properties object the methods from Hashtable are available to you, even though they are totally unnecessary and confusing, and using the superclass methods doesn't work or causes problems.
Hey I have being looking a lot and watching a lot of videos about inheritance.
There is just this concept of abstract classes which means that it cant be implemented.
I get that you cant use a abstract class on a gameobject but what is the force of using a abstract class?
Also can abstract method only be implemented in a abstract class, and why cant you implement the method in a abstract class but only override it?
I also read something about a abstract method taking a component<T> and I havent found out what the purpase of that was hope some of you clever minds can help a confused programmer :D
Abstract classes are used to model a shared "master class" which will never be used itself but derived classes of it will use that data/functions.
For example say your inheritance is
Animal
Bird Mammal Reptile
In your game, you will only ever use a Bird/Mammal/Reptile since those are concrete models of animals, But they all will share at least some common amount of code. Health, Hunger, and may provide some abstract functions such as Move() which will be implemented on a per subclass level.
From an engineering standpoint, this let's you do fancy things such as create an array/vector of type Animal which can contain birds, mammals, and reptiles.
So say we have a vector of type Animal with 1 of each subclass.
We can then do
foreach (Animal a in animals)
a.Move(100)
Birds/Mammals/Reptiles all move differently, but because we have that abstract function with no implementation at the base level, our code can guarantee that at some point in the inheritance tree it is implemented.
Other popular examples are an abstract class of Item and the abstract function item.Use(); Item could be a Potion, a Scroll, an apple (class Food). It doesn't matter because they all share that same base level interface.
I think reading Microsoft's article on Abstract Classes and Methods would be extremely helpful. You utilize abstract classes by providing base functionality to a class and inheriting from it.
You're also confusing some wording with implement and override: you implement an abstract method by overriding it.
Component<T> means that the class Component with the type parameter as something you define. This is defined in C# as Generics. You utilize these with base Unity3D classes like Component<GameObject> or GetComponent<GameObject>.
I have an inherited class which i would like to point to from the base class. Example below
class Base
{
inherited* test;
};
class inherited: Base
{
};
the purpose of this is so that the base class (a character) contains a linked list of the inherited class (items)
ps apologies for any mistakes, i'm new to this site
It might be possible to trick the compiler into accomplishing this, but it's most certainly bad OOP design. If all you want to do is be able to store an instance of the inherited class but can treat it like the base class, then you can simply make inherited* test a base* test and it will accept pointers to either inherited or base (or any other subclass of base).
If you actually want base to treat that instance as inherited, you need to rethink your class hierarchy because you don't actually have an inheritance tree here.
I have a clue about Object Oriented Programming:
I need to have a parent class HandlerException which needs to define the sign of three methods (MethodA, MethodB, MethodC).
Then, I have a child class BusinessHandler which inherits from HandlerException and defines ONLY the MethodA of its parent class.
Then, I have a child class DataHandler which inherits from HandlerException and defines ONLY MethodC of its parent class.
Then, I have a class named CustomerDAO which inherits from DataHandler and consumes the MethodC written on its parent class. (consumes it like: DataHandler.MethodC).
As you can see, its a typical object oriented programming problem; I need to have some static methods (MethodC) to access it directly without any instance of the class. The parent class HandlerException could be abstract? and its 3 methods (A, B and C) could be ???? (that's my question, how is the RIGHT way to write this parent class: abstract with abstract members, or virtual, or maybe an interface?)
I hope you got the idea of my question and that I made myself clear. Thanks in advance.
I forgot: I'm using C#, and to mention: MethodB would be implemented on the next release of the app.
Depends on the language you are using, but it sounds like the HandlerException class would be abstract and all three methods would be virtual.
If the HandlerException class has absolutely no implementation whatsoever (only defines those three methods) then it would probably make sense to make it an interface rather than an abstract class.
Also, where is MethodB implemented? If it isn't implemented by any of those classes, then all the classes would need to be abstract.