DEV Community: Jules

Making my Ruby 'Legacy Code' SOLID

Jules — Tue, 07 Apr 2020 10:57:57 +0000

Several weeks ago I was working on a TicTacToe game in Ruby, but then I moved on to Java for a while. Now I've returned, full of type-security and compiler error handling, and hopefully some transferrable things too. There's plenty to look at, but I'll just be working through a single example for each SOLID principle.

Dependency Inversion

I'm starting with the 'D' in SOLID because when I came back to this project I noticed how tightly coupled the whole thing was, making any change very difficult. Most classes instantiated others instead of having them injected, so that was the first thing I changed.

Take a look at this test for my Game class. It makes an instance of Game, refers to both Board and ConsoleInOut, and fixes the gets result of ConsoleInOut.

Before

require 'game'

describe Game do
    it 'Asks for board size input' do
        allow_any_instance_of(ConsoleInOut).to receive(:gets).and_return('4')
        game = Game.new
        expect(game.board.board_size).to eq 4
    end
end

How do we know that Game contains instances of these classes? How do we change their input and output? We don't and we can't (unless you count allow_any_instance_of as changing input).
We have an opaque bundle of prima-donna classes that insist the tests be written around them. Let's change that by instantiating all of Game's dependencies externally and then injecting them on instantiation.

After

require 'game'

describe Game do
    before(:each) do
        @inOut = ConsoleInOut.new('', '')
        @player_x = Player.new('Player 1', 'X')
        @player_o = Player.new('Player 2', 'O')
    end

    it 'Asks for board size input' do
        board = Board.new(@inOut, 4)
        game = Game.new(@inOut, @player_x, @player_o, board)
        expect(game.board.board_size).to eq 4
    end
end

Now we know exactly what Game contains, because we passed them in, and this allows us to change the parameters of these classes beforehand. For example, when we pass in a ConsoleInOut instance, we can replace STDIN with a string to simulate input, and STDOUT with a string so that the test output isn't polluted by every print method.

Single Responsibility

Classes shouldn't have more than one responsibility, plain and simple. There are more technical explanations out there, but it's enough so say that my ConsoleInOut class is both getting input and validating it.

It works, but if I were to swap out ConsoleInOut for, say, WebInOut, I'd need to reimplement validation as well as Input/Output.

Since Game will always get the same input, there's no reason to ever change validation, so let's go ahead and put it in the Game class that handles interactions between classes.

Before

class ConsoleInOut
    def initialize(input, output)
        @input = input
        @output = output
    end

    def get_input
        #
    end

    def print(to_print)
        #
    end        

    def select_move(max_turns)
        print("Please enter a free number from 1-#{max_turns}")
        player_input = gets.chomp.to_i
        valid_player_input(player_input, max_turns)
    end

    def valid_player_input(player_input, max_turns)
        player_input >= 1 && player_input <= max_turns ? player_input : 
        select_move(max_turns)
    end

    # And some similar select/validate methods
end

class Game

    # And the rest of the Game

    def submit_move
        player_input = @inOut.select_move(@board.max_turns)
        @board.make_move(current_player.mark, player_input - 1)
        @board.view_board
    end
end

After

class ConsoleInOut
    def select_move
        player_input = gets.chomp.to_i
    end

    # Remove valid_player_input, rest is the same
end

class Game

    # The rest is the same

    def submit_move
        valid_move = false
        until(valid_move)
            @inOut.print("Please enter a free number from 1-#{@board.max_turns}\n")
            player_input = @inOut.select_move(@board.max_turns)
            valid_move = @board.is_square_free?(player_input - 1)
        end
        @board.make_move(current_player.mark, player_input - 1)
        @board.view_board
    end
end

Now ConsoleInOut just gets input for Game, without knowing or caring what happens next. Game is now a bit bigger, but more complete, and validation is functionality that shouldn't ever need changing. As a bonus, if anything goes wrong with input and validation, it's easier to place the blame.

Open/Closed

I'm going to be very daring and use a metaphor now:

A gaming console or desktop computer is complete in itself.
It doesn't need a particular screen to work, just a screen, and the HDMI port lets you plug it into a huge range of screens without changing anything else.
If one screen breaks, the console still works, just find a new screen.
But if you took out the port and built-in a screen, it would be less modifiable, and the screen breaking would be serious.

Your code should have more 'ports' and fewer 'built-ins'. Metaphor over, promise that's the only one.

So...

In the case of a program, it should be be complete and closed to changes, yet open for new features to be added.

If I were to add a Computer Player to my game, it would require rewriting the game so that the Computer could choose to make a move without console input.

In order to make the program open to extension, it is necessary to create a seam by moving the responsibility of selecting a move to the Player class. Then, the core program will not require changes.

