DEV Community: Elle Hallal 👩🏽‍💻

What Are Interfaces, Abstract and Concrete Classes?

Elle Hallal 👩🏽‍💻 — Wed, 29 May 2019 00:00:00 +0000

Originally posted at ellehallal.dev👩🏽‍💻

What Are Interfaces?

Interfaces are used to standardise the way a particular set of classes are used. An interface specifies common behaviour, which needs to be implemented by the classes. It can be described as a blueprint of a class.

An interface decouples what needs to be implemented from how it is implemented. It is not concerned with how the behaviour is implemented.

Every method declared in an interface will need to be included in a class which implements it. The body of methods in an interface are empty, and therefore classes implementing it need to override the methods to add a method body.

An interface contains methods and constants, which are automatically public andabstract. As a result, including these keywords is optional.

For example, here’s the play method in the Pet interface. It has an empty method body:

public interface Pet {
  void play();
}

Interfaces have an is-a relationship. In the example below where Cat is implementing Pet, Cat is-a Pet:

public class Cat implements Pet {
    private String name;

    public Cat(String name) {
        this.name = name;
    }

    @Override
    public void play() {
        System.*out*.println(name + " is playing with human");
    }
}

Cat has overridden the play method in the Pet interface, with its own playmethod.

Below is another example, using an interface called MediaPlayer. The classes MusicPlayer and VideoPlayer implement the interface.

Interface - MediaPlayer

public interface MediaPlayer {
    void play();
    void stop();
    void currentlyPlaying();
}

Class - MusicPlayer

public class MusicPlayer implements MediaPlayer{
    private String songName;
    private boolean isPlaying = false;

    public MusicPlayer(String songName) {
        this.songName = songName
    }

    @Override
    public void play() {
        isPlaying = true;
    }

    @Override
    public void stop() {
        isPlaying = false;
    }

    @Override
    public void currentlyPlaying() {
        if (isPlaying) {
            System.out.println(songName + " is currently playing.");
        }
        else {
            System.out.println("Nothing is playing.");
        }
    }
}

Class - VideoPlayer

public class VideoPlayer implements MediaPlayer{
    private String videoName;
    private boolean isPlaying = false;

    public VideoPlayer(String videoName) {
        this.videoName = videoName
    }

    @Override
    public void play() {
        System.out.println("Playing...");
        isPlaying = true;
    }

    @Override
    public void stop() {
        System.out.println("Stopped");
        isPlaying = false;
    }

    @Override
    public void currentlyPlaying() {
        if (isPlaying) {
            System.out.println(videoName + " is currently playing.");
        }
        else {
            System.out.println(videoName + "is not playing. Press play");
        }
    }
}

MusicPlayer and VideoPlayer have implemented the play, stop, and currentlyPlaying methods declared in MediaPlayer, by overriding them.

Other key points

An interface cannot be instantiated
A single class can implement more than one interface
Multiple classes can implement the same interface
An interface can extend another interface
Another example of an interface is List in Java.

What Are Abstract Classes?

The purpose of an abstract class is to provide a common definition of a base class that multiple derived classes can share.

It should be used when a class contains some implementation code, which all subclasses can use, such as a method with a body. Like interfaces, an abstract class can also be referred to as a blueprint.

An abstract class contains at least one abstract method. An abstract method is a method with an empty body, just like the methods in an interface.

The difference is in an abstract class, the abstract keyword needs to be used when declaring the class and abstract methods. Here’s an example:

public abstract class Animal {
    public abstract void speak();
}

In addition, methods within this class type can have any visibility, where as in an interface, methods are public only.

Abstract classes can also contain non-abstract methods, meaning the method body is defined. For example, here’s the abstract class, Animal , with the non-abstract method age:

public abstract class Animal {
    public abstract void speak();

    public void age(int age) {
        System.out.println("I am " + age + " years old");
    }
}

Abstract classes cannot be instantiated, and classes which extend from it need to override the abstract methods to provide implementation. Below is an example of a class which extends from the Animal class, overriding the abstract method speak:

