DEV Community: Jonathan Kuhl

A Programmer Goes Shopping

Jonathan Kuhl — Wed, 03 Jul 2019 23:00:14 +0000

A Programmer is told by his wife "please go buy milk, and if they have eggs, buy a dozen."

The programmer returns with a dozen jugs of milk.

When his wife angrily asked him why, he said, "they had eggs."

When isn't inheritance used?

Jonathan Kuhl — Sat, 29 Jun 2019 22:27:41 +0000

I was asked in an interview "when would you not use inheritance." And I paused because the only thing I could articulate was "when it doesn't make sense?"

This was for a .NET position, by the way.

The thing that puzzled me about this question was that I didn't really know how to say it. You don't use inheritance when it doesn't apply to the software architecture. And that's more or less what I said, but I was wholly unsatisfied with my answer.

After the interview was done as I was doing my after-action report, I had this sneaking suspicion that he wanted me to mention composition. And as I write this post, I also feel like I should have added immutability, you don't want inheritance on objects that are meant to be immutable (like Java's String class).

But now it bothers me. What would be a good answer to that question?

A Trick With Map

Jonathan Kuhl — Fri, 14 Jun 2019 04:09:27 +0000

The Problem

Consider the following problem I came across on r/learnjavascript: Why does [1,3,11].map(parseInt) result in [1, NaN, 3]?

The Answer

It is common for new developers to be unaware of how map works and how it feeds parameters to the function it is provided. We're all aware that the first parameter it gives is the element in the array we're currently iterating over.

For example: [1,3,11].map(element => console.log(element)) gives us an output that lists 1, 3, 11.

But the fact is, map actually feeds three parameters to the given function. Map provides the current element being iterated over, the current index we're at, and the array being iterated over.