Take the code above as a 'before' example for Game.

Before

class Player
    attr_reader :id, :mark
    def initialize(id, mark)
        @id = id
        @mark = mark
    end
end

After

class HumanPlayer
    attr_reader :id, :mark
    def initialize(id, mark, inOut)
        @inOut = inOut
        @id = id
        @mark = mark
    end

    def make_move
        @inOut.select_move
    end
end

class Game

    # The rest is the same

    def submit_move
        valid_move = false
        until(valid_move)
            @inOut.print("Please enter a free number from 1-#{@board.max_turns}\n")
----->      player_input = current_player.make_move
            valid_move = @board.is_square_free?(player_input - 1)
        end
        @board.make_move(current_player.mark, player_input - 1)
        @board.view_board
    end
end

Now that the instance referred to by current_player is responsible for returning a move, we can just swap out a now Human_Player class to extend the program with a Computer player. See below.

Liskov Substitution

In Java, you can make sure that one class is substitutable for a similar one with interfaces or abstract classes. Ruby doesn't have that, but as a colleague is fond of saying, "we can keep the interface in our heads". An interface contains a list of methods that a class doing this particular job must have, but leaves the implementation up to each class. So instead of having an interface file and having the compiler enforce it, we will just imagine that that's going on.

See the HumanPlayer class and its tests below to see what we're working with.

Human Player

class HumanPlayer
    attr_reader :id, :mark
    def initialize(id, mark, inOut)
        @inOut = inOut
        @id = id
        @mark = mark
    end

    def make_move
        @inOut.select_move
    end
end

Tests

require 'human_player'
require 'console_in_out'

describe HumanPlayer do

    before(:each) do
        inOut = ConsoleMock.new('3', '')
        @player = HumanPlayer.new('Player 1', 'X', inOut)
    end

    it 'Stores player name' do
        expect(@player.id).to eq('Player 1')
    end

    it 'Stores player name' do
        expect(@player.mark).to eq('X')
    end

    it 'Can make a move' do
        expect(@player.make_move(9)).to eq(3)
    end
end

The HumanPlayer class stores information (id and mark), and has a make_move method. If this class implemented an interface, that interface might look like this.

Player Interface

interface Player
    def initialize(id, mark)
    end

    def make_move(max_turns)
    end
end

With the same methods, but no body, you can implement the functionality however suits you, and replace a generic Player instance with any instance that fits this pattern.

I've also added max_turns to make_move as I'm anticipating the computer using the rand method in the initial implementation, so HumanPlayer needs this to make the classes substitutable.

Note: It's worth passing in an instance of the Board class so that the computer has knowledge of the Board state, but for the sake of this example I'm keeping it short.

Computer Player

class ComputerPlayer
    attr_reader :id, :mark
    def initialize
        @id = 'Computer'
        @mark = 'O'
    end

    def make_move(max_turns)
        rand(max_turns)
    end
end

To summarise, it doesn't matter how Player or ComputerPlayer work, just that they contain the same core methods. Want to add methods to one or the other? Fine, they will still conform to the Liskov Substitution Principle as long as they both have make_move and store id and mark, since other classes refer to these.

If I want to change how HumanPlayer or ComputerPlayer makes a move, I can do this without modifying Game, and I can add a third option without changing anything.

We're nearly done.

Interface Segregation

I don't have a specific code example for this principle, as this is a small program with two (imaginary) interfaces. The 'imaginary' is important; Ruby doesn't have interfaces, so if the idea is still unfamiliar to you, feel free to move on to the next section.
Otherwise, I will briefly cover the idea behind the Interface Segregation Principle.

The Interface Segregation Principle states that more, smaller interfaces are better than fewer, larger interfaces. This is to prevent the forced implementation of unused methods by a client. In the case that the In/Out interface grew too large, it may be possible that a class implementing it didn't use all of its methods, but had to add them anyway to avoid compiler errors. Why should you add code that isn't used? You shouldn't, meaning this bloated interface should be broken up so that each class only contains methods it uses.

It's also helpful to have smaller classes and interfaces to follow the Open/Closed Principle mentioned earlier; with fewer modifications necessary and more seams available, any future change is much easier.

It's All Connected

Interestingly there's overlap between the SOLID principles, so each of these improvements doesn't just improve the program in one way; having a Liskov Subsitution approved In/Out interface makes dependencies more manageable, as well as making the program open to extension. Furthermore, exporting make_move functionality to a Player better follows the Open/Closed Principle, narrows the responsibility of Game, and paves the way for a Liskov Substitutable computer_player class.

Error handling in Java

Jules — Fri, 20 Mar 2020 10:27:11 +0000