public class Dog extends Animal {

    @Override
    public void speak() {
        System.*out*.println("Woof!");
    }
}

An abstract class can implement an interface. In addition, a subclass of an abstract class usually provides implementations of all abstract methods from the parent class. If not, the subclass must also be declared as abstract.

What Are Concrete Classes?

A concrete class implements all of its inherited methods and state from an interface and/or an abstract class. Unlike an interface or abstract class, a concrete class can be instantiated.

It demonstrates the implementation of a blueprint. Any abstract methods are overridden, to include a method body.

A concrete class can implement multiple interfaces, but can only inherit from one parent class.

In the example below, the Dog class inherits its methods from the interface, Pet, and the abstract class, Animal.

Another example of a concrete class is an ArrayList in Java. It implements the methods in the List interface. It also extends from the AbstractList class. In addition, it implements other interfaces, such as Iterable and Cloneable.

What Is The Liskov Substitution Principle?

Elle Hallal 👩🏽‍💻 — Fri, 17 May 2019 00:00:00 +0000

Originally posted at ellehallal.dev👩🏽‍💻

The Principle Definition

Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T.

That’s great, but what does it mean 🤷🏽‍♀️? In simpler terms, a child class should be able to substitute a parent class, without any unexpected behaviour. It ensures inheritance is being used correctly.

An example of adhering to the Liskov Substitution Principle

Below is the class Animal. When the speak method is called, a string is expected to be returned. The method does not have any parameters.

class Animal
    def speak
    ""
    end
end

Below are subclasses Cat and Dog. Both inherit from Animal and have a speak method.

class Cat < Animal
    def speak
    "Meow!"
    end
end

class Dog < Animal
    def speak
    "Woof!"
    end
end


cat = Cat.new
dog = Dog.new

cat.speak  # "Meow!"
dog.speak  # "Woof!"

Although calling the speak method on Cat returns 'Meow!' and 'Woof!' for Dog, a string is returned in both cases. In addition, no arguments are required. As a result, instances of these subclasses can be substituted where an instance of Animal is used.

Violation of the Liskov Substitution Principle

Below is the class Jellyfish, which is a subclass of Animal. Its speak method has a parameter name and returns a string.

Although this method returns a string, it needs a name as an argument when called. As the parent class’ speak method doesn’t require a name argument, an instance of the Animal class cannot be substituted with an instance of the Jellyfish class.

class Jellyfish < Animal
    def speak(name)
    "#{name} cannot speak"
    end
end

jellyfish = Jellyfish.new
jellyfish.speak("Jelly")  # "Jelly cannot speak"

In addition, if the speak method of a subclass returned anything other than a string, this would also violate the principle.

In conclusion

To adhere to the Liskov Substitute Principle, a child class should be able to substitute a parent class, without any unexpected behaviour. This is to ensure inheritance is being used correctly.

Helpful resources

What Is The Dependency Inversion Principle?

Elle Hallal 👩🏽‍💻 — Tue, 30 Apr 2019 00:00:00 +0000

Originally posted at ellehallal.dev👩🏽‍💻

This is a quick blog on my understanding of the dependency inversion principle. There are still elements I am unsure about, so please feel free to leave feedback.

What is the Dependency Inversion Principle?

High-level modules should not depend on low-level modules. Both should depend on abstractions.Abstractions should not depend on details. Details should depend on abstractions.

— Robert C. Martin

That’s great, but what does it mean? 🤷🏽‍♀️ I’ll demonstrate my understanding by using a class in my Tic Tac Toe application as an example.

Dependency Inversion in Tic Tac Toe

In the application, there’s a class called GameFactory. The purpose of GameFactory is to create an instance of the Game class with the specified players and a board.

Here’s a condensed version of the class:

class GameFactory
    def initialize(player_factory)
    @player_factory = player_factory
    end

    def new_game(squares)
    board = Board.new(squares)
    player1 = @player_factory.create_player('x', 1)
    player2 = @player_factory.create_player('o', 2)
    Game.new(board, player1, player2)
    end
