Introduction

OOP - fewer definitions, more practice

24/09/2019

Note: you should have some experience with Java programming language - this is not a tutorial for beginners.

Paradigms and principles

Usually, when it comes to articles about Object Oriented Programming, it all boils down to four paradigm principles and five SOLID principles (if you don’t know those - we’ll get to them later). A few fancy words, maybe an example to show that the words actually mean something. Why not create something and come up with the said concepts yourself to prove that those principles are actually viable and knowing them is the base of being a good developer using an object oriented language or any language actually?

When is the code considered “legacy”?

Now, even though the project that we’ll discuss in this series may seem simple as a concept, it’s pretty hard to actually create a tool, an application or a framework that works well and is easily maintainable and expandable. While the outcome of many commercial projects may seem all right, their code base can be really terrible. Not much time is needed for such a project to turn from a great, new-technology-based developer snack into a most hated legacy swamp, which nobody wants to have anything to do with.

Actual product

In this series our goal is to create a tool that will help us translate a static HTML file into multiple languages. Thanks to that we can serve the same web page with different text based on placeholders used in the template file and file-based translation dictionaries. Such tools exist in many languages and frameworks - we want to perform an internationalization, which is usually abbreviated to i18n (there are 18 characters between the first and the last letter in the word).

Here’s an example of a template:

<head>
    <title>${page.title}</title>
</head>
<body>
    <header>
        <h1>${welcome.header}</h1>
        <p>${welcome.text}</p>
    </header>
    <article>
        <p>${main.page.about}</p>
        <p>${main.page.social}</p>
    </article>
    <footer>${footer.contact}</footer>
</body>

Page with templates

Here’s how it looks after applying i18n for English language:

Page translated to English

If we wanted to serve the page in two languages - we can, if we’d rather have ten different versions - it’s only a matter of adding a dictionary of placeholder translations for each new language, the rest is Java magic.

…and it’s changed

The most important thing that we need to address in our applications and tools is change. Change is the only constant, but what can actually change? From my experience - everything. As a developer you are dependent on a “client”, which can be not only a person or a company that wants you to create an application based on specification, but also any user of your tool or framework if you’re creating one or even people using your open-source project. All of them have some requests and requirements. Requirements like to change. You and your code have to be ready for that.

The placeholders used in the example above look fine, but maybe there’s a big website, which has its placeholders written as

--this.is.a.placeholder--

and we’d like to be able to process it. Or maybe we’d like to translate a React project, which is based on such tags:

<Trans>translation.placeholder</Trans>

Another thing - translation dictionaries - should we use a property-like format, YAML, JSON or something else? The best idea would be to start from a simple properties file, but also to have in mind that the format can be really anything that can be translated into a key-value map.

What else could change? File loading - we assume translating one file at a time, but maybe we should scan a directory recursively for files matching a pattern? Application format - a simple tool run from the command line is assumed to be enough, but what if we wanted to make it a web application with a nice graphical interface? Should we think about splitting into microservices? Actually, the programming language we’re writing in could change and the code should be ready even for that.

Testing stuff

One more thing that’s related less to the OOP paradigm and more to programming in general is writing tests, yet it will be somehow covered in this series. I’m not saying 100% coverage in a Test Driven Development manner is a must. I just want to show you how important the tests are not only when it comes to “just” checking if your application works as expected. Thanks to tests you can write a much better API, you can actually prepare the low level software architecture and finally you can perform any refactor you want without worrying much about breaking something and not knowing about it. Tests do not give you a hundred percent confidence and should not embolden you, yet without them the project may and will eventually come to a state, when nobody wants to even add new functionality, let alone refactor the code or migrate to newer JDK or dependency versions.

Go to main page Next post