Compiled languages are very needy, but at least you know before you deploy the code that you've accounted for most edge cases. However, this definitely comes under 'don't just do what the IDE suggests', which has caused me problems before now, so let's establish some appropriate error handling.

What's to be done

Certain methods are more likely to fail than others, so to compile you have to use error-handling; in this case either try/catch or throws will get the job done.

Example 1

public class Database {
    Connection connection;
    public Database(String databaseUrl) {
        Class.forName(org.postgresql.Driver);
        connection = DriverManager.getConnection(databaseUrl, "postgresUser", "postgresPassword");
    }
}

Attempting to connect to a Postgresql database above will cause two compiler problems:

forName() Unhandled exception: java.lang.ClassNotFoundException
getConnection() Unhandled exception: java.sql.SQLException

These can be solved together or separately with the solutions I mentioned above.

Try/catch

public class Database {
    Connection connection;
    public Database(String databaseUrl) {
        try {
            Class.forName(org.postgresql.Driver);
            connection = DriverManager.getConnection(databaseUrl, "postgresUser", "postgresPassword");
        } catch(ClassNotFoundException | SQLException e) { // or just (Exception e)
            e.printStackTrace();
        }
    }
}

Throws

public class Database throws ClassNotFoundException, SQLException { // or, again, just Exception
    Connection connection;
    public Database(String databaseUrl) {
        Class.forName(org.postgresql.Driver);
        connection = DriverManager.getConnection(databaseUrl, "postgresUser", "postgresPassword");
    }
}

But which! When?

Let's quickly go over why this happens. The reason we need to handle anything is that there is a chance that one of the methods we're using will call throws. The forName() method comes with throws built in, so we either have to say that the method in which we use it (in this case, Database) could throw an error, or catch it.

If we choose throws, we're allowing the error to move on, and unless it is handled by another method - like a method that calls Database - it will cause the program to terminate with an error message.

However, when we use try/catch we're saying:

Yes, this code is risky but try it anyway
If it throws an error we'll catch it and do this instead. Usually 'do this instead' is an error message for the user.

And on top of try/catch is finally:

Whatever happens, we will do this afterwards

So...

To condense this, throw passes responsibility up to the next method to be handled (or ends the program if not handled eventually), and catch handles exceptions in a meaningful way now.

When to let it throw

Tests are a good time. In JUnit, you can assert that a method throws an error in whatever case, and if you didn't plan for it to throw, then your tests won't pass and you'll find out quickly.

Checked vs. Unchecked Exceptions

So far, everything we've covered has been about checked exceptions, which are exceptions found by the compiler before the program is run. There are also unchecked exceptions or 'Runtime Exceptions', which are only found when the program is running.

Checked Exception Examples

class Iterate {
    public static void main(String args[]) {
        String arr[] = {"Primo", "Two", "Third"}
        System.out.println(arr[10]);
    }
}

The above will compile, but then throw an IndexOutOfBoundsException as we're trying to access the tenth element of an array with only three items.

Similarly, if you call an instance that hasn't been instantiated and get a NullPointerException, that would be an unchecked exception. These exceptions should still be handled, you just won't have them pointed out by the compiler.

Summary

Checked exceptions are picked up by the compiler and must be handled. They tend to involve interactions outside of the program (reading files, database queries, input).

Unchecked exceptions happen during runtime and should be handled, but won't prevent compilation. They are mostly problems within the program (null, type incompatibility, out-of bounds, dividing by zero).

Repository Pattern

Jules — Tue, 17 Mar 2020 11:25:49 +0000

Design Patterns are a new idea to me, but the concept is easy enough to understand; it's a general, reusable solution to a commonly occurring problem. The idea came from an architect, Christopher Alexander, and has been adopted in software.

All OO languages can work with classes to store and manipulate data, but a pattern would be a particular way of using objects to create and manipulate other objects that has been proven to work for a specific purpose. Let's take a look at the Repository Pattern.

What's a Repository?

A Repository has access to a collection of objects of a single class, on which you can perform CRUD operations.

Eric Evans explained it in his book Domain Driven Design: A Repository represents all objects of a certain type as a conceptual set. It acts like a collection, except with more elaborate querying capability

Example 1

public interface ContactRepository() {

    void createContact(Contact contact)
    void removeContact(Contact contact)
    void updateContact(Contact contact)
    List query(Specification specification)
}

In this Interface, notice that the methods used are CRUD methods, that they all take an object as their argument, and that the object is the same for each of them.

The query method is an exception. Assuming that you are working with a large set of data, potentially in a database, it's not feasible to load them all, all of the time. Instead, you load a specific one or group that match a query.
To implement this, you need a Specification object. If you wanted to query by date, the business layer could pass a Date object to the repository, which then returns the results matching that query.

You would likely need other methods for functionality like returning objects before or after a specific date, and that's fine; just make more methods.

