# Chapter 2: Types Vs Classes and Subtyping Vs Inheritance In Scala we have predefined classes and we can create our own classes as well, which are we called user-defined classes. But sometimes, we are using Class and Type words interchangeably, **is it correct?** Not exactly. **Types** and **Classes** are two different things and in the layman terms, we can say that Classes can be Types but not vice versa.
Types are an abstraction which contains behavior but Classes are concrete implementation, which contains the properties and behavior.
```scala trait NewType { … } class NewClass(property: Int) { … } ``` Most of the Java/Scala backgrounds always have an illusion, about these two are the same. But while looking at other language(s) like **Haskell** and **OCaml**, the picture is clear. Now, we have some brief idea about that Types and Classes are different. Now, **do you think SubTyping and Inheritance are same?** Not exactly, the implementation of subtyping and inheritance still depends on language to language and according to mathematics, these are different. In languages like **OCaml**, it supports **structural subtyping** while in **Java/Scala** they support **nominal subtyping**. \ **Madhavan Mukund** explains **SubTyping** and **Inheritance** with a beautiful way in his lecture notes called [Programming Language Concepts](https://www.cmi.ac.in/~madhavan/courses/pl2006/lecturenotes/lecture-notes/node28.html). He explains like this way: ### Sub Typing Subtyping concept is generally based on the principle called **Liskov Substitution principle** where type **B** is a subtype of **A** if every function invoked on an object type of **A** is also be invoked in object type of **B**. Languages like **Java/Scala** we can use inheritance as of subtype perspective. But Scala is a mixture of both **OOP** and **FP**, so we can use a bit of structural subtyping via duck typing design pattern.\ **Madhavan Mukund** explains this with the help of examples, where we are going to convert into Scala code. ```scala trait Queue { def deleteFront(): E def insertRear(elemenet: E): E } trait Stack { def insertFront(element: E): E def deleteFront(): E } trait Dequeue { def insertFront(element: E): E def deleteFront(): E def insertRear(elemenet: E): E def deleteRear(): E } ``` In the above examples, we have a `Queue`, `Stack`, and `Deque`. The `Queue` contains two methods `deleteFront` and `insertRear`. The stack contains two methods `insertFront` and `deleteFront`. `Dequeue` contains four methods, `deleteFront`, `insertRear`, `insertFront` and `deleteFront`. In the application, if we are using `Queue` and `Stack`, we can easily replace Queue and Stack with `DeQueue` even there is no inheritance relationship between these classes but not vice versa. Like below code: ```scala def performOperationOnPassedQueue(queue: Queue) = { queue.insertRear(13) queue.deleteFront() } def performOperationsOnPassedStack(stack : Stack) = { stack.insertRear(13) stack.deleteFront() } // Change Queue and Stack from Dequeue def performOperationOnPassedQueue(dequeue: Dequeue) = { dequeue.insertRear(13) dequeue.deleteFront() } def performOperationsOnPassedStack(dequeue : Dequeue) = { dequeue.insertRear(13) dequeue.deleteFront() } ``` In that case, we can say that `Dequeue` is a subtype of `Queue` and `Stack`. Because according to **Liskov Substitution**, if **B** is replaced by **A** then **B** is a SubType of **A**. ### **Inheritance** Inheritance is used in the perspective of code reusability, if class **A** has some properties or behaviors, with help of inheritance we can reuse those behaviors. ```scala trait Queue { def delete(): E def insert(elemenet: E): E } trait Stack { def push(element: E): E def pop(): E } trait Dequeue { def insertFront(element: E): E def deleteFront(): E def insertRear(elemenet: E): E def deleteRear(): E } ``` According to the above example, Queue, Stack and Deque have different method names, but the implementation of deque methods are same as Queue and Stack method. So, in that case, we can say that there is no subtyping between Quest and Deque or Stack and Deque, but can create the inheritance relationship between them, because of code reusability. Like in the below example: ```scala trait Dequeue extends Queue with Stack { def insertFront(element: E): E = { super[Stack].push(element) } def deleteFront(): E = { super[Queue].delete } def insertRear(elemenet: E): E = { super[Queue].insert(element) } def deleteRear(): E = { super[Stack].pop } } ``` Languages like Scala/Java, it is really difficult to separate out these concepts because via inheritance subtyping is also associated. But these concepts are actually different and used for a specific purpose. ### Nominal Typing **Jamie Kyle** gives a beautiful and simple example of **Structural Typing vs Nominal typing** within his [blog](https://medium.com/@thejameskyle/type-systems-structural-vs-nominal-typing-explained-56511dd969f4). Let’s see, how can we implement Nominal and Structural subtyping in Scala. ```scala class Foo { def method(value: Int): String = { … } } class Bar { def method(value: Int): String = { … } } val foo: Foo = new Bar // Compile time error in Scala, because there is no inheritance between these two classes and Scala/Java support nominal subtyping ``` ### **Structural Subtyping** ```scala class Foo { def method(value: Int): String = { … } } class Bar { def method(value: Int): String = { … } } def structuralSubTyping(obj: { def method(value: Int): String }): String = { … } structuralSubTyping(new Foo) structuralSubTyping(new Bar) ``` In Scala Structural Subtyping is also called **Duck Type design pattern**, where we can say, if it walks like a duck, quack like a duck so, we can say that, it is a duck. As per scala best practices, we need to avoid this structural subtyping, because of internally it uses reflection which makes our code slow. #### Note: In Java or Scala for achiveing subtyping we generally using inheritence. So, in this book we will be using subclass and subtype interchangeably. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://harmeetsingh.gitbook.io/scala-type-system/phase-i/chapter-2-types-vs-classes-and-subtyping-vs-inheritence.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.