how to inherit parent class to the child class with different method of inheritance?
I have written the code but in multilevel inheritance I am not getting the expected output. and getting difficulty in understanding the hierarchy inheritance.
Related
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 know that a class can inherit from another class, but there are lots of different names for these.
A child class inherits from a parent class
A subclass inherits from a superclass
A derived class inherits from a base class
Are these all just different names for the same thing? Or am I missing the point?
Generally these three can be the same or different depending on the context,
A super class always suggest that it is the root class so does base class but parent class is a loose term. A parent class class can be a base class and derived class at the same time . It can be the superclass as well. So context matters .
I hope you get the idea .
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.
It seems to me that I can make just about anything using object, trait, abstract class and in rare occasions, case class. Most of this is in the form object extends trait. So, I'm wondering, when should I, if ever, use a plain, standard class?
This is not a right place to ask this question
Looks like you are new Scala
Class is a specification for something(some entity) you want to model . It contains behavior and state
There is only one way to declare so called regular class using keyword class
Both trait and abstract class are used for inheritance.
trait is used for inheritance (generally to put common behavior in there). trait is akin to interface in Java. multiple inheritance possible with traits but not abstract class.
A class can extends one class or abstract class but can mixin any number of traits. Traits can have behavior and state.
case class is a nothing but a class but compiler produces some boilerplate code for us to make things easy and look good.
object is used when you want to declare some class but you want to have single instance of the class in the JVM (remember singleton pattern).
If an object performs stateful computations on its members i.e. its members are declared with vars;
Or, even if its member are only declared with vals but those vals store mutable data structures which can be edited in place, then it should be an ordinary (mutable) class akin to a Java mutable object.
The idiomatic way of using Case classes in Scala is as immutable types i.e. all the constructor arguments are vals. We could use vars but then we lose the advantages of case classes like equality comparisons will break over time.
Some advise from Programming in Scala by Odersky et al on deciding between using traits, abstract classes and concrete classes:
If the behavior will not be reused, then make it a concrete class. It is not reusable behavior after all.
If it might be reused in multiple, unrelated classes, make it a trait.
Only traits can be mixed into different parts of the class hierarchy.
If you want to inherit from it in Java code, use an abstract class.
Since traits with code do not have a close Java analog, it tends to be
awkward to inherit from a trait in a Java class. Inheriting from a
Scala class, meanwhile, is exactly like inheriting from a Java class.
As one exception, a Scala trait with only abstract members translates
directly to a Java interface, so you should feel free to define such
traits even if you expect Java code to inherit from it. See Chapter 29
for more information on working with Java and Scala together.
If you plan to distribute it in compiled form, and you expect outside
groups to write classes inheriting from it, you might lean towards
using an abstract class. The issue is that when a trait gains or loses
a member, any classes that inherit from it must be recompiled, even if
they have not changed. If outside clients will only call into the
behavior, instead of inheriting from it, then using a trait is fine.
If efficiency is very important, lean towards using a class. Most Java
runtimes make a virtual method invocation of a class member a faster
operation than an interface method invocation. Traits get compiled to
interfaces and therefore may pay a slight performance overhead.
However, you should make this choice only if you know that the trait
in question constitutes a performance bottleneck and have evidence
that using a class instead actually solves the problem.
If you still do not know, after considering the above, then start by
making it as a trait. You can always
change it later, and in general using a trait keeps more options open.