Business Objects and the Business Layer

The data you are returning is known as a business object, as it is complete in a business sense. Take an account or a user, both are complete ideas that may need to be understood and accessed by the business layer. Importantly, the business layer doesn't care about how the data persists - so it could be in-memory or a DB - the only thing it cares about is storing and retrieving objects, which it does through the repository.

How is the Repository Pattern distinct from other patterns?

As previously stated, the Repository Pattern receives objects and queries using those objects, and only works with a single, complete business object.
If instead you were using the Data Access Object (DAO) Pattern, you might not use a complete business object, so you might return more than a single type of object, and you might not query with objects, but with a variable.

Summary

If you're working with data like accounts, you can access those accounts from a class (business layer) by creating an intermediary class (repository) that understands accounts and only accounts. It CRUDs accounts, and can return them to the first class, which doesn't need to know how anything works as long as it gets what it wants.

Business Layer <---> Repository <---> Storage

On the Open-closed principle (Decoupling & Abstraction)

Jules — Tue, 10 Mar 2020 12:30:55 +0000

Here, I'll be tracking the abstraction of a Contact Manager that I've been decoupling, similar to the example in my post on Interfaces. The aim of this is to reach a point when I have a core program that needs no modification to add new functionality, but instead can be extended with new classes, per the second of the SOLID principles.

As a program grows, it's important to keep an eye on its structure and spot opportunities for abstraction.
If a class gains a few more functions, you might find, for example, that the single mention of the string name of a field becomes a regular reference, and that it's worth promoting a string to a variable, or a series of constants to a class.

Unless it's important, I'll use abstract methods with no bodies. Below is the Contact class from my program, which stores data and modifies it.

Example 1 - Contact

public class Contact {

public String FirstName;
// plus five more fields

public Contact(String firstName // five more here too) {
   this.FirstName = firstName;
    // plus five more fields
}

public updateFirstName(firstName) {
    if (!firstName.matches(String.valueOf(ValidateInput.blankString))) {
        FirstName = firstName;
    }
}
// plus five more almost identical update methods
}

Immediately there are a couple of problems here. The first is that I've got six methods doing the same thing with only one variable.

Abstraction Concept: Repetition indicates that there's room for abstraction, so let's generalise these methods.

The second is that the Contact class is responsible for both storing and modifying its own state. That's a lot of responsibility for what should be the computer equivalent of a card with six lines on it.

It also means that the 'structure' of the program is really just a series of inseparable classes, as ContactManager relies on Contact when it tells it to update itself.

Abstract-ification Sequence

public class ContactManager {

private ConsoleIO consoleIO;
private ArrayList<Contact> contactList;

public ContactManager(ConsoleIO consoleIO, ArrayList<Contact> contactList) {
   this.consoleIO = consoleIO;
   this.contactList = contactList;
}

public void updateField(String value, Contact contact, int field) {
    if (!value.matches(String.valueOf(ValidateInput.blankString))) {
        switch (field) {
            case 1: contact.FirstName = value; break;
            case 2: contact.LastName = value; break;
            case 3: contact.Address = value; break;
            case 4: contact.PhoneNumber = value; break;
            case 5: contact.DOB = value; break;
            default: contact.Email = value; break;
        }
    }
}
// and a lot of other methods
}

And now Contact is just

public class Contact {

public String FirstName;
// same as before, 5 more

public Contact(String firstName) {
   this.FirstName = firstName;
}
}

Much better. Now six methods are one, and the Contact class is 18 lines long, with the sole responsibility of storing information.

Example 2 - ConsoleIO

Note: If you don't know about interfaces, scroll back up and see the other post in my Abstraction series.

ConsoleIO is my class for handling input and output, specifically in the console.

To implement the InputOutput interface I made, ConsoleIO needed four methods:

display
getStringInput
getMenuInput
confirmInput

My ConsoleIO class had the required four methods to implement the InputOutput interface, but it also had methods that validated the input.

public class ConsoleIO implements InputOutput{

public ConsoleIO()

public void display()

public String getStringInput()

public int getMenuInput()

public String getInput()

public static Boolean validateInput()

public static Boolean validName()

public static Boolean validNumber()

public static Boolean validDOB()

public static Boolean validEmail()

public static Boolean isBlank()
}

What had started as a method or two grew to six, and this class never really needed to know the rules for valid input. If this were a whiteboard, I'd draw a big circle around everything with valid in it (and that last one too, close enough).

Abstractionise

public class ConsoleIO implements InputOutput{

public ConsoleIO()

public void display(String message)

public String getStringInput()

public int getMenuInput()

public String getInput()
    // this method calls validation methods
}