[1,3,11].map((element, index, array) => //... )

We can see this by changing our console.log by referring to it directly rather than wrapping it in an anonymous function:

[1,3,11].map(console.log)
1 0 [ 1, 3, 11 ]
3 1 [ 1, 3, 11 ]
11 2 [ 1, 3, 11 ]

This is pasted directly from the node REPL. You can see here, we get on each line, the element, the index, and the array.

So back to the original problem, why do we get [1, NaN, 3]?

Because these three arguments are being passed into parseInt. I believe that many new developers forget that parseInt actually takes two arguments, more than they would forget that map provides three arguments. parseInt takes a number and the radix. The radix tells parseInt which number system we're using. 0 is decimal, 2 is binary, 3 is trinary, 8 is octal, 16 is hex, and so on and so forth.

parseInt(11, 3) outputs 2 because that's it's trinary equivalent.

So on each pass in map, parseInt looks like this:

parseInt(1, 0);
parseInt(3, 1);
parseInt(11, 2);

The array argument is ignored because parseInt only takes two arguments. The number provided becomes the element from the array and the radix comes from the index.

On the first pass, we're converting 1 to decimal, which is of course, 1. A radix of 0 and 10 are decimal, so nothing changes with decimal numbers. On the second pass, we get NaN because the value 1 is invalid for a radix. And on the third pass, we're converting 11 to 2. 11 in binary is of course, 3. We have a 1 in the 2^1 position and a 1 in the 2^0 position, 2^1 + 2^0 = 2 + 1 = 3.

In short, the reason we get unexpected values, is because map provides more arguments to the parseInt function than we desired.

How do we fix this?

The solution is very simple, we don't directly pass a reference to a function like parseInt to map. Instead, it's best to wrap it in an anonymous function first:

[1, 3, 11].map((element, index, array) => parseInt(element) );

Of course you can omit the index or array parameters if you aren't using them, I left them in for illustration

Then you can pass your arguments to the function as needed.

Now this is only necessary for functions that take, or potentially take, multiple arguments. If you want to map with a function that only takes one argument, feel free to pass it the reference directly.

const square = x => x * x;
[1,2,3].map(square);
//  [1, 4, 9]

Just be careful to be sure whatever you pass into map, and this goes for foreach and many of the other array methods as well, only takes one argument.

You can read more about how parseInt works on the Mozilla Developer Network here.

Happy coding.

The Definition of Recursion is Recursion

Jonathan Kuhl — Thu, 13 Jun 2019 17:31:12 +0000

Recursion

In programming, there are two types of looping, recursion and iteration. Iteration is the most common form of looping, using your basic while and for loops or more complicated generators. Recursion however is when a function is called within its own definition.

Recursion occurs when an algorithm to solve a problem involves repeating the same steps in a diminishing pattern, until you get to a condition where you can break out of the recursion.

To illustrate, let's consider multiplication as being solvable by recursive addition.

x * y = x + x(y-1) + x(y-2) + . . . x(y-n) where y-n > 1

In any form of multiplication, x * y, the multiplication can be thought of as x plus x times y minus one. Repeat, until y is one. Let's take a look with actual numbers:

x = 3, y = 4
3 * 4
= 3 + 3 * 3
= 3 + 3 + 3 * 2
= 3 + 3 + 3 + 3 * 1
= 3 + 3 + 3 + 3
= 12

Note how it is recursive because you're repeating the same steps over and over again as the value of y diminishes. When y is 1, we have our base case where we break out of the recursion. When this happens, the recursion ends, and we simply add up all the threes.

The Stack

So how does this work programmatically? Well, whenever you call a function, a new frame is added to the stack. The stack is a region in memory that handles your functions. When the function completes, it's output value, if it has one, is returned to the stack that called it. This is why the keyword return is named what it is. We're returning to the lower stack frame.

At the bottom is our problem, 3 * 4. To solve this issue, we add a new frame to the stack and input the next step of the problem, which is the bold part of 3 + 3 + 3 * 3. Meanwhile, the current frame will wait for the frame above to return. That frame, will then do the same, making a new frame and inputting the bold part of 3 + 3 + 3 + 3 * 2. And again, the frame will wait for the frame above to return. This continues until we reach the base case.

If there is no base case, the frames will stack on each other until the stack runs out of memory, which leads to a stack overflow error.

Once we reach the base case, the frames start returning. The top frame will return a 3, and pass it to the frame beneath it, which can then finish its calculation and return a 6, and so on and so forth until the frame at the bottom finally receives the returned value it needs and returns a 12.

In the image above, you can see the whole process laid out. We start at "start" and go up, creating new frames until we reach the base case, then we start going down the stack back to the bottom, returning the value of the function in the frame above it all the way down.

Implementation

Most languages support recursion. As Python is one of the easiest languages to read, I'll show you how this can be implemented in programming.

The first thing to think about is, where does the recursion end? This is called the base case. In the above example of 3 * 4, our base case was when we reached 3 + 3 + 3 + 3 * 1. In terms of x * y, it's when y = 1.

If x is 3:

3 * y
= 3 + 3 * (y - 1)
= 3 + 3 . . . + 3 * y: y = 1
= 3 + 3 . . . + 3

When y is 1, the recursion is complete, and the stack can collapse to the value we want.

So now we have the base case, we also need to know which part is the recursion. And that part is the x(y - 1) portion of x + x + ... + x(y - 1) of our equation. This is the part that repeats in each step. The repetition of x + x...+x is resolved as the stack collapses.

Here's the most basic version of our function, in python:

def mult(x, y):
    if y == 1:
        return x
    return x + mult(x, y - 1)

if y is one, we're at our base case. Because x * 1 is x, we can just return x. Otherwise we're going to add the recursive portion of our algorithm, x(y-1), to x and return that value. x(y-1) translates to mult(x, y-1) in this case.

Now we can just call the function and give it a try:

import sys

def mult(x, y):
    if y == 1:
        return x
    return x + mult(x, y - 1)

if __name__ == '__main__':
    x,y = [int(i) for i in sys.argv[1:]]
    print(mult(x,y))

Here I have it set up so we can call the function with arguments in the command line. We're using a list comprehension to turn those arguments into integers and unpacking them into variables x and y, which we then pass into the mult() function, and print to the screen.

We have to slice sys.argv because the zeroth value is always the name of the file, we only want the first and second arguments.

We call with python3 multiply.py 3 4 and it will display a 12.

The command might be different on your machine, depending on how python is installed and aliased in your PATH, and how you've named the file. The syntax is [Python] [filename.py] [x] [y]

When we enter 3 and 4 as x and y, mult(3,4) is called and placed in a new frame on the stack. This function in turn calls itself with mult(3, 4-1) and pushes that on the stack. And this repeats until mult(3,1) is called, where y is 1 and the base case is met.

This final base case will return a 3 to the frame beneath it. The function in that frame can now finally complete its return statement and return a value to the frame beneath it, and so on and so forth, collapsing to the bottom. What we end up with is 3 + 3 + 3 + 3, which is 12.

Improving our function

However our function only works with positive or zero values of y. Negative values will always result in a stack overflow (or in Python, RecursionError: maximum recursion depth exceeded in comparison)

We can make our function work with negatives. The logic is the same, we just have to switch some of the signs around because we're going from left to right on the number line now, whereas with positive values, we're going from right to left. x needs to be made negative and y needs to increase to positive 1 rather than decrease to positive 1.

3 * -4
= -3 + 3 * -3
= -3 - 3 + 3 * -2
= -3 - 3 - 3 + 3 * -1 
= -3 - 3 - 3 - 3
= -12

Or in Python, we add a new if statement:


import sys

def mult(x, y):
    if y == 1:
        return x
    if y >= 1:
        return x + mult(x, y - 1)
    else:
        return -x + mult(x, y + 1)

if __name__ == '__main__':
    x,y = [int(i) for i in sys.argv[1:]]
    print(mult(x,y))

Now it works with negative values as well. Negative values in x are handled by the natural way negatives work in addition and subtraction, so we don't need to worry about that scenario. Plug in any integer and this function should work.

Where Do We Use Recursion?

Of course, this function is useless, Python, and most other programming languages, provides us with a multiplication operator and we don't need to worry about the internal implementation of it.

But recursion itself is useful wherever you see a repeating pattern where the steps for solving a problem involves repeating the steps of an algorithm again and again until diminishing to some base case. Another example is a factorial.

Factorials in math are defined as:

x! = x * (x-1) * (x-2) ... * (x - [x-1])
5! = 5 * (5 -1) * (5 - 2) * (5 - 3) * (5 - 4) = 120
5! = 5 * 4 * 3 * 2 * 1 = 120

And in Python:

def fact(x):
    if x == 1:
        return x
    return x * fact(x - 1)

Here you can see a repeating pattern where the steps to solve are the same and diminishing towards a base case. This makes recursion a good tool to solve. When you can see this pattern, you know recursion is a tool you can use to implement a solution.

In most cases where recursion is used, iteration can also be used. Iteration is often cleaner, easier to maintain and understand, and is usually more performant, which is why I prefer iteration. Sometimes however, recursion really is the simplest solution, even against iteration.

Take for example Minesweeper. In Minesweeper, when you click on a blank square, all the squares next to that blank, that are also blank, need to be uncovered. Those squares in turn need to find their neighbors and if they're blank, they need to be uncovered. And then those squares also need to find their neighbors and and then be uncovered, so on and so forth until all the blanks in a contiguous region are uncovered. If you'll note, the steps of the algorithm are repeated over and over again, each square needs to find its neighbors, and each of those neighbors need to find their neighbors, this is the recursive part of the algorithm. The base case is encountered when no more neighboring squares are found that are blank.

Here it makes the most sense to solve the problem with recursion. This was a problem I solved when I implemented a Minesweeper game in React. You can take a look here: ReactSweeper Context Class. Within the clearBlanks method in our context, is a getAllAdjacentBlanks method. It's not a clean method and can clearly use further refactoring, but the point is you can see how it has a base case, if indicesToBeCleared has no elements, and a recursive case otherwise where it calls itself passing in the new found blank squares.

The point is, where I can see a repeating pattern, I can usually find a solution with recursion, so long as there's a base case that causes the recursion to stop and then collapse back down to the value I'm looking for. In multiplication, that value is the product of two numbers. In factorial, it's the factorial of a number, and in getAdjacentSquare, it's an array of all the squares that need to be revealed when a blank is clicked.

Where you see this repeating pattern, is where you can start thinking about recursion. But be careful. Interation with loops and generators is usually the simpler and more performant solution and they don't run the risk of stack overflow errors (though they do run the risk of infinite looping.)

Automobiles and OOP, a SOLID understanding

Jonathan Kuhl — Wed, 08 May 2019 23:12:57 +0000

SOLID

SOLID is an acronym for five best practice principles in Object Oriented Programming. The purpose is to make OOP more reusable and maintainable and easier to understand.

The SOLID Principles are as follows:

Single Responsibility

A class does one thing and one thing well

Open-Closed

A class is open to extension but not to direct modification

Liskov Substitution

A super class can be replaced by a sub class without breaking the program

Interface Segregation

It is better to have small specific interfaces than one big one

Dependency Inversion

A class should depend on abstraction over concretion

That's a bit of a mouthful though so I'm going to extend my car analogy to talk about each principle in kind.

Single Responsibility

A car is made of many discrete parts. Brakes, wheels, engine, etc. I'm going to focus on the engine. Now, most people think that the engine's responsibility is to make the car go, but this isn't true.

The engine's responsibility is to spin the crankshaft. That's it. Making the car go is a combined effort of many different parts each that do one single thing. The engine however doesn't care about the brakes or the axles or the wheels. It's only job is to turn the crankshaft. In fact, you can even take the engine out of the car and put it in something else and the engine will do its job.

Every part in a car behaves this way. The brakes only care about applying friction to the wheels. The spark plugs only care about firing in the "combustion" phase of the piston.

Now this might be a limitation of mechanical engineering, creating a part that does multiple things at once is not easy, but in programming, it's very easy and even seductive. Why not make one master class?

Because it turns into a mess, that's why. If you have a single object that is concerned with multiple parts of the application, changing one thing here might break something else, somewhere else, in a less predictable manner. Perhaps the code is old and you've forgotten that this value here is doing double duty over there.

This is a principle that can be expanded beyond OOP, it's also a good principle for programming in general, especially in functional programming. A function should do one thing, and do it well.

But what does it mean to "do one thing?" After all, it's pointless to have a function or an object that literally only has one line of instruction. This is a question of design, based on your own judgement. It's up to you and your team to divide up the software into small discrete parts with distinct roles and create classes, objects and functions to perform them.

As an example, imagine an object responsible for connecting to your database. That's all it should do. It should not also do CRUD operations or expose the public API. It should connect to the database and manage that connection. That's it. Like a car's engine, you'd be able to decouple such an object from your software and use it elsewhere. If you start building REST methods and CRUD methods into it, it becomes more complex and less reusable.

Open-Close

The principle of Open-Close says that an object should not be modified, but merely extended. This is akin to inheritance. When Subaru or Ford builds a car, they extend upon the original concept of a car. (We'll touch upon this further when I talk about the Dependency Inversion principle.) We have a base idea of a car that no one wants to change, and for good reason. If Subaru "changed" the idea of a car, they'd produce a car we wouldn't be able to easily operate.

Now, the analogy here fails because our concept of a car is abstract, but pretending it was concrete, if you change the base class, then all the derived classes also break.

Once an object or a module is created, one should be able to write code that extends it, adding fields and properties as needed to the extension, but not to the base object itself. The base object instead keeps its internals encapsulated and only exposes what it needs to expose.

Liskov-Substitution

Liskov-Substitution states that supertypes can be substituted by subtypes without breaking the code. If I write code with a base class object, I should be able to replace that base class object with any of its subtypes and it still works. Inheritance is typically the method that allows this to happen.

Most people know how to drive a car. If you consider Ford or Subaru or Chevrolet to be subclasses of type Car, you can replace any car with any other car and still know how to operate it. Each car make and model has different properties, but they're the same enough, because they derive from a base class of Car, that they can be substituted without modifications.

Interface Segregation

It is better to have many small specific interfaces than one big one. A large general purpose interface, much like a large object, is unmaintainable and unwieldy. Instead, the software should be broken up into smaller components that do single simple things.

For example, the wipers in my car aren't dependent on some other system (other than the basic electronics) to be active or inactive first. They don't depend on the state of other parts.

This has a further use when I can add or remove interfaces as necessary. Think of a computer for example. One interface is a keyboard. It does one thing, it sends keyboard instructions to the motherboard. It doesn't depend on any other piece (not even the motherboard, as it can plug into other motherboards and possibly other pieces of hardware.) You can remove it without affecting the other parts of the computer.

This is a downside to laptops, especially Macs. You can't easily swap parts, the interface is one huge chunk, and Mac users don't have the ability to add new RAM or internal ROM.

Break the software down into independent parts and keep them separate from each other. Try to think in terms of "plug and play."

Dependency Inversion

The principle here is that a class should be based on abstraction, and not concrete implementation.

Again, we all have an idea of what a car is and how one is to be operated. The cars we drive, the concrete metal objects we drive, based on concrete schematics stored in the headquarters for the car companies, are based on this abstract idea. The exact details on how to implement a car are found in the schematics (the class) and constructed in the cars themselves (the instance objects.)

Java Servlets serve as a great example for object oriented programming. The hierarchy is as follows:

Servlet is an interface.
GenericServlet is an abstract class that implements Servlet
HttpServlet is a concrete class that implements GenericServlet.

We start at the abstract idea of what a servlet is. The interface lets us know what the classes need to implement. The abstract class will provide more details on what needs to be implemented by extending classes and will provide some behavior and properties that are already set. HttpServlet is a concrete class based on those two higher templates.

We know that HttpServlet implements init(), destroy() and service() because the interface at the top demands that it does. This is a top down system where the top lays out the behavior and state that the extending/implementing class needs to perform and the class at the bottom provides the implementation.

This is a best practice because the higher implementation details are, the more brittle the whole inheritance chain is. If I change something at the top, that effect can ripple downward and break everything beneath. Dependency inversion puts only a contract at the top, the derived objects decide for themselves what the implementation details are.

There's a basic idea of what a car is, a Subaru Outback is a specific concrete implementation of what a car is. A car is a vague definition with few details, a Subaru Outback is a specific definition with tangible details.

Conclusion

SOLID is a set of five principles to help a developer create software that is reusable, understandable and easier to maintain. Knowing and applying these principles will make you a better programmer over all.

Happy coding.

Making A Switch In CSS

Jonathan Kuhl — Sat, 30 Mar 2019 18:28:05 +0000

Let's switch it up!

For a recent project I thought I'd use Materialize CSS and after working with it, determined that, while it's a good library, it wasn't for my project. However, I really liked the switch element they designed so I decided to remake it myself in CSS.

Doing so required I go into areas in CSS I'd never gone before, namely, pseudoelements. By manipulating ::before and ::after, I can make a functional switch out of a checkbox.

Below is the final product. It's a switch that toggles from off to on, and turns grey and unusable when disabled.

Getting Started

We're going to begin with the humble checkbox and wrap it in a label, as we should so that when the user clicks on the label, it will toggle the checkbox

For accessibility purposes you should always use labels in conjunction with form elements.

To ensure our CSS doesn't affect other checkboxes on our site, we'll give the label a class, and modify that class and its descendents as we continue.

<label class="switch">
  Off
  <input type="checkbox">
  On
</label>

Let's set up the CSS:

.switch input[type="checkbox"] {

}

The first thing we need to do is get rid of the default checkbox styling. This took some research, but I found the solution, -webkit-appearance: none;. Our checkbox will now disappear.

Then we need to determine the placement of our knob (the red or blue circle) and the little slider the knob "travels" on (the grey rectangle in the back). These will be made with pseudo elements and they need to be moved relative to the position of the checkbox element.

That's a big hint, we will need to style the knob for absolute positioning, but absolute positioning, as a default will be based off the whole window. We'll want position: relative on our checkbox because it is the parent element for the ::before and ::after pseudo elements.

Finally, we'll want some spacing around our switch, once it appears, so the "on" and "off" text doesn't smash right next to it, and we can do this with margin.

.switch input[type="checkbox"] {
  -webkit-appearance: none;
  position: relative;
  margin: 0 1rem;
}

That sets up our checkbox. But right now, we have nothing to see, so lets make the slider

Mmmm Sliders

Nothing would please me more than a plate of mini burgers. But this a CSS article, not a local small town grill with American food, country music and goofy sh*t on the walls.

In this context, the slider is just the track our knob travels on. We'll make it out of the ::after pseudo element.

But first, what is the ::after element, and for that matter, the ::before element? Well, pseudo elements are elements that come with various tags that can handle various things. I know that's a very generic and unhelpful response, but there are a lot of them. Some, like ::first-line can modify the first line of a paragraph. There's an experimental one that lets you mess around with ::spell-check. The MDN has a lot of information on pseudo elements

::before and ::after are elements found on most HTML elements and they are considered children of their element. ::before is the first child and ::after is the last child. For our purposes, it won't matter which one is the first or last child. These can be used for a lot of purposes, even creating mustaches.

But we're going to keep it simple and use ::after to create our slider. It'll just be a regular rectangular grey box.

To target it, we simply need to append ::after to a new css rule

.switch input[type="checkbox"]::after {

}

There are five things we need to do to make it appear. First, pseudo elements need some content. Ours will be a simple empty string, so content: '' will suffice. Next, it needs to have display property. We'll make it block, because after some finagling, that's what I found works best here. And it needs a background color, and I picked grey.

Don't make the mistake I always do of setting the color property! color is for text! background is what we want to set!

Finally, we need height and width. As it should be set within a body of text, having it based on the root em (rem) seems the most logical. I set it to be 1 rem wide and 0.5 rem high.

.switch input[type="checkbox"]::after {
  content: '';
  display: block;
  width: 1rem;
  height: 0.5rem;
  background-color: grey;
}

A wild grey rectangle appears!

Styling the Knob

Now for the knobs. Here we have a knob that can be either right or left, but is always a circle, always has a shadow (to make it have some 3d effect) and always has the same content and size, so we want to write our CSS to be DRY, Don't Repeat Yourself.

We want to write a baseline for our ::before pseudo element.

.switch input[type="checkbox"]::before {

}

Again, we need to give it content, dimensions and a display property for it to show.

.switch input[type="checkbox"]::before {
  content: '';
  display: block;
  width: 1rem;
  height: 1rem;
}

That will make a square for us. We can't see it yet because there's no color though, so we'll want to make the rules for when the checkbox is checked and unchecked, since the color changes depending on that value.

Targeting a checked checkbox is simple, we can make a new rule that selects :checked. Targeting an unchecked box is a little more tricky because there's no :unchecked. We have to use the :not() pseudo selector, so we can make two new rules:

.switch input[type="checkbox"]:checked::before {
}

.switch input[type="checkbox"]:not(:checked)::before {
}

The order is important here. We want to target the ::before pseudo-element of a checked input element of type checkbox that is descendent of an element of the switch class. We don't want :checked after ::before because ::before doesn't have a checked attribute.

If it is checked, I want it to be blue and moved to the left 10 pixels. And if it is not checked, I want it to be red and moved to the right 10 pixels.

.switch input[type="checkbox"]:checked::before {
  left: 10px;
  background-color: blue;
}

.switch input[type="checkbox"]:not(:checked)::before {
  right: 10px;
  background-color: red;
}

Because we're modifying left and right attributes, our baseline needs to be set for position: absolute:

.switch input[type="checkbox"]::before {
  content: '';
  display: block;
  position: absolute;
  width: 1rem;
  height: 1rem;
}

Now we're almost there. The knob is a bit uncentered on the track, to fix it, I found that setting the top position -0.25 put it where I wanted it:

.switch input[type="checkbox"]::before {
  content: '';
  display: block;
  position: absolute;
  top: -0.25rem;
  width: 1rem;
  height: 1rem;
}

And finally, let's make it a circle with some shadow. Circles are easy, just give it a border radius of 50%. Shadows on the other hand, I never hand craft shadows, I found a good online tool for that. I like to use CSSMatic for this. They have a real-time box shadow tool that autogenerates the code for you. With the border radius and values I liked, the final CSS for the baseline selector looks like this:

.switch input[type="checkbox"]::before {
  content: '';
  display: block;
  position: absolute;
  top: -0.25rem;
  width: 1rem;
  height: 1rem;
  border-radius: 50%;
  -webkit-box-shadow: 2px 2px 5px 0px rgba(0,0,0,0.75);
  -moz-box-shadow: 2px 2px 5px 0px rgba(0,0,0,0.75);
  box-shadow: 2px 2px 5px 0px rgba(0,0,0,0.75);
}

And there you have it! A functional switch!

But wait, there's more!

No form element is complete without styles to target :disabled. Our users need a visual cue to know this element can't be used at the moment. For this, we can take our knob, our ::before element, and change the color if the checkbox is disabled:

.switch input[type="checkbox"]:disabled::before {
  background-color: darkgrey;
}

That will turn the knob grey if it is disabled. Try adding 'disabled' to the input tag to test it out.

And we're done here!

Here's the full code:

<label class="switch">
  Off
  <input type="checkbox">
  On
</label>

.switch input[type="checkbox"]:checked::before {
  left: 10px;
  background-color: blue;
}

.switch input[type="checkbox"]:not(:checked)::before {
  right: 10px;
  background-color: red;
}

.switch input[type="checkbox"]::before {
  content: '';
  display: block;
  position: absolute;
  top: -0.25rem;
  width: 1rem;
  height: 1rem;
  border-radius: 50%;
  -webkit-box-shadow: 2px 2px 5px 0px rgba(0,0,0,0.75);
  -moz-box-shadow: 2px 2px 5px 0px rgba(0,0,0,0.75);
  box-shadow: 2px 2px 5px 0px rgba(0,0,0,0.75);
}

.switch input[type="checkbox"]::after {
  content: '';
  display: block;
  width: 1rem;
  height: 0.5rem;
  background-color: grey;
}

.switch input[type="checkbox"] {
  -webkit-appearance: none;
  position: relative;
  margin: 0 1rem;
}

.switch input[type="checkbox"]:disabled::before {
  background-color: darkgrey;
}

This is a simple little switch that can add a little flavor to a site. It works great for binary situations, if the user wants this or the user wants that.

Feel free to use and modify this as you see fit. Try adjusting size or colors. Make it fancier, have fun with it. And if you see any way this can be done better in CSS, let me know.

Happy coding

Some Closure on Closures

Jonathan Kuhl — Wed, 06 Mar 2019 22:43:57 +0000

Introduction

Closures are a concept that take a while for many new JavaScript developers to get used to. It's one of the more abstract concepts of JavaScript. A closure exists when you have a function within a function that has access to the outer function's state.

What?

See, that's the definition I always see when someone defines a closure. But it's not as clear cut as to what it really means, so let me explain

Execution Context

When a function is called, JavaScript's engine creates what is called an execution context. This context contains all the state required for that function. In simple terms, state is simply the variables and their current values.

function foo() {
    const a = 3;
}

In the function foo() above, when you call foo() an execution context is created, the variable a is set to 3 and then the function ends, the context is destroyed and the variable is destroyed and the function returns undefined.

This is also how scope works. a is declared in the function and only exists within that function and any lower blocks that may appear in that function.

Any internal functions within foo() can access foo()'s state.

function foo() {
    const a = 3;
    function log() {
        console.log(a);
    }
    log();
}

But this is just basic scoping right? Well yes, in this example, but here's what's powerful about closures. If the outer function foo() is destroyed, the internal log() function, if it was brought out of the function, would still have access to foo()'s state.

function foo() {
    const a = 3;
    function log() {
        console.log(a);
    }
    return log;
}

const log = foo();
log();    // logs 3

// foo()() would also be acceptable, and would also log 3

The internal log() function still has foo()'s execution context, even though foo() was called, created, and destroyed.

To illustrate this further, let's make foo() take a parameter rather than a hard coded variable.

function foo(a) {
    function log() {
        console.log(a);
    }
    return log;
}

const log3 = foo(3);
const log4 = foo(4);

log3();    //logs a '3'
log4();    //logs a '4'

// alternatively
foo('hello')();    //logs 'hello'

Here you can see foo() is called 3 times with different values for a and the returned function still "remembers" the value of a from the execution context.

That's essentially what a closure is. It's an internal function that has access to the the outer function's state.

But Why?

Why would I need to use this? Well, there are a number of situations where its useful to utilize closures. Generators use closures. Event handlers use closures. Partial application of functions use closures. Closures are a major component of functional programming.

Here's how you can create a generator in JavaScript. This one is similar to (but simpler than) Python's range() object:

This is a handmade generator by the way, rather than the built in generator syntax that comes with JavaScript. For more information on the official JavaScript generators, check out the Mozilla Developer Network

function range(start, end, step=1) {
    let count = 0;
    return () => {
        count += 1;
        if(start < end) {
            return start += count !== 1 ? step : 0;
        } else {
            return false;
        }
    }
}

const r = range(1, 5);
console.log(r());    // logs 1
console.log(r());    // logs 2
console.log(r());    // logs 3
console.log(r());    // logs 4
console.log(r());    // logs 5
console.log(r());    // logs false

The ternary count !== 1 ? step : 0; is used to ensure the range includes the start value

The range() function returns an anonymous function that keeps track of the current state of the three parameters passed into the function. Each time you call r(), it will return the next iteration of that state, which is mutated by the expression start += step. Starting with this range object, it's not terribly difficult to use closures to rewrite many of the JavaScript array functions to functional functions that work on generators instead.

Here's what map() might look like.

function map(mapping) {
    return (range)=> ()=> {
        const value = range();
        if(value && value !== false) {
            return mapping(value);
        } else {
            return false;
        }
    }
}

const squares = map(x => x ** 2)(range(1,5));
console.log(squares());    //logs 1
console.log(squares());    //logs 4
console.log(squares());    //logs 9
console.log(squares());    //logs 16
console.log(squares());    //logs 25
console.log(squares());    //logs false

Note that with arrow notation ()=> ()=> {} is what a closure would look like.

Here you have a generator to create square numbers. Each time the function is called, it "remembers" the execution context of the outer function.

You can, of course, loop over the generators as well.

let s;
while(s = squares()) {
    console.log(s);
}

Don't get confused with the expression in the while loop. That = is an assignment operator, not an equality operator. = is a function under the hood however, and it will return the value of squares(), which is either a number, or false, and thus we can take advantage of truthy/falsy here.

But I felt writing it out was clearer.

You can see the code for these generators in action at Repl.it

Saving State

Closures also work when you need to save state. Imagine you have a large app that needs to connect to multiple mongo databases. I have an express back end and I need to export multiple connection functions to multiple javascript files. A closure can be a simple way of doing this:

//in a file called "database.js"
const mongoose = require('mongoose');

const user = process.env.MONGO_USER;
const password = process.env.MONGO_PW;
const db1URI = `mongodb+srv://${user}:${password}@cluster1.mongodb.net/database1?retryWrites=true`;
const db2URI = `mongodb+srv://${user}:${password}@cluster2.mongodb.net/database2?retryWrites=true`;
const db3URI = `mongodb+srv://${user}:${password}@cluster3.mongodb.net/database3?retryWrites=true`;

// wrap the connection in a closure so I can export it with the URI
function Connect(uri) {
    return function() {
        mongoose.connect(uri, {
            auth: {
                user,
                password
            },
            useNewUrlParser: true
        });

        const db = mongoose.connection;
        db.on('error', console.error.bind(console, 'connection error'));
        db.once('open', ()=> {
            console.log('\nSuccessfully connected to Mongo!\n');
        });
    }
}

const db1Connect = Connect(db1URI);
const db2Connect = Connect(db2URI);
const db3Connect = Connect(db3URI);

module.exports = {
    db1Connect,
    db2Connect,
    db3Connect
};

Then in various modules in your Express code you could say

const MongooseConnect = require('./database.js');
MongooseConnect.db1Connect();

//and in another file somewhere else
const MongooseConnect = require('./database.js');
MongooseConnect.db2Connect();

//etc

Here the Connect() method saves the URI parameter passed in in a closure so that later when you actually call it, it can connect to Mongo (through Mongoose) with that URI. This allows me to have one single function for connecting and one central location with all the connection strings gathered in one spot. I could simply export a function and pass the string as a parameter, but then I'd have to define a connection string in different files that use the Connect() function or have an object defined in another file with all the connection strings in one spot. With a closure, I can simply export the functions and have all my connection strings in one spot where I can maintain them with ease.

Events

Closures also work with asynchronous operations and events. In fact, when you pass a callback to a click handler, that is by definition a closure. addEventListener is a function, the handler you pass into it would be the closure.

Here's a piece of code I wrote when it finally clicked how a closure works for me:

function clicker() {
    let counter = 0;
    const myDiv = document.getElementById("mydiv");
    const btn = document.querySelector("button");
    btn.addEventListener('click', ()=> {
        myDiv.innerHTML = counter;
        counter++;
    });
}

clicker();

I had a need to have the event listener added to a DOM element within a function and I wrote the above to make sure the concept itself worked. It's a simple counter, you click on a button the number goes up. Hurray, I guess.

But the point is, the anonymous click event handler still has access to the counter variable and the myDiv element, even though the clicker() function will already have its execution context destroyed by the time the user clicks the button (unless he's got a super fast millisecond reaction speed I suppose.) Even though counter and myDiv are scoped to clicker(), the event handler can still access them.

Asynchronous functions and events work just fine with closures because that closure still has access to the state of the enclosing function even if there's some time between the destruction of the enclosing function and the calling of the closure. If you have some closure that calls some network API and it takes 250 milliseconds to get a response, then that's fine, the closure still has access to the enclosing state.

Summary

Closures are tricky to understand. Hopefully some of the examples above made it clearer how they work. Remember, a closure is simply an internal function that has access to the state of the function that it is contained in. Here's an idea to get a better handle of closures, use the range() function I provided above and try to make a toArray() method that gives an array for each value in the generator. Or try to make a filter() function or rework any of the other JavaScript Array methods to work on range(). I've made a few on my own and they'll all require you to use closures.

Thank you and happy coding.

Batman and Promises

Jonathan Kuhl — Tue, 29 Jan 2019 16:44:29 +0000

Alfred

Imagine you're the CEO of some business. Wayne Enterprises I suppose. Here you are putzing around in the Batcave trying to figure out what the Joker's going to do next, but you, Mr. Wayne, have a hankering for some caffeine. So you fetch Alfred and tell him, "get me a coffee."

So Alfred goes to get you a coffee. While he's out and about, you're still free to continue polishing the Batmobile and searching for information on the Joker on the Batcomputer and fixing the holes and tears in your Bat armor.

After a little while, Alfred returns.

Promises are Alfred. A Promise is a task JavaScript performs with an assurance that it will, at some point, return with some value. It might not be the value you want, but it will be some sort of value. Promises are asynchronous. Actions passed to a Promise are put on the event loop rather than the function stack, which allows the other functions in your code to continue executing while you await your promise.

Here's a basic Promise:

new Promise((resolve, reject) => {
    doTheThing((error, value)=> {
        if(error) {
            reject(new Error('something broke'));
        } else {
            resolve(value);
        }
    });
});

We have some function, doTheThing() that gets some value. What it is doesn't really matter. Maybe it's an API call or something. Either way, the basics work like this. If you get the value you want, you pass it to the resolve() function. If you don't get the value you want, you call reject() and pass it an error or some other value you'd want if the Promise returns an error.

Any object passed to resolve, is then passed to the callback function of any then() call. then() is fired immediately after resolve() and will perform the action you desire to have happen once your Promise is resolved. catch() works with reject(). catch() also takes a callback and the value passed into reject() is then passed into the callback catch() uses. If you have multiple promises and multiple then() methods chained onto it, catch() is a one stop shop for all errors that are thrown; you only ever need one catch().

So to rewrite this in terms of our Alfred example:

const coffee = new Promise((resolve, reject) => {
    getCoffee((error, coffee)=> {
        if(error) {
            reject(new Error('no coffee!');
        } else {
            resolve(coffee);
        }
    });
});
coffee.then((coffee) => drink(coffee))
    .catch((error) => console.error(error.msg));

Alfred comes back and says he has your favorite coffee! Your Promise is resolved and you can drink the coffee. Alfred comes back and tells you he failed to get coffee because the Joker blew up all the coffee shops. Your Promise has been rejected. You get mad, suit up and head out in the batmobile to handle this . . . error.

Sandwiches

After handling the Joker, you are hungry. You want a sandwich! But not just any sandwich. The Batman has a sophisticated taste after all. So you tell Alfred, that you want cheese from a specialty cheese shop, meat from your favorite deli, and fresh bread from your favorite baker.

Alfred now has to handle three promises at once.

This is where Promise.all() comes in. Promise.all() handles an array of promises and will not resolve until all the promises in the array are resolved. If any one of them are rejected, they are all rejected.

const sammich = Promise.all([getBread, getCheese, getMeat]);
sammich
    .then((nom) => eat(nom))
    .catch((error) => console.error(error.msg));

When Alfred returns, you either have all three parts to your sandwich, or you don't have a sandwich.

But why get the individual ingredients one at a time when there are so many delicious Gotham City sandwich shops to choose from? You decide you want a sandwich, but you can't decide between three different stores, so you'll just eat the first sandwich that is returned from you. You send Alfred, Robin, and Gordon out separately to get you a sandwich.

This is Promise.race(). Promise.race() takes an array of Promises and returns the first one to be resolved, skipping any that get rejected. Only if all of them are rejected, will Promise.race() be rejected.

const sammich = Promise.race([sandwich1, sandwich2, sandwich3]);
sammich
    .then((nom) => eat(nom))
    .catch((error) => console.error(error.msg));

Robin came back first, so you eat his sandwich.

Async/Await

But here's the thing, using .then and .catch get clunky. Can we get around this? You are after all, The Batman and your batcave could use a little cleaning up.

Async/Await offers some clean up. It allows for your flow control in your code to feel more natural. The way it works is simple, but it only works on Promise objects. If you mark a function as async and mark a line inside that function with await, execution of that function will halt on that line while waiting for that promise to be resolved or rejected. Meanwhile, all the other functions will keep executing. The execution of the async function is thrown into the event loop and will only be executed once a value is returned and the function stack is cleared.

While Alfred, Gordon and Robin are going about getting your sandwiches, you're free to tinker about the batcave and do whatever you want while you wait, so long as what you want to do doesn't require those sandwiches.

await is exactly what it sounds like, the execution must await the resolution or rejection of this promise. Any rejection is picked up by the catch block of a try/catch.

async function waitForCoffee() {
    let coffee;
    try {
        coffee = await getCoffee();
        coffee.drink();
    } catch(error) {
        console.error(error.msg);
    } finally {
        thank('Alfred').forServices();
    }
}

We're assuming getCoffee() returns a Promise in this example.

Here you have a more top to bottom flow of control with async/await. There's no other benefit to using async/await over .then()/.catch(), it isn't faster or necessarily more performant. It's just easier to read and manage.

Just be aware that async/await only works on Promises. If you try using it on something like the geolocation API, it won't work, unless you wrap those functions in Promises first.

That is Promises in a nutshell.

On Automobiles and OOP

Jonathan Kuhl — Fri, 18 Jan 2019 20:33:04 +0000

Introduction

Stand at any street corner and watch the traffic for a while. A Subaru Crosstrek. A Ford Escort. Now Dodge Ram. A Subaru WRX with a loud rumbling engine. A Yugo held together by duct tape and desperation.

All of these, are cars. They have the same basic structure. Four wheels, an engine, a steering wheel, runs on gasoline or diesel. Yet, they vary greatly in color, horsepower, shape, features, and even the type of gasoline they might use. Every busy street is a cacophony of different car shapes, yet most of the vehicles we see, everyone will agree, is a car. And yes, depending on how you define it, your Dodge Ram could be considered "a car."

This in turn is what Object Oriented Programming (OOP) is about. An object is a bundle of individual properties that is based on some basic template. Each individual car is a bundle of individual features based on some basic template. Of course, some templates are templates of templates. There is no "basic car", it is an abstract idea, a collection of properties and methods every derivative car must implement, but every derivative is free to implement as they desire within the confines of that abstraction. We have a general idea of what a car is, and then expanded into different types of cars. A Subaru Outback is an station wagon. A GMC Yukon is an SUV. A Ford Fusion is a sedan and no one really knows what a Honda Fit is. From these types, station wagon, SUV, sedan, etc, you can find even more specific ideas, like the vehicles I listed as an example. Ultimately, you get to an abstraction specific enough to build individual cars from.

Car
    Sports Utility Vehicle
        GMC Yukon
    Station Wagon
        Subaru Outback
    Sedan
        Ford Fusion

These are called classes.

Classes

If you walk into a Subaru factory, you won't find a group of crazed engineers trying to hobble together a car willy-nilly. That of course, would be ludicrous, inefficient and lead to the creation of cars that are not uniform.

Artistically, non-uniformity is typically valued, but in the programming world, it causes problems. Objects don't fit their required role. Testing is nearly impossible and therefore quality assurance goes right out the window. Mass production is slowed.

Instead what you find is a long procedural assembly line of workers (most of whom are now robots) following a precise set of instructions to build a car based on a previously drawn out schematic.

This schematic is precisely what a class is. Classes themselves are not the objects they create, but rather a template for creating objects. If I were to pull the schematics of a 2017 Subaru Outback, it tells me in detail where every nut and bolt goes and how every functionality works and is implemented.

Constructors

Of course, there are variations in how individual cars are created. While, for some reason, orange Subaru Crosstreks (I too enjoy driving pumpkins down the street!) seem to dominate the freeways, obviously, one has a lot of leeway in color and numerous other minor features.

The constructor sets properties and initializes them. It allows us to set the individual details for an individual instance of the object. Then, it creates the object.

Constructors, and initializers, come in many different flavors. And before I continue, there is a clear difference between a constructor and an initializer. A constructor creates the object in memory (the Subaru factory plops out a new Outback) and the initializer sets its properties (the new Outback gets painted with optional features plugged in.) Some languages do this at once, others do it separately.

// Java
class MyObject {
    String param;
    MyObject(String param) {
        this.param = param;
    }
}

// JavaScript
class MyObject {
    constructor(param) {
        this.param = param;
    }
}

# Python
class MyObject:
    self.__init__(self, param):
        self.param = param

Think of constructors like the assembly line at a Subaru factory. You start it up by telling the robots what colors and features you want (okay, it probably doesn't actually work like that in the real world factories but bear with me) and the robots then, based on the class template they're given, build the car with your desired parameters.

At the end of the line is a nice shiny Outback with all the customization you wanted, but it has enough Outback features that it is as much an Outback as any other Outback you encounter. Even the old blocky ones.

Interfaces and Abstract Classes

However, not every object needs to be constructed. As I said before, the basic car idea is not a concrete object, but an abstract idea. The basic car is just a list of features that every car must implement. If you don't implement these features, whatever your building is not a car. Maybe it has wheels and an engine, but it is not a car. If a semi comes out of the other end of your factory, it is not a car because it has too many wheels. If an M1 Abrams Main Battle Tank comes out of the other end, it's not a car because it has treads, instead of wheels, and the DOD would like to know why you're building military tanks.

An interface is a contract. It guarantees that whatever comes out the other end will be a car.

To drop the car analogy for a moment, imagine you have a function that takes an object as one of its parameters and within that function, it calls one of that object's methods.

class Person {
    String name;
    Person(String name) {
        this.name = name;
    }
    public void greet() {
        System.out.printf("%s says 'Hello'", this.name);
    }
}

// assume we're in class main
public static void personGreet(Person person) {
    person.greet();
}

public static void main(String ...args) {
    personGreet(new Person("Jim"));
}

In the above example, we have a method that takes a Person and calls its greet method. This works fine of course, but there's a problem. What if I have multiple person types, and inheritance is a model doesn't work to my favor? What if I have Employee and Dog, all of which might have a greeting, but maybe don't work as a subclass of Person? Employee might, but Dog wouldn't! Maybe the structure of my code is such that Employee works out better with composition rather than inheritance. We can ensure that both classes work in the personGreet() method with an interface:

interface Greetable {
    public void greet();
}

class Employee implements Greetable {
    // ...
    public void greet() {
        System.out.printf(
            "%s says 'Hello', I work for %s as %s", 
            this.name, this.job, this.jobTitle
        );
    }
}

class Dog implements Greetable {
    // ...
    public void greet() {
        System.out.printf("%s barks 'Arf Arf!', this.name);
    }
}

// and back to the Main class
public static void personGreet(Greetable greeter) {
    greeter.greet();
}

Now our greet class can take any object that implements Greetable because we can be confident that it implements the required methods.

It's also incredibly helpful with any modern IDE. If an IDE knows your variable implements Greetable, it will helpfully suggest methods in the Greetable interface, so you don't have to memorize how to spell them or in what order the method parameters might go.

Some languages like JavaScript don't have static typing and for those languages interfaces are meaningless. If I wanted to pass an object to the personGreet() method, there's nothing to ensure that the personGreet() has a greet method, except for me to actually program such a check. An interface is where statically typed languages shine. If you're a fan of JavaScript but also want static types, try Typescript.

In drivers ed, you were not taught how to drive a specific car. You were taught how to drive in a very generic fashion. We all understand that cars implement a specific interface. The steering wheel is on the left (unless your British), the accelerator is on the right and it makes it go. Flick the blinker up to single a right turn, and the blinker down to signal a left turn. Cars all implement the same interface. If you can drive one car, you can drive them all.

And any vehicles that require special licensing, they might implement the Car interface, but they also implement some other interfaces the user would need to be aware of. A semi might implement some of the same details as a car. A semi is operated in the same basic way after all, but would also implement some other interfaces, since it's size, weight, number of wheels would all affect its handling and make it a different object. In fact, it might be better, to take some ideas out of car (like basic driving) and move it up into a Vehicle interface.

Perhaps it would be better if car were an abstract class rather than an interface, that implements the Vehicle interface, but also has its own properties like hasFourWheels and other things that are unique to cars, but not to vehicles.

In Java you can see this progression from the Servlet interface to the GenericServlet abstract class to HttpServlet abstract class to your own implementation of Servlet that inherits from HttpServlet or GenericServlet.

Properties and Methods

Let's go back to that road I opened this article up with. We had all those cars driving by, including that god awful orange Subaru Crosstrek. (Why are they always orange?) While they all inherit from Vehicle and Car, they all look pretty unique. People have a broad choice in shape, color, performance, radio, cabin controls and so on and so forth. When you construct an object, it is a unique data structure stored in memory. You can have any number of them (until memory runs out of course) and they might have the same basic shape, yet they're all unique.

Now before I continue, a property is defined in different languages as different things. In JavaScript, they are properties. In Python and Ruby, they are attributes. In Java, they are fields. For clarity sake, when I say "property", it applies to all of these things.

A property is simply some state applied to an individual object. A car's color or its horsepower, for example.

A method is some behavior an individual object might perform. When you hit the gas in your car, you call the accelerate() method. And even though every object has the same accelerate() method, not every car will accelerate at once! Only the car calling its own accelerate() will start to accelerate and increase its speed property. If two cars accelerate at the same time, they only modify their own internal state. Me pressing the gas in my car, only makes my car go.

Static vs Member

When people talk about static methods and properties, they often say something obscure like "static methods belong to the class, while member methods belong to an object." Once you get a handle on OOP, that's not terribly difficult of a concept to grok. But for someone brand new to programming, it might be a bit confusing. After all, don't all methods and properties belong to the class? A new programmer might not yet realize that a class and an object are not the same. As I said earlier, a class is a schematic, an object is the concrete thing the schematic designs.

Anything marked as "static" is something meant to apply to the class as a whole, something that wouldn't make sense to apply to an individual object, nor make sense to separate from the class.

To explain it, I'll continue the car analogy. Imagine you take your car on a road trip. Because you're fabulously rich, you ferry your car across the Atlantic from the United States to Europe. When you get there, you realize Europeans, who like to keep things simple, use the metric system. Fortunately, your car came with a function that swaps the miles-per-gallon display to kilometers-per-liter. Such a formula is useful for any car, but it won't change if you're driving a Subaru WRX or a Ford Fusion or a clunky Yugo held together by duct tape and desperation. MPG to KPL is the same function no matter what you drive. Even if you drive a gas guzzler, the unit conversion doesn't change. So why make the method specific for individual cars? Make it static so that all cars can share it.

The MPG-to-KPL conversion doesn't belong in a car. Certainly an individual might build in a method to display such a conversion in its own, but the actual implementation of the mathematics doesn't belong in a car. It instead can just be stored as common knowledge to all automakers and drivers out there.

class Car {
    final static double MPG_TO_KPL = 0.425144;
    public static double mpgToKpl(double mpg) {
        return mpg * MPG_TO_KPL;
    }
}

class Outback extends Car {
    public void displayMetricFuelConsumption() {
        double fuelConsumption = Car.mpgToKpl(this.mpg);
        System.out.println("Current fuel consumption in kpl: " + fuelConsumption);
    }
}

As you can see, the individual object itself can call its own method that displays the converted unit, but the unit conversion itself is static and kept at the class level. Furthermore, Outback wouldn't have to extend Car for the static method to be available, any object can call it from the Car class.

Inheritance

At this point you should have a broad idea of what inheritance is. To put it all in one place, the idea of inheritance is that subtype inherits the properties and methods of its parents.

A station wagon is a Car, therefore it has four wheels and is meant to be used by the general population. A Car in turn is a Vehicle and therefore it has a steering wheel, accelerator and brake pedals, some sort of piston engine, and so on and so forth.

A Subaru Outback is a station wagon, therefore it is a car with a hatchback with extra space in the trunk. And because it is a station wagon, it is therefore a Car, and because it is a Car, it is therefore a Vehicle.

Polymorphism

But not every subtype will implement methods in the same way their parent does! A Subaru WRX and a Subaru Outback certainly have different acceleration methods! In any OOP language, children can override their parent's methods and properties. This is done through overriding and overloading, though not every language will support overloading. JavaScript, for example, does not.

An override is when we change the implementation, but keep the method signature the same. In the Subaru WRX, maybe within our acceleration method there's a turbocharge method, something you wouldn't typically find in an Outback.

An overload is when the method signature is the same but the arguments and their types are different. You can override a method multiple times so long as you overload it with different arguments and different argument types. But again, not every language supports this. JavaScript does not.

You can emulate overloading in JavaScript by using the typeof or instanceof keywords and programmatically determining what the arguments are and what the implementation does depending on what arguments are given, but you can't have multiple functions with the same name and different parameters.

You can in Java:

public static String add(String a, String b) {
  return a.concat(b);
}

public static int add(int a, int b) {
  return a + b;
}

Both methods have the same name, but different signatures. Overloading is simply changing the implementation depending on what the inputs are.

Application Programming Interface

Before I continue, I do want to take a brief moment to explain what an API (application programming interface) is. An API is the collection of public facing properties and methods a user can use.

Your car has an API. There's a port for it to take in gas. There's a pedal that makes it go and another that makes it stop. There's a wheel that allows me to steer. These things allow you to interface with the car and change its state and behavior in a controlled and predictable way.

The API of any object can be summed up as its public properties and methods that are meant to be used by the user.

Encapsulation

When I drive down the road, when my foot is on the brake or the gas, it affects the internal state of my car. I'm slowing down or speeding up. It does not affect the other cars around me. The internal state of my car is encapsulated. As the user, I don't need to know what the engine is doing, and neither does anyone around me. I just need to know what the public API is. When I interface with that API, I don't need to be aware of what is going on inside. If I hit the gas, I don't need to know specifically which pistons must rise and which ones must lower at any given moment; the engine handles that for me. And if I were allowed to go in and modify that while the engine is running, I could break something.

This is encapsulation. A class's internal state is only exposed to the outside world through specific methods explicitly designed for use by an outside user. A singleton for example, uses encapsulation to ensure there's only one instance of itself. The constructor is only accessible through a specific public method that ensures it can only be called once. Typically, it checks if the instance is created and either creates the instance, or returns a reference to that instance, but the constructor itself, set to private, cannot be called from the outside.

Abstraction

Now let's return to that driver's ed course again. Remember that you were not taught to drive a specific car, but a generic idea of a car. We know that any car you do drive will inherit from Car and Vehicle, so we know it will have things like an accelerator, a brake pedal, a steering wheel, turn signals, and everything else in more or less the same place and the same configuration (but maybe on the other side for you British types!)

It doesn't matter how those methods are implemented, but only that they are, and in a predictable manner. Abstraction is related to encapsulation, in that you don't know or care about the internals. What you do know, is that if you call a method, predictable behavior should occur. If I hit the gas, the car should move forward. If I hit the gas and the blinkers come on, that . . . that would be weird.

You know how to drive any car because you were given an abstract idea of what a car is and what its methods are. You know every car will have these methods in a similar API you can use. The actual implementation of the gas pedal or the turn signal or whatever is black boxed from you. If you want to accelerate, you just hit the gas. There's no need to understand how pressing that pedal causes gas to flow into your engine, which makes the pistons rise and fall and allows them to cycle through a system of intake, compression, combustion, and exhaust. Sure, that might be handy for maintenance, but you can just as easily drive a car without any clue what that big loud metal thing under the hood is actually doing.

Abstraction hides implementation details from where it is not necessary. It allows you to take that implementation and bundle it into something more meaningful and reusable. This reduces complexity on the user's end. Take for example JavaScript's library of Array methods.

const squares = [1,2,3].map(x => x**2);
//[1, 4, 9]

While JavaScript is an OOP language, it is based on a prototypal inheritance scheme rather than a classical one. That's something to keep in mind. With that said, most of what I've stated here applies to JavaScript as well, but perhaps not exactly.

Do I as the user care what map() does under the hood? No. All I care is the knowledge that it performs some function on every element. I don't care how. I don't want to implement a mapping function every time I want to change the elements of an array. Why not abstract it away into a method so I can reuse it as necessary?

That is abstraction.

Conclusion

Object Oriented Programming can be a bit confusing but I find it is best understood if you think about objects as literal everyday objects. Cars are mass produced objects that bear a similar basic shape even though there's an incredibly wide variety of types out there, from hulking SUVs to station wagons, to pick up trucks, to sedans and sportscars. If you think about how cars relate to each other in the real world, you can have a better understanding on how objects work in the programming world.

I hope this helped create a better understanding of what OOP is and what the basic concepts and terms involved in OOP are. I did not intend to really go into actual language implementation of OOP, but hopefully when you read about how different languages implement OOP, having some sort of analogy will help make the concepts clearer.

A Case Against Switches

Jonathan Kuhl — Sun, 11 Nov 2018 01:31:22 +0000

The Problem

Switches are ugly. They are bug prone. The default fallthrough behavior is begging for errors. I think Swift did the right thing and made fallthrough a keyword, rather than a default, but even then, I'd rather avoid them if I can. They just don't fit in with the rest of my code. The indentation is awkward and no one can seem to decide if the case statements are indented or not.

Python didn't even bother to implement them in the language.

I primarily work in JavaScript, so I'll be focusing on that language. However, any language with first class functions and some sort of key/value pair structure can avoid switches. Java, for example, can use maps and lambdas. But I'll be sticking with JavaScript.

The JavaScript Object

How do we avoid switches? Well, each case in a switch is essentially a key-value pair. You're matching a single key, the case, with a single value, an expression to be evaluated, or a set of instructions. Sound familiar? Boil it down to two key works, key and value and you have a basic JavaScript object. How do we use a JavaScript object in place of a switch?

Well let's start with an example. Let's pretend we have some code that displays an error message when a log in fails.

errorMessage(error) {
    const status = {
        '401': 'Please check your username and password',
        '404': 'Account not found, have you registered?',
        '500': 'Something went wrong with the server, please try again later',
        'Failed to fetch': 'Servers are currently down, please try again later'
    }
    return status[error.status];
}

Here we have code that behaves like a switch. We have 4 different error messages that can get thrown, a 401 if verification fails, a 404 if the user isn't found, a 500 if something broke, or a Failed to fetch if the server is down. All we have to do is a very basic look up on an object and that's it. No fall through, no jarring switch structure. Just a basic JavaScript object.

But what if I wanted a default case? Well that's simple too, we just need to check if the value is in the object itself. There are a number of ways to do this, but I'll just check if the property exists by checking for undefined:

errorMessage(error) {
    const status = {
        '401': 'Please check your username and password',
        '404': 'Account not found, have you registered?',
        '500': 'Something went wrong with the server, please try again later',
        'Failed to fetch': 'Servers are currently down, please try again later',
        default: 'Something borked, sorry!'
    }
    if(!status[error.status]) {
        return status['default'];
    }
    return status[error.status];
}

Current JavaScript is also fairly flexible. If I wanted to use numbers rather than strings for object keys, I can do that. JavaScript will, under the hood, turn them into strings. Therefore the following is also valid JavaScript:

const object = {
    1: 'one',
    2: 'two',
    3: 'three'
}

object[1]; // 'one'

Of course, you can't use dot notation on this object, object.1 is invalid, but if we're simply using this object as a switch, then it doesn't matter. With bracket notation, dot notation isn't mandatory anyways. But what's important here is that we can recreate switch behavior with both strings and numbers. Now you could use true and false as strings for keys if you wanted to make a boolean, but I argue a switch is overkill for a boolean anyways.

Functions?

However, when we're using switch, we're often doing more than grabbing strings and numbers, we might also be holding functions. Thankfully, JavaScript is a language that treats functions as first class citizens. Functions can be passed around like any other object, and of course, can be the values of properties in our objects.

Here arrow functions truly shine, though if you need to preserve this, you'll have to reach for Function.prototype.bind(), or use the old school syntax for JavaScript anonymous functions,function () { .... Function shorthand in JavaScript objects also preserve the context of this and in that case, the name of the function, becomes the key, and the instruction block becomes its value.

const greet = {
    sayHello1: function() { return 'Hello' },
    sayHello2() { return 'Hello' },
    sayHello3: ()=> { 'Hello' }
}

In this example, greet.sayHello1() and greet.sayHello2() do exactly the same thing. greet.sayHello3() is slightly different because it is an arrow function and therefore the this keyword is lost. However since the function isn't using this, all three are exactly the same in this particular scenario. If you needed this for an arrow function, you can do greet.sayHello3.bind(greet).

Imagine we have a text based RPG. You play a wizard who has a number of spells he can cast. The user types in the spell he wants and the wizard casts it. You could use a switch to determine which spell to cast, or use an object:

function castSpell(spellname) {
    const spellbook = {
        fireball: ()=> 'Wizard casts Fireball!',
        iceshard: ()=> 'Wizard casts Ice Shard!',
        arcanemissiles: ()=> 'Wizard casts Arcane Missiles',
        polymorph: ()=> 'Wizard casts Polymorph!',
        default: ()=> 'Wizard doesn\'t know that spell.'
    }
    if(!spellbook[spellname]) {
        return spellbook['default']();
    }
    return spellbook[spellname]();
}

So what the function does is, you pass in a spell name, and it uses the spellname to match a value in the spellbook. That value is a function, so by using () after grabbing the value will call that function.

I'm using bracket notation for the default method here for consistency. spellbook.default() would also be valid.

Here we can call functions the same way we would in a switch. You can abstract away all the code that would be your case statements and shove them in an object methods and simply call them via bracket notation.

This does have some trade offs, as it's harder to tell what spellbook[spellname]() is doing than case 'fireball': return fireball(); but the code is more elegant, there are fewer levels of indentation, and no threat of fallthrough.

But I Want Fallthrough!

Oh. Well then. Obtaining fallthrough behavior in an object is more difficult and there's no one way to do it. There could be an argument here where switch might actually be a better construct to use. And if so, then use switch. But understanding that objects have a number methods on them, there are other solutions as well. With Object.values(), Object.keys() and Object.entries(), you can get all of your key/value pairs into arrays and then run them through any number of array functions. This can be done to achieve fallthrough.

Imagine we have an object with a bunch of functions and, given a number, we need to call all the functions upto, and not including that number. This is one case where a switch fallback is useful, but this is also easily done with an object. Here's an example:

function callFns(number) {
    const object = {
        1: ()=> console.log('one'),
        2: ()=> console.log('two'),
        3: ()=> console.log('three'),
        4: ()=> console.log('four'),
        5: ()=> console.log('five')
    }

    Object.keys(object).forEach(key => {
        if(key >= number) {
            object[key]();
        }
    });
}

Call callFns(3) and it will log 'three', 'four', and 'five' to the console. This would simulate using switch(3) { with no break or return in any cases. By combining Object and Array methods, we can simulate a fallthrough for our situation. But again, this may be a case where a switch might be the better construct. After all, the primary cause of bugs in a switch is the fallthrough feature. However, by using an Object, you get access to a number of methods that can make an object more flexible than a switch statement. By getting an array of your object's entries, you get access to filter, reduce, some, every, as well as iteration methods like map and forEach, and structures like for of.

In Summary

Objects in JavaScript give you a simple alternative to the switch statement. Objects are flexible and less bug prone than switch statements and they aren't as jarring in your code as switch statements. If you don't want fallthrough, using an object in place of a switch is a better option. If you do want fallthrough, it can be achieved through Object and Array methods, but a regular switch might be a better option.

All in all, your style of code is up to you, but I suggest being like Python and throwing the switch out entirely.

Happy Coding.