Scala for Simpltons. Objects and Classes… Get that static garbage out of here.

Objects and Classes, the building blocks of all things programming. Today I'm going to cover a few Scala concepts at a moderately high level. (I’m here learning with you guys) We will be going over

• Singleton Objects.
• Companion Classes.
• Abstract Classes.
• Case Classes.
• the “apply” method.

This will, if all goes well, put us in a good place for “Pattern Matching”. So without further ado (yes it’s ado and not that weird french word… man I can’t stand elitists) Let's go.

Singleton

A Singleton is a class that can only return one instance of itself. This means when you use this object you are always using the object at its certain point in memory and never a copy of it. In Scala, top-level objects are all “Single Instanced” with Classes being instantiable. Objects are path-dependent, so src.hero.SuperPowerObject is a completely different object from src.villan.SuperPowerObject.

Companions. Classes and Objects.

The key thing to understand about companion classes and objects is that companion classes and objects have access to each other's private fields and methods. Above you see 2 objects and 1 class, the Connection object has a private method connectToDb which is called inside of its companion class below. There are many different use cases for this, but one key thing to remember is that Objects in scala are static, and if you are using a companion class somewhere else in the application, you will have access to the object's private variables and methods.

Abstract Classes

preferredName is the result of the function def preferredName, notice you do not need to call a function that has no parameters.

Just as many of you would assume, an abstract class is a class that only defines its methods signatures and not their implementations. (As I’m typing this, I'm realizing I really need to jump into Data patterns… ) Anyways, abstract classes create an IS-A relationship between themselves and where they are being extended. This means wherever you extend an abstract class you must also define its methods within the extending class. Before I switch gears, Abstract classes are classes, so they can be parameterized, given parameters that are the same as fields in Scala. Traits on the other hand….

Traits (Bonus)

Frogs jump, Adults humans can jump, babies don't jump though, neither do lizards… are people more closely related to frogs than babies?…

I wasn't going to go over traits, but I think it's necessary, traits are reminiscent of interfaces in Java. They fit with Scalas preferred method of class building which would be through composition a much more concise and granular way of composing a program. So, imagine you are trying to represent the animal kingdom, you have an Animal base class that houses all of your “Animal” shared fields and methods, but then you have to start describing a multitude of animals that have branched out vastly down their own evolutionary paths. This is where creating extensions through an incredibly deep web of relationships could get very tricky. Instead, you could break things into traits each animal child class could be defined fitting their overall type or scientific classification, but when we want to create shared connections between different species we can do so by defining them by traits. For example a Great Ape, 🦍 🦧 (love the mac book pro… emojis are lit 🔥 )

Apes are extremely diverse in many aspects from social structures to their diets. Some apes eat only fruits and berries, others will eat the brains of one of their own. Yet they are all Apes, what makes a Gorilla a gorilla vs a human? and how many separate classes would it take to get to one or the other from the base Ape class? Traits provide granularity, orthogonality, and modularity.. should have thrown out a big word alert.

Case Classes

C to the A to the S to the E

Case Classes, they have a couple uses, one being modeling immutable data, quickly. Scala case classes have build in apply methods that return new instances of the class.

Now wait a gosh darn min… I looked at your code and if they are different instances then why is numberOne equal to numberTwo?

Case classes compare at a structure level not a reference level, this allows for comparison based on the case classes values, not its point in memory.

Next week I will be tackling Pattern Matching which case classes are very handy for.

Apply Methods

So, you may have noticed throughout the code examples I haven't been using the new keyword to instanciate objects… This is due to Objects making use of their apply methods that are used as factory functions. Case classes have have a default apply method built in, above you can see how I have multiple apply methods and one apply method is actually using the same objects multi parameter apply method, both return a new instance.

NEXT TIME ON SCALA FOR SIMPLETONS…

Pattern Matching… This will be interesting. scroll up a few inches for a sneak peak 😉 Hope you enjoyed.

For more Scala, visit
Data-flair (They have a cool tutorial)
https://data-flair.training/blogs/scala-tutorial/
Scala Docs
https://docs.scala-lang.org/tour/case-classes.html
Scala Book
https://docs.scala-lang.org/overviews/scala-book/
I have no idea what this site is, but it looks really cool. Not Scala related, or maybe it is… I don't know.
https://llvm.org/devmtg/2009-10/ScalarEvolutionAndLoopOptimization.pdf