end

In the new_game method, new instances of the Board and Game classes are created within it. However, this violates the Dependency Inversion Principle.

What’s wrong with it?

The high-level class GameFactory is dependent on the low level classes Board and Game. As a result, they are tightly coupled. A change in a low-level class will affect the high-level class.

If the name of the Board or Game class was changed, the new_game method within GameFactory wouldn’t work. As a result, it would need to be amended to accommodate the renamed classes.

If sub classes of Board and Game were to be used to create a new game, (for example, BestBoard and FunGame) the new_game method would need to be changed again to accommodate this.

A method to resolve the above issues is to pass the classes into GameFactory's constructor:

class GameFactory
    def initialize(player_factory, board, game)
    @player_factory = player_factory
    @board = board
    @game = game
    end

    def new_game(squares)
    board = @board.new(squares)
    player1 = @player_factory.create_player('x', 1)
    player2 = @player_factory.create_player('o', 2)
    @game.new(board, player1, player2)
    end
end

Whatever is passed in as board and game during initialisation, becomes @board and @game within GameFactory.

If the names of the Board and Game classes were to change, initialising GameFactory with the renamed classes would not affect GameFactory.

If subclasses of Board and Game (for example, BestBoard and FunGame) were used to initialise an instance of GameFactory, this would not affect how new_game functions.

In conclusion, my understanding is initialising a specific class, or classes within another results in tight coupling. Being able to inject the classes via the constructor, helps to make the classes loosely coupled.

Resources

Dependency Inversion Principle in Ruby SOLID Principles #5 - Dependency Inversion Principle

Creating An Unbeatable Computer Player Using Minimax

Elle Hallal 👩🏽‍💻 — Fri, 26 Apr 2019 00:00:00 +0000

Originally posted at ellehallal.dev👩🏽‍💻

This week, I have been working on adding an unbeatable computer (UC) player to my Ruby Tic Tac Toe game.

In this blog, I will share my understanding of recursion and minimax, and my first attempt at using it to create an unbeatable computer player. In order to implement a UC Player I needed to implement the MiniMax algorithm, which also meant I needed to use recursion.

The computer player

The beatable computer player

Before working towards making it unbeatable, the computer player selected a move without a strategy. It simply picked an available space on the Tic Tac Toe board at random.

The unbeatable computer (UC) player

The UC player should know the available squares on the board, assess all of the possible outcomes and as a result, choose the best move.

What is considered to be the best move?

The UC player’s aim is to win. If this is not possible, the next best outcome for the UC is for the game to be a tie. The opponent winning the game is not an option. A move should be selected to prevent an opponent from winning, subsequently resulting in a win or a tie for the UC player.

Recursive functions and Minimax

What is a recursive function?

My understanding of a recursive function is a function which calls itself, until a certain condition is met. It consists of a base case, and a recursive case.

Base case: when triggered, this stops the recursive function.
Recursive case: The recursive function calls itself again, with a slight variation from the previous function call. The recursive case occurs when the base case is not triggered.

What is the minimax algorithm?

My understanding is:

it’s an algorithm which uses recursion
the aim is to maximise the outcome for active player and conversely minimise the outcome for the other player
it is used to get the optimum move for a player in a game
it plays out all of the possible outcomes, using the current player and opponent mark
each outcome of the game is given a score, depending on whether the current player wins, an opponent wins, or the game is a tie.
the selected move should minimise the points the opponent can obtain.

In the context of a Tic Tac Toe game:

The maximising player is the UC player, and the minimising player is the opponent.
The base case is triggered when either player has a winning line or the board is full (a tie).
If the base case is not triggered, the recursive function will continue where the UC player’s mark and the opponent’s mark will keep being added to the available squares on a board
When a mark is added to the board, this means the recursive function has been called again.
When a player has won, or the game is a tie, the initial square that was played is given a score.
The UC player selects the best move where the opponent’s score is minimised.