ConsoleIO is back down to its core methods, and below we have a new class that doesn't even need to be initialised, since everything's static.

public class ValidateInput {

public final static Pattern blankString = Pattern.compile("^$");

public static Boolean validateInput(){
    // this one calls the ones below as appropriate
}

public static Boolean validName()

public static Boolean validNumber()

public static Boolean validDOB()

public static Boolean validEmail()

public static Boolean isBlank()

}

Decoupling

It's getting a lot easier to look at these classes and tell what they do. ConsoleIO doesn't know what makes input valid, and ValidateInput doesn't know where the input comes from or goes back to.

Decoupling Concept: If a class isn't designed to handle other classes (like ContactManager handles Contacts), then it should know nothing about how it works. The less it knows, the less it relies on low-level details.
Passing information from ConsoleIO to ValidateInput should be seen as a black-box, where input goes in, mysterious (see: abstract) doings occur, and then output comes out.

It might seem that this isn't much of an improvement; that I've just moved methods from class 1 to class 2 and that class 1 still needs the methods of class 2. However, the value comes in that I can swap ConsoleIO for a different InputOutput interface-based class like 'WebIO', and I don't need to repeat the validation methods.

Abstraction Concept: Abstraction doesn't have to make a difference now, the value comes in facilitating future change. I've made room for future classes, but I don't need to know how they work.

End Goal

While this program isn't finished, the examples I gave were basic changes that made incremental improvements now, and make future change much easier.

The aim of this program is to reach a point where each class only knows just enough to do its part, so that I could swap out any class with another that follows an appropriate interface.

What this achieves is maximum room for extension, without needing to anticipate any specific functionality. Using this on the web? Swap out ConsoleIO with the new WebIO.

Interfaces Explained

Jules — Mon, 09 Mar 2020 12:56:17 +0000

In the quest to write Better Code, you will encounter many abstract concepts, the explanations of which are themselves often abstract. The idea of an Interface is a simple one when kept grounded in code, so that's how I'm addressing it here.

Below is an interface in a Contact Manager I've been making in Java. It's a command-line application that stores information in memory. Instead of class it says interface, its methods have no body, and it contains no variables, although it can have final static fields.

Example 1

interface InputOutput {

    void display(String message);

    String confirmInput(String field, boolean isAnUpdate);

    int getNumberInput();

    String getInput(String detail);

}

What does an Interface do?

Nothing. It's just a blueprint that you must adhere to.

If I were to remove it and all mentions of it from my project, nothing would change. This isn't surprising, as the four methods it contains have no body. Because they're abstract/blueprint methods.

However, since my ConsoleIO class (see Example 2) 'implements InputOutput', it must contain the methods that the InputOutput interface contains. In other words, we're stating that InputOutput was used as a model around which the ConsoleIO class was made.

It could also contain methods not specified in the interface, but it has to have those core ones.

Example 2 shows the class that the InputOutput interface was modelled after (in this case, I made the class and extracted an interface after, but in the future I might start with an interface). It contains the same four methods, as well its own instance method and some variables. The difference is that the methods have bodies now, implementing details of the relevant functionality however I see fit.

Example 2

public class ConsoleIO implements InputOutput {

private final InputStream input;
private final OutputStream output;
private final BufferedReader reader;
public final PrintStream printer;

public ConsoleIO(InputStream input, OutputStream output) {
    reader = new BufferedReader(new InputStreamReader(input));
    printer = new PrintStream(output);
    this.input = input;
    this.output = output;
}

public void display(String message) {
    printer.println(message);
}

public String confirmInput(String field, boolean isAnUpdate) {
    Boolean validInput = false;
    String userInput = null;
    while (!validInput) {
        userInput = getInput(field);
        validInput = ValidateInput.validateInput(field, userInput, isAnUpdate);
    }
    return userInput;
}

public int getNumberInput() {
    String userInput;
    try {
         userInput = reader.readLine();
    } catch (IOException e) {
        return - 1;
    }
    try {
        return Integer.parseInt(userInput);
    } catch (NumberFormatException e) {
        return 0;
    }
}

public String getInput(String detail) {
    display("Please enter your " + detail + ":");
    String userInput = null;
    try {
        userInput = reader.readLine();
    } catch (IOException e) {
        display("Cannot read line" + e);
    }
    return userInput;
}
}

Let's Get Abstract

An interface doesn't handle anything concrete. It doesn't specify how the methods it contains are to be implemented, only that they should exist.

The interface is a plan for future classes that will implement the same functionality in a different context.
In this case, it's an InputOutput interface, so if in the future I add a class to my program so that it works online as well as in the command-line, it will need methods to:

Display output
Confirm input
Get string input
Get menu input

Polymorphism

Example 3

interface Save {
   void saveNumber(String phoneNumber)
}

class File implements Save
    public void saveNumber(String phoneNumber) {
        // However you implement saving to a file
    }
}

class Database implements Save
    public void saveNumber(String phoneNumber) {
        // However you implement saving to a database
    }
}

Interfaces help create systems that implement polymorphism. The idea of polymorphism is that classes are interchangeable, so swapping an instance of class File for one of Database wouldn't matter, as they have the same methods.

Let's say Phonebook calls the write method for either of these, injecting the relevant class as destination.

destination.saveNumber("5550123");

It would work either way, and the program wouldn't know or care where it's saving to.

Closing

Interfaces are abstract because they serve as plans or reminders rather than having any real functionality. Languages like Ruby don't even have interfaces, but it helps to keep the idea of them in your mind when designing your system.

Java Primitives vs. The Rest

Jules — Tue, 03 Mar 2020 12:24:24 +0000

"Friends don't let friends use Integer."

Related to my last post about not making everything static and recursing through chained methods, a colleague offered the above maxim. And, also related, it was something low priority, but on my radar to look up when I had more time (because that's going to happen). The final connection was that I was once again making things harder for myself by using the wrong tool for the job.

Why were you using Integer Jules?

Because I didn't know about the primitive int. These distinctions don't exist in Ruby, so they didn't exist to me. Somebody had pointed out that using Integer would create issues, but it became an afterthought because it was 'working' now.

So what's the difference?

Integer five = 5;

Integer is an object reference. When I declare five as an Integer, I'm making a new object, with a value of 5, that I am passing by reference whenever I refer to five.

int five = 5;

The int type is a primitive, which stores an actual value, instead of the reference to an object where the value is stored. This means slightly better performance when using primitives.

Does it really make a difference?

An excerpt from Joshua Bloch's Effective Java gives the following example:

Example 1

public static void main(String[] args) {
    Long sum = 0L; // uses Long, not long
    for (long i = 0; i <= Integer.MAX_VALUE; i++) {
        sum += i;
    }
    System.out.println(sum);
}

The above code takes 43 seconds to run because reference type Long is used. If you replace Long with long, it takes 6.8 seconds. Think of all of the objects you're creating just to refer to once.

Example 2

Integer x = 1;
Integer y = 1;
return x == y; // false

int a = 1;
int b = 1;
return a == b; // true

If using reference types, you end up comparing objects instead of values unless .equals() is used.

So why use reference types?

Reference types let you work with useful methods like Map, List, and Set (pretty much any class method), which require an object. Objects like Integer also allow for null values, should you need them.

The important thing is to consider your needs, such as whether your program is going to require the option to use null with numbers, or whether you need to use certain class methods. Many class methods could be replicated to work with primitives if necessary, but you have options both with and without as it is.

In summary, you have high-performance options in primitives, and options with greater functionality in reference types.

More principles please

It's easy to get so caught up in small details that you miss the big ideas, so I've found immense value already in the simplicity of "Friends don't let friends use Integer", and the more rounded "Only use Integer where int can't do the job" that has emerged from doing some research.

I suppose that another good principle here is "Read the docs" as somebody already considered that it might be useful to have a basic understanding of the language so yeah, I'm going to go and read the docs over at https://docs.oracle.com/javase/tutorial/java/nutsandbolts/

Anyway, thanks for reading, and if you've got anything to add I'd love to hear it!

P.S.

Extra Note Regarding Ruby

The addition of new kinds of variables is not just helping me work with Java, but is also giving me insight into the kind of tradeoffs that you might make when working with a language like Ruby. In benchmark tests, Ruby is always near the bottom, and it's easy to see why when every bit of data is an object. But it is very nice to work with.

Java 'Static' keyword - Intro: How (not) to use it

Jules — Mon, 02 Mar 2020 11:38:31 +0000

When do I use the static keyword? What does it do? Doesn't matter, the IDE is telling me where to add it!

With that attitude, my Main class ended up looking like this:

Example 1

public class Main {
    static Contact contact = new Contact();
    static Input input = new Input();

public static void main(String[] args) {
    showMenu();
}

public static void showMenu() {
    int menuChoice;
    menuChoice = input.menuChoice();
    switch (menuChoice) {
        case 1: updateContact();
        default: break;
    }
}

static void updateContact() {
    updateContactFields();
    showContact();
}

static void updateContactFields() {
    // lots of update calls
}

static void showContact() {
    // Lots of prints
    showMenu();
}
}

It was a train-wreck for lots of reasons, but the static everything was causing problems I wasn't aware of.

Bad move Jules

I had priorities, and finding out what all of these (not so) generic keywords meant was low. Anyway, the program worked, and if I made a new method, IntelliJ told me that I couldn't reference a non-static method from a static context, so all of the methods became static.

In the back of my head however, there was something bothering me;

The main method in a Java class must be static
Every method I was using was directly or indirectly called through the main method
Methods called by other classes didn't have to be static, but also could be

So why was I adding this all of the time?

Blocker

Eventually, a combination of using recursion where loops were better and making my entire class static caused problems with state that I couldn't debug. Someone familiar with Java took a quick look and asked me if I knew what static did.

They described it, in Ruby terms, as making something a Class method or variable. I needed instance at most, but had unintentionally made everything global.

Solution/Example 2

public class Main {

    Input input = new Input();
    ArrayList<Contact> contactList = new ArrayList<>();

public static void main(String[] args) {
    Main main = new Main();
    main.showMenu();
}

public void showMenu() {
    boolean complete = false;
    while (!complete) {
        printMenuOptions();
        int userInput = input.menuChoice();
        switch (userInput) {
            case 1: {
                newContact();
                break;
            }
            case 2: {
                updateExistingContact();
                break;
            }
            case 3: {
                showContact();
                break;
            }
            default:
                complete = true;
                break;
        }
    }
}

void printMenuOptions() {
    // logs
}

void newContact() {
    contactList.add(new Contact(input.confirmInput("first name"), input.confirmInput("last name"), input.confirmInput("address"), input.confirmInput("phone number"), input.confirmInput("DOB in dd/mm/yyyy format"), input.confirmInput("email")));
}

void updateExistingContact() {
    if (checkForContacts()) {
        displayContacts();
        try {
            updateContactFields(contactList.get(Integer.parseInt(input.confirmInput("contact choice")) - 1));
        } catch (Exception e) {
            System.out.println("No such contact");
        }
    }
}

boolean checkForContacts() {
    if (contactList.size() == 0) {
        System.out.println("There are no contacts yet");
        return false;
    } else {
        return true;
    }
}

void updateContactFields(Contact contact) {
    // logs and update calls
}

void showContact() {
    if (checkForContacts()) {
        displayContacts();
        Contact contact = null;
        try {
            contact = contactList.get(input.contactChoice() - 1);
        } catch (Exception e) {
            System.out.println("No such contact");
            showMenu();
        }
        printContactDetails(contact);
    }
}

void printContactDetails(Contact contact) {
    // lots of logs
}

void displayContacts() {
    System.out.println("Please select a contact");
    for (int i = 0; i < contactList.size(); i++) {
        System.out.println(i + 1);
    }
}
}

(Note: there's extra functionality here too)

To avoid calling methods from the static method main, you just:

Make an instance of the Main class in the main method
Call any methods from that instance of Main (e.g. main.displayContacts())
Now you only have to make things static where it's good practice

When should things be static?

I'm glad you asked: Let's say I have a list of contacts, and each of these contacts has several properties. In case they share a common property, the variable can be static to save memory.

class Contact {
    String name;
    static String country = "Arstotzka";
    int age;
    // and so on
}

If I have 10 Contact instances, the name variable will be assigned memory 10 times. On the other hand, country is static, so it's only given memory once, however many instances there are. It doesn't have to be static, but it's more efficient, memory-wise, to make it so.

Notes:

It can still be changed, but it's less likely to be changed than non-static variables.
Static variables must also be initialised with a value, as you are saying that the variable and its value is inherent to the class.

Class Methods

Class methods are used without instantiating the class, as was the case in Example 1. Main was never instantiated, so if I called any methods, they had to be class level instead of object level.

Example 3

class Contact {
    String name;
    static String country = "Arstotzka";
    int age;
    // and so on

    static void updateCountry() {
        country = "Republia";
    }
}

The static method in Example 3 updates the static variable country, so every instance of Contact will now have the string value 'Republia' instead of 'Arstotzka'.

Recap

Static variables are class level variables, so are inherited by instances, and must be initialised before making an instance
Static methods are class methods, and are called without the class being instantiated
If you want to use instance methods, you need to instantiate your class (just now made the connection between instance variables/methods and instances of classes)

This is far from exhaustive, but is information that would have saved me a lot of time and pain if I had done the research earlier.

Let me know your thoughts, whether you think this is clear and useful, or I've missed something big and made some bad assertions!

Thoughts on Java, Part 1

Jules — Tue, 25 Feb 2020 09:01:55 +0000

Tracking my thoughts and understanding of Java as my understanding grows.

Impressions

Words that are jumping out include 'structured' and 'arbitrary'. I've already written about my first impressions of type-safety, but this moves into new territory, like the different classes of strings.

Progress

It's harder to predict how long tasks will take; Some things are very similar in implementation to Ruby, but with strings it's Apples and Oranges. Some strings are mutable, some are immutable, and trivial tasks like pushing strings to arrays has made me aware of the StringBuffer class, which does not return a string equal to that of the String class.

Closing

Working with Java has meant dealing with things I didn't know existed, so assuming that the OO similarities make up for being static, typed, and compiled was wishful thinking. I'm starting from the beginning again, only the beginning is harder here. It's a lesson in humility.
I'm learning a lot though, and I think that once the basics are down, things will seem clear, and I'll be a better programmer for having learned to do it this way.

Why is Software/Tech such an attractive industry?

Jules — Sun, 23 Feb 2020 14:56:23 +0000

Symptoms of a good thing

Things like remote-working and flexible hours are symptomatic of an industry that is good for workers, but you could stick those perks to an unattractive industry and not change it for the better. So...

Causes

Novelty. Engineering is not new, but the medium is. That's not to say that there are no old ideas holding practitioners back, but there's a lot of forward focus. Computing courses don't have modules on the Michelangelos and Da Vincis of programming, so we move forward, challenging current and old practices.

Possibility. If I were to begin a woodworking, blacksmithing, architectural, or pretty much any other making-things based project right now, I would have to make considerations for budget, materials, tools, and other limiting factors.
With my mid-range computer in front of me, it's more a 'the only limit is your imagination' kind of scenario, with notable exceptions like data science.
I can start my project on GitHub, use a free IDE to program in a free language and all of its free libraries, use some free (or free for the first thousand calls a day) web-services to host a website, keep a database, authenticate requests, and even do some machine learning tasks.

Accessibility. Do you have a computer? With an internet connection? Good enough.
As well as having an open source community with all of the tools you need for a long time, there are blog posts guiding you through getting a website hosted for free in half an hour. There are many websites dedicated to teaching you how to program for free, with some high-quality paid courses for not a lot of money. Stuck on a problem? Ask Stack Overflow.

Intangibility. Like I said, this isn't woodworking, or anything physical (unless you want to work with RaspberryPi or another microprocessor), so the work is wherever you are. Want someone to help from the other side of the world? Timezones are your biggest barrier, big deal. No work in your city? Work remotely.
All of these things are easier said than done, but for many other industries these points are non-starters, or at best a Friday treat.

Sum it up

A new and unique combination of possibility, low barrier to entry, and minimal physical restrictions make for something that is only limited by the people within it, and they're usually willing to help.

Thoughts on Craft, Part 1

Jules — Sun, 23 Feb 2020 14:56:08 +0000

A series tracking my thoughts on Software Craftsmanship as they develop.

Get some words down there

Hackathons, hackjams, meetups, conferences, and so on. Open Source communities, Hacker News, heated discourse on whether Agile actually works, stuff like that.

That's all stuff that makes me think that people care about what they do, and care about being better, however good they already are. I've attended talks from people who claim to exclusively pair-program, and others who love working with Clojure despite the fact that it's Clojure. There are a lot of talks generally, with lots of passion and ideas flowing.

Boil it down, now

What I'm getting at is that Software Development presents more as a vocation or a life choice than a career. There's a thriving community, where experienced professionals give up free time to learn and teach.

Nothing I've listed is unique to this industry, but it's all so pervasive that it makes a unique industry.

Type-Safety, it's pretty nice

Jules — Fri, 21 Feb 2020 17:22:46 +0000

Okay, short one.
I'm used to programming in Ruby where anything goes and you fix stuff later. The ultimate procrastination.

That said, it's surprising how useful I'm finding strongly-typed methods and variables; it's like having comments everywhere saying what my program's doing and makes me think about design more. When I can see that this method returns a string, but the one it calls is boolean-y, I'm encouraged to consider how they interact more.

Even if it doesn't change what I do now, it saves a lot of time when refactoring, and the tests don't even have to run for me to find out that square pegs don't go in round holes.

Long and short, restrictions keep things structured, and Java's working out well (enough).

Done.

The Right Way vs. the Easy Right Way

Jules — Fri, 21 Feb 2020 09:35:42 +0000

360 No Gradle

I've always leant towards doing things the 'right' way even if it's slightly harder than doing it the easy way, so imagine my joy when I'm assigned a Java project without the use of an IDE or package managers.

How's that working out?

Nothing's working and I don't know why.

Will you ever do it again?

Probably not.

What about Java itself?

It's early to say, but the language differences don't seem as big as the general project management differences (when compared to Ruby or JavaScript).

Notes for anyone trying the same thing

Look up setting CLASSPATH to .jar files (for junit and hamcrest)

Wrap it up

What I've picked-up here is that the barrier to entry for test-driving Java programs is much higher when done the hard way. If IntelliJ or Gradle/Maven cuts any of that out in the future (and according the web results, things always 'just work' when using those tools) then I can mark that experiment as done and move on.