Object identity and Equality:

‘==‘ and equals()

equals() default implementation is in line with == operator i.e, it
provides identity equality and return true if reference variable
pointing to same object
But if you need logical equality then equals() method needs
override

Ex:
Car myCar1 = new Car("blue");

Car myCar2 = myCar1;

Car myCar3 = new Car("blue");

Here myCar1 and myCar2 point to the same object but myCar3
points to the different object though all three have same content

Think about the WhiteHouse as example, you can have a replica of

WhiteHouse but at a different place so you cannot say replica as
original since both have different address on the globe. Similarly
here though both the objects contain same content and look alike
‘==‘ operator will treat both as different due to different in their
address.

https://dzone.com/articles/object-identity-and-equality-in-java

Which is you need to override the equals() method whenever there

is a need to compare the objects and also when comparing two
objects (or overriding the equals() method) their hashCode should
also be same and hence hashCode() method is also overridden

**HashTable and HashMap are used internally to store the objects

Both equals() and "==" operator in Java is used to compare objects to check equality but the

main difference between equals method and  the == operator is that former is a method and
later is an operator. Since Java doesn’t support operator overloading, == behaves identical for
every object but equals() is method, which can be overridden in Java and logic to compare
objects can be changed based upon business rules
equals and hashcode for every class to test the equality and to provide a hash or digest based on
content of class

Whenever hashCode() mehtod is invoked on the same object more than once within single execution
of application, hashCode() must return same integer provided no information or fields used in
equals and hashcode is modified. This integer is not required to be same during multiple execution
of application though

—————————————————————————————————————————————————————————————
——————————————

Case classes:
Classes with ‘case’ modifier are called case classes - this
modifier makes the Scala compiler add some syntactic
conveniences to the class
Which includes:
1.It adds the factory method with the name of the class
2.All arguments in the parameter list of a case class
implicitly get a val prefix, so they are maintained as fields
3.Compiler adds natural implementations of methods like -
to print, hash and compare a whole tree consisting of the class and
all its arguments
toString
hashCode
equals
4. Compiler adds a copy method to class for making
modified copies - Useful for making a new instance of the class that
is the same as another one except that one or two attributes are
different (works by using named and default parameters)

All the above 4 features come along with the case classes - With
this the class and objects become a bit larger as additional method
are generated and an implicit field is added for each constructor
parameter.

There are 3 differences between Switch(of java) and Match(of

Scala):
1.Match is an expression in Scala - it always results in value
2.Scala’s alternative expressions never “fall through” into the
next case
3.If none of the patterns match, an exception named
MatchError is thrown

Kinds of Patterns:
————————
1.Wildcard patterns
2. Constant patterns
3. Variable patterns
4. Constructor patterns
5. Sequence patterns
6. Tuple patterns
7. Variable binding

Factory objects - Contains the methods that construct other objects.

So instead of using “new” keyword you can refer to these factory
methods to construct the objects.

Companion objects

In Scala, it is common to use syntax that looks like a function call. For example, if firstName
is a string, then

firstName(i) gives the ith character of the string.

Equivalent to firstName.apply(i)

You can think of this as an overloaded form of () operator. It is implemented as a method

with name apply in StringOps class

Option/some/None -
https://commitlogs.com/2016/09/17/scala-option-some-and-none/