How is an outcome scored?

If the game is a tie, the outcome is scored as 0. The maximum points a winning player can obtain is 10 (or -10 in the case of an opponent).

As a mentioned above, when a mark is added to the board, the recursive function is being called again. My understanding is by keeping track of the depth (how many times the recursive function has been called), this helps to assess the outcome of the game. The aim is to win in the fewest moves. Therefore a win in 1 move should have a higher score than a win in 3 moves

As a mark is added to the board (another recursive function call, increase in depth by 1), the depth is subtracted from the player’s maximum score.

For example, here’s a scenario:

The UC player is looking for the best move and tries out position 3
After the recursive function was called 3 times (depth = 3), the UC obtained a winning line

  maximum_score = 10
  depth = 3
  score = maximum_score - depth
  #score = 7

A Visual Example Of The UC Player Using Minimax

Expanding on the above, the example below presents a scenario where the UC player has three available squares it can choose from (3, 4, and 9). It demonstrates all of possible outcomes being played.

The UC player (x) is the maximising player, and the opponent (o) is the minimising player. I’ll explain all of the possible outcomes in more detail below.

The UC playing position 3

The image above demonstrates the following:

UC plays position 3 (depth 1)
Opponent plays position 4 (depth 2)
UC plays position 9 (depth 3)

The outcome is a winning line for the UC, after a total of 3 positions have been played.

The UC has won, so the maximum score is 7. Remember the maximum points the UC can get is 10, and the depth is subtracted from this.

To the right of the image:

UC plays position 3 (depth 1)
Opponent plays position 9 (depth 2)
UC plays position 4 (depth 3)

The outcome is tie, neither the UC or the opponent has a winning line. The minimum score is 0.

In conclusion, for position 3:

Maximum score = 7 (10–3)
Minimum score = 0 (tie)

The UC playing position 4

In the above diagram, the UC plays position 4. When doing this, both outcomes result in the UC not winning, and the opponent wins in one.

In conclusion, for position 4:

Maximum score = 0 (tie)
Minimum score = -8 ( -(10–2))

The UC playing position 9

The maximum score is 7 , as the UC can win in one of the outcomes at depth 3.

However, the minimum score is -8 , because the opponent wins in the other outcome at depth 2.

Although the UC can win by choosing position 9, the opponent can win on the next move.

In conclusion, for position 9:

Maximum score = 7 (10–3)
Minimum score = -8 ( -(10–2))

Using the scores to select a best move

My understanding is the UC player’s aim is to ensure the opponent obtains the minimum amount of points possible. The higher the opponent’s points, the higher its chance of winning.

Therefore, the best move is square 3 🎉 with the maximum score of 0 for the opponent (minimising player). This position results in either a win or tie for the UC player. The opponent has no chance of winning.

Making a beatable computer player unbeatable

In theory, the above sounds great but how can it be implemented to create an unbeatable computer player? In all honesty, I found translating the above into code extremely difficult.

There are many examples, blogs and videos demonstrating numerous ways to create an unbeatable computer player using minimax. You can find the resources I found helpful at the bottom of this blog post. In this explanation, I’ll try to explain each part of the function.

Before I begin, here is the Minimax class I created. It contains the find_best_move recursive function, which the unbeatable player will use.

The reason for choose_move

To ensure the instance of the board object being used within the game isn’t modified, a new instance of the board is created using the copy_board method. You can see the Board class here.

The purpose of find_best_move’s parameters

def find_best_move(board, depth=0, current_player, opponent)

board is needed in order to:

get all of the squares, consisting of unavailable (taken) and available squares on the board
check if a player has a winning line on the board, or if the board is full (tie)
reset the square was modified, with a player’s mark

depth:

to keep a track of how many times the recursive function was called

current_player:

the mark of the player whose turn it is to play a move

opponent:

the current_player's opponent

best_score and available_squares

best_score = {}
available_squares = board.available_squares

best_score:

to keep track of the scores for positions
When all of the available squares have been evaluated, best_score will contain the scores, with the available square as the key. For example: {3=>-8, 9=>0}

available_squares:

contains the available squares on the current board as an array

The base case for find_best_move

As mentioned previously, in a recursive function, there should be a base case, which will stop the function if it is triggered. Here it is:

return score_move(board, depth, current_player, opponent) if
  board.stop_playing?(current_player, opponent)

If the game is a tie, or either player has won, the game is over. As a result, the recursion should stop. board.stop_playing? returns true if this is the case.

The outcome of playing the initial square should then be scored and returned, to be added to the best_score hash.

A separate method score_move returns the score depending on the outcome.

def score_move(board, depth, current_player, opponent)
  if board.winning_line?(current_player)
    10 - depth
  elsif board.winning_line?(opponent)
    depth - 10
  elsif board.complete?
    0
  end
end

Recursive case: Iterating through the available squares

Iterate through the available squares on the board
Play the current_player’s mark in the selected square
In the best_score hash, set the key as the square, and the value to the outcome score.
This is where the recursive function is called again, with slight variation. board now has a mark in a previously available space, depth has increased by 1. The current_player and opponent switch.
board.reset_square removes the mark from the available square

Why is the return value of the recursive function multiplied by-1? 🤷🏽‍♀️

This is something I’m yet to grasp, but here’s a quote from a blog post, explaining the reason:

“Multiplying the return value by -1 will ensure you get either [a positive or negative score] depending on who is last to move.If the game is won on any odd move (1,3,5,7,9), the result will be [positive], which means the current player has won the game.If the game is won on any even move (2,4,6,8), the score will be [negative], which means the opponent would have won the game.”

Recursive case: Evaluating the move

evaluate_move(depth, best_score)

The last part of the find_best_move function is to evaluate the move. My understanding is if the depth is not zero, meaning the recursive function has not returned to the first function call, then return the score.

If the depth is zero, the best move is to be returned as the UC’s player’s move.

def max_best_move(scores)
  scores.max_by { |key, value| value }[0]
end

def max_best_score(scores)
  scores.max_by { |key, value| value }[1]
end

def evaluate_move(depth, scores)
  depth.zero? ? max_best_move(scores) : max_best_score(scores)
end

For example, position 9 was played and the score for the outcome was 0 (a tie). If depth = 1 the score needs to be returned. Remember the best_score hash that’s in the initial recursive function at depth 0? Currently it looks like this:

best_score = {3=-8, 9=> }

It needs the value (0) to match the key (9), to complete the hash. As a result of calling evaluate_move, the score will be returned, and the best_move hash becomes:

best_score = {3=-8, 9=>0}

When depth = 0, the values (scores) of each key (available square) in the hash can be evaluated with evaluate_move. The key with the highest value is returned. In this example, the best move is 9.

In conclusion, this is my understanding of recursion, and using minimax to date. There are still some elements I am unsure about. As my understanding of minimax improves, the way the unbeatable player has been created is likely to change.

You can find the repository for my version of Tic Tac Toe, in Ruby here: https://github.com/ellehallal/ruby-tic-tac-toe

Helpful Resources

Testing Output With RSpec

Elle Hallal 👩🏽‍💻 — Tue, 09 Apr 2019 00:00:00 +0000

Originally posted at ellehallal.dev👩🏽‍💻

This is a quick blog on testing output with RSpec. Currently, I am working on a Tic Tac Toe game in Ruby, where a user can play against a computer.

Previous test attempts

I’ve experienced issues testing a loop in the game, where it keeps requesting moves from players until the board is full or a player has won.

def main_game
  play_move until @game.over?
  end_of_game
end

One attempt at testing this was to spy on the play_move and end_of_game methods. This worked fine if a full board was provided.

However, this was proving difficult to test when an incomplete board was present. Despite simulating user input, the test would hang at this stage. The same issue occurred when using object doubles.

Testing output

One of my mentors suggested testing the output of the end_of_game method. The end_of_game method prints the Tic Tac Toe board and the outcome of the game.

it 'plays a game that ends with a winning player' do

  expect { controller.main_game }
  .to output("""

  1 | x | x
----------------
  o | o | x
----------------
  x | o | o
The current player is x
Choose a position from 1-9:

  x | x | x
----------------
  o | o | x
----------------
  x | o | o
x is the winner!""")
  .to_stdout

The multi-lines and alignment was also proving difficult to get right for the expected output. The key element that needed to be tested was the outcome of the game, which was the last line of the output: 'x is the winner!'

StringIO

StringIO is a ‘string-based replacement for an IO object. It acts same as a file, but it’s kept in memory as a String’.

The idea is to catch the stream of output and redirect it. To check the last line of the output was correct, my mentor suggested trying the following:

it 'plays a game that ends with a winning player' do
  controller = controller_setup([1, 'x', 'x', 4, 'o', 'x', 'x', 8,     'o'])
  allow($stdin).to receive(:gets).and_return('8', '4', '1')
  $stdout = *StringIO*.new

  controller.main_game
  output = $stdout.string.split("\n")

  expect(output.last).to eq('x is the winner!')
end

In this test:

A new instance of the controller class is created, with an incomplete board
The input is simulated to play the three remaining positions on the board
The standard output $stdin is redirected to a new instance of StringIO
The main_game method is called to play and complete the game
The output is then saved to the variable output, converted to a string, and split at the points where there is a new line to create an array of strings
The last item in the array is expected to be 'x is the winner!'

I’ll continue to use this method when testing large blocks of text with multiple lines. It’s significantly simpler than trying to align multi-line outputs in a test.

Resources

What Is The Red Green Refactor Cycle

Elle Hallal 👩🏽‍💻 — Fri, 29 Mar 2019 00:00:00 +0000

Originally posted at ellehallal.dev👩🏽‍💻

This week, I have continued creating a human vs. human Tic Tac Toe game in Ruby, using Test Driven Development. I have also been trying to get familiar with a number of principles and rules, such as SOLID principles and the Four Rules of Simple Design.

When creating Tic Tac Toe, Test Driven Development is helping me to break down the game into small chunks. I still have a way to go, but the red, green refactor cycle is helping me to write cleaner code.

Red, Green, Refactor cycle

Red

The red stage means that a test should be written and it should fail. This means not writing any code related to the test yet. In addition, it’s important to run the test to ensure it fails. Here’s an example of a test in my Tic Tac Toe game:

it 'returns false if there are available spaces on the board' do
  board = Board.new([1, 2, 3, 'x', 5, 6, 7, 8, 9])
  expect(board.complete?).to be false
end

Green

The green stage means code should be written to pass the test. At this stage, the code doesn’t need to be the cleanest, just enough to make the test pass.

The simplest way of passing the above test would be to create a method namedcomplete?, which simply returns false. Here’s my initial attempt, which passed the test:

def complete?
  available_squares = @squares.count { |square| square.is_a? Integer }
  available_squares == 0
end

Refactor

The refactor stage refers to writing a cleaner version of the code and still pass the test. In Sandi Metz’s presentation on SOLID Object-Oriented Design, there are a number of factors to consider when refactoring:

Is it DRY?
Does it have a single responsibility?
Does everything in it change at the same rate?
Does it depend on things that change less often that it does?

Looking at the method above, it appears to be DRY. However, it does have more than one responsibility.

Counting the amount of available squares
Returning true or false depending on the amount of available squares

My understanding is there should be two separate methods. With this in mind, another test was created to test a method counting the amount of available squares. The related code in complete? was extracted and added to the new method:

//test
it 'returns the amount of available squares' do
  board = Board.new(['x', 2, 'o', 4, 5, 6, 7, 8, 9])
  expect(board.available_squares).to eq(7)
end

//method
def available_squares
  @squares.count { |square| square.is_a? Integer }
end

The refactored complete? method is now doing one thing: returning true or false depending on the amount of available squares:

def complete?
  available_squares.zero?
end

I still have a way to go to adhere to the Single Responsibility Principle throughout the Tic Tac Toe game. Following the red, green, refactor cycle and the points on refactoring are helping to apply this principle.

Helpful resources:

What Is The Single Responsibility Principle?

Elle Hallal 👩🏽‍💻 — Thu, 21 Mar 2019 00:00:00 +0000

Originally posted at ellehallal.dev👩🏽‍💻

The Single Responsibility Principle(SRP) is one of the five SOLID principles of object-oriented programming. The intention is to “make software designs more understandable, flexible and maintainable”.

SRP is the concept that a class should have one responsibility, and therefore only one reason to change.

Implementing The Principle

I’m currently working on a Tic Tac Toe game in Ruby, where I have been provided with a number of user stories. The first user story is: as a user, I can see the initial board.

Breaking this down, my understanding is there needs to be a Tic Tac Toe board, and the user needs to be able to see it.

Creating The Board

class Board
  attr_reader :board

  def initialize(board)
    @board = board
  end
end

Above, the Board class takes a board as an argument when initialised. For a Tic Tac Toe game, an array containing numbers 1–9 will be passed when an instance of Board is initialised.

board = Board.new([1, 2, 3, 4, 5, 6, 7, 8, 9])

Displaying The Board

To show the Tic Tac Toe board, a method is needed to show the output to the user. For example:

def display_board(board)
  print """
    #{board[0]} | #{board[1]} | #{board[2]}
    -----------
    #{board[3]} | #{board[4]} | #{board[5]}
    -----------
    #{board[6]} | #{board[7]} | #{board[8]}\n"""
end

It would be natural to assume this method should be within the Board class, simply because that is where the Tic Tac Toe board lives.

However, what if changes were to occur in the future? For example, if the application was to become web-based, rather than command line based, display_board would be a redundant method. As a result, it is likely that any methods within Board containing output would need to be changed.

What would happen if all output was contained within a separate class? In the case above, the Board class wouldn’t need to be amended because it doesn’t contain methods that are printing to the command line.

With this in mind, a new class called Display, was created with the display_board method added:

class Display
  def display_board(board)
    ...
  end
end

For other user stories, where printing a message to the command line is needed, such as prompting the user for a move and displaying the current player, it will be contained within this class.

Conclusion

By implementing the Single Responsibility principle, the Board and Display classes have one responsibility each and only one reason to change.

The Board class manages the state of the Tic Tac Toe board. In relation to the user story, it creates a Tic Tac Toe board.

The Display class manages printing output to the command line for the user to see. In relation to the user story, the user can see the initial board.

How To Deploy A Web App To Heroku

Elle Hallal 👩🏽‍💻 — Wed, 30 Jan 2019 00:00:00 +0000

Originally posted at ellehallal.dev👩🏽‍💻

This is a quick blog on how I deployed my weather manager app to Heroku.

Deploying took longer than anticipated, due to an issue I was experiencing with dotenv-webpack and dotenv in a production environment. The following error kept popping up when deploying to Heroku:

failed to load ./.env

Thanks to one of my mentors, Dan, for helping me to figure out what was going on! As this issue has been resolved, this blog will outline the steps in an order that should not cause errors when deploying.

For reference, here’s how my weather manager files are organised. There are hidden files:

./dist contains main.js
.env (which contains my API key) is in the root directory

Step 1: Express.js — web app framework

Create server.js in the root directory, and add the following code:

const express = require("express");
const path = require("path");
const port = process.env.PORT || 8080;
const app = express();

app.use(express.static(__dirname + '/dist'));

app.get('*', (req, res) => {
  res.sendFile(path.resolve(__dirname, 'index.html'));
});

app.listen(port);

Run npm install express

Key points

__dirname is the directory where server.js is
__dirname + ‘/dist' is the current directory from where main.js is running

Step 2: Create webpack.prod.js

This step is important if you have dotenv-webpack installed. If installed then in webpack.config.js, dotenv-webpack is required:

const path = require("path");
const Dotenv = require("dotenv-webpack");

module.exports = {
  entry: "./src/index.js",
  mode: "development",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist"),
  },
  node: {
    fs: "empty",
  },
  plugins: [new Dotenv()],
};

This is fine for development, but doesn’t seem to work well for production. Therefore, a similar file is needed for production only, which doesn’t contain references to dotenv-webpack.

Create a copy of webpack.config.js in your root directory and name it webpack.prod.js
In webpack.prod.js, remove references to dotenv-webpack, and replace it with the following:

const path = require("path");
const webpack = require("webpack");

module.exports = {
  entry: "./src/index.js",
  mode: "production",
  output: {
    filename: "main.js",
    path: path.resolve(__dirname, "dist"),
  },
  node: {
    fs: "empty",
  },
  plugins: [
    new webpack.DefinePlugin({
      "process.env": {},
    }),
  ],
};

Under scripts in package.json, add:

"scripts": {
  "start": "node server.js",
  "heroku-postbuild": "webpack --config webpack.prod.js"
},

As a result, Heroku will use the webpack.prod.js file, rather than the webpack.config.js file.

Set the version of npm and Node.js by adding the below to package.json:

"engines": {
  "node": "11.6.0",
  "npm": "6.5.0"
}

Step 3: Only require dotenv when NODE_ENV is set to development

Assuming dotenv is also installed, add the following to server.js, just under const app = express();

if (process.env.NODE_ENV == 'development')
require('dotenv').config({ silent: true });

Step 4: Set dotenv-webpack and dotenv as devDependencies

For dotenv-webpack and dotenv to be required during development only, run the following:

npm install dotenv --save-dev
npm install dotenv-webpack --save-dev

Step 5: Deploying to Heroku

Sign up to Heroku
Install Heroku CLI
Log into Heroku via the terminal with heroku login
Run heroku create to create your app on Heroku. An app name will be generated
Reinitialise the project by running git init
Set a Heroku remote branch by heroku git:remote --app [your-heroku-app-name]
Set your environment variables — or config vars as they’re referred to in Heroku. Here’s how I set my API key for openweathermap: heroku config:set API_KEY=myapikey3902e92e802e8
Git add and commit
Push to Heroku with git push heroku master

And that’s it (hopefully)!

Helpful Resources

What Is Dependency Injection?

Elle Hallal 👩🏽‍💻 — Fri, 16 Nov 2018 00:00:00 +0000

Originally posted at ellehallal.dev👩🏽‍💻

This is a quick blog on how I've used dependency injection to improve the design of my JavaScript Tic Tac Toe game.

In the example below, when the Game class is initialised, instances of the Board and Player classes are also created.

class Game {
  constructor() {
    this.board = new Board();
    this.player1 = new HumanPlayer();
    this.player2 = new HumanPlayer();
  }
}

If we wanted to add a new type of player (ComputerPlayer) as an option in our game, the above code would make it difficult to do so. This is because the player types are "hardcoded" in the Game's constructor. This is where dependency injection comes in.

What Is It?

In software engineering, dependency injection is a technique whereby one object (or static method) supplies the dependencies of another object.
— Wikipedia

Let's apply this to our example. Instead of "hard coding" the classes to be initialised inside of Game's constructor, we can pass them in.

class Game {
  constructor(board, player1, player2) {
    this.board = board;
    this.player1 = player1;
    this.player2 = player2;
  }
}

When we initialise a new instance of Game, we can pass in our arguments.


const board = new Board(['o', 'x', 'x', 'x', 'o', 'o', 'o', 'x', 'x'])
const humanPlayer = new HumanPlayer();
const computerPlayer = new ComputerPlayer();
const game = new Game(board, humanPlayer, computerPlayer)

As a result, this improves the flexibility of which dependents we can use with Game. For example, now we can initialise the class with two human players, or two computer players, or one of each!