So I want to start my blog with one of the arguments that have thrilled me in recent times more than anything else in the programming world: the web app vs native app thing. We’re obviously focusing our attention on mobile platforms, as no one need someone explaining how much better it is to develop web-based apps for desktop than native ones. Software companies just shifted their efforts from native/only one OS compatible/hard to keep updated/too much influenced by local machine performances apps to the web (especially after that wonderful browser called Firefox came and thaught to Microsoft and friends how a decent browser should work -a lesson they still seem not to have learnt); and, in my memory, that shift began from the years 2006/07 on.

Would you have ever used -or, even known- Facebook if it only was a software to be installed on your Windows/Mac/Linux? I have reasons to think the answer is no. So, why are we talking again about the best choice between native and web Web app on BlackBerryeven for apps we know there’s no other way to succed than using the web as their main platform? The answer is quite simple: mobile devices. Or, to be more precise, the companies that make the OSs running on such devices. It’s not needed to be said that Apple gets a huge amount of money from the apps that developers publish on their App Store. It’s $99 per year, and 30% of every sales generated in-app. So, whilst desktop browsers have reached a level that allow you to develop practically everything using the web as your platform, mobile browser have not yet reached the same level. And, while companies like Apple and Google are getting a lot of external pressure to adopt the new HTML5 standards and to make their mobile browser acting just like their desktop versions do, they hesitate because they know they can get no revenue from people developing mobile web apps instead of native ones, and their OSs would also lose their uniqueness from the moment apps begin to work on any OS that have a decent and updated browser.

But in my opinion things are -slowly- changing. Firstly, since version 4.0 of Android, Google introduced Chrome for Android, although it is not yet the default browser (with the exception of their Nexus 7), but it is obviously going to become it. And there are reasons to imagine they will at one point take their Chrome web store (where you can publish, and even sell, your web-based apps) on Android, and that I think is going to be breakthrough. Mozilla’s doing the same with Firefox, and it’s not a scoop that they will introduce their new Mozilla Marketplace (something similar to Chrome web store, but with a few other interesting features). Even Apple’s very very slowly improving Safari mobile (it’s to be said that they’re the only ones with that cool option “Add to home screen” on the main menu, which lets users create an icon launcher of your web app, just like a native app). Also, the next BlackBerry 10 browser seems to be very advanced, and the fact that Mozilla’s going to launch their Firefox OS (which runs completely on HTML5) is simply exciting.

Conclusion

There are reasons why web apps on mobile have not succeded as they should until now, and they do not depend, in my opinion, on the web potentialities themselves, but on the OSs producers willingness. But there are also a lot of reasons for starting to seriously think about developing HTML5 cross-platform web apps, as things are going to change a lot in the next months, and it might be a huge waste of time (and money) to employ your resources in developing a native app for iOS, one for Android, one for BlackBerry and Windows Phone (not to say that in many cases smartphones and tablets with the same OS may require a different app to be developed).

 

It’s about a month ago that I came to know that Larry Ullman, a web programmer and writer of wonderful tutorials/books, was about to write a new book on the Yii framework, my favourite PHP framework at all.

While there’s no doubt I will be one of the firsts to buy it, I suggest to everyone interested in (and/or actually involved with) programming with PHP and using a framework to make your webapps more stable, simple to keep updated (especially if you work with a team) and stable, to read Larry’s incredibly clear and well written “Learning Yii framework” series on his blog. Should you like it, you may consider to buy his next to be published book.

The Yii framework was created by Qiang Xue, a developer previously involved in the Prado framework. «Yii is a free, open-source Web application development framework written in PHP5 that promotes clean, DRY design and encourages rapid development. It works to streamline your application development and helps to ensure an extremely efficient, extensible, and maintainable end product.» (source: yiiframework.com/about/).

Other books on PHP from Larry Ullman:

3: http://www.amazon.co.uk/gp/product/0321656229/ref=as_li_tf_tl?ie=UTF8&camp=1634&creative=6738&creativeASIN=0321656229&linkCode=as2&tag=marctroi07-21

title: 'Yii: XML generator' author: Marco Troisi layout: post date: 2012-10-27 url: /xml-generator-yii-framework/ categories: - PHP - Tutorials - Yii Framework

title: A List Apart author: Marco Troisi layout: post date: 2012-11-10 url: /a-list-apart/ categories: - HTML5 - Mobile

title: I got a Rasperry PI! author: Marco Troisi layout: post date: 2013-01-05 url: /i-got-a-rasperry-pi/ categories: - Raspberry PI - Tutorials tags: - raspberry pi

title: How to set up a full web server on a Raspberry PI author: Marco Troisi layout: post date: 2013-01-16 url: /how-to-web-server-on-raspberry-pi/ categories: - Raspberry PI - Tutorials tags: - apache - lampp - mysql - php - raspberry pi

title: Make your website available offline with HTML5 author: Marco Troisi layout: post date: 2013-04-12 url: /make-your-website-available-offline-with-html5/ categories: - HTML5 - Mobile - Tutorials tags: - appcache - chrome - firefox - html5 - manifest - mobile - offline

</html>

The .appcache extension is actually not mandatory, but it’s the W3C standard, so you better adopt it in order to avoid incompatibilities with strict standard-observing browsers. The manifest attribute in a web application can specify either the relative path of a cache manifest file or an absolute URL (but they must be from the same origin as the application).

It’s important to know that this manifest must be included in each and every page that you want to be cached, and you don’t have to list those pages in the manifest, because they will be automatically saved as the user visit them.

The cache manifest file must be served with the MIME type text/cache-manifest. In Apache, you can do that adding the following line to your .htaccess file:

AddType text/cache-manifest .appcache

The Appcache manifest file

The Appcache manifest file is a simple text file that lists the resources (identified by URI) that you want the browser to cache for offline access. The following is an example of a manifest file:

CACHE MANIFEST
# mywebapp.appcache v1
# this is my cache manifest 
fileindex.html
cache.html
style.css
image1.png

# Use from network if available
NETWORK:
network.html

# Fallback content
FALLBACK:
/ fallback.html

It’s vital for the cache manifest to be identified as such to have CACHE MANIFEST as its first line. All the resources listed after that line are going to be cached.

The NETWORK section lists all the resources for which a network coverage is required, and you don’t want the browser to save them and use the cached version.

In the FALLBACK section we’re going to list the pages that should be showed when a certain resource is not available. In our case, we decided to show “fallback.html” for every resource not available (“/“).

You can also add a further section CACHE, which will work just as the lines after CACHE MANIFEST. All the three sections CACHE, NETWORK and FALLBACK are optional and can be declared more than once in the manifest file.

Testing!

If you think that this is going to work at the first attempt you’re probably crazy. The smallest error in the appcache manifest file will actually prevent your application to be locally cached on a device. In such situations, tools like Manifesto (http://manifesto.ericdelabar.com/) are simply priceless and save you a lot of time and headaches.

Firefox and a few other browsers display a notification bar the first time a user loads an application that uses the application cache.

[UPDATE:  Since v. 26, there is no longer a notification bar on Firefox when websites use appcache]

See also

title: 'WordPress and Ghost: a CMS vs a blogging platform' author: Marco Troisi layout: post date: 2014-01-01 url: /wordpress-and-ghost/ dsq_thread_id: - 2100460454 categories: - HTML5 - Javascript - node.js - PHP - Software Development tags: - ghost - node.js - php - WordPress

title: 'Writing for Milk & Honey Mag' author: Marco Troisi layout: post date: 2014-02-28 url: /writing-for-milk-honey-mag/ dsq_thread_id: - 2336984874 categories: - News

title: How to use Fat Free framework from the command line description: "A simple tutorial that will enable you to use Fat Free framework from command line in just a few minutes." author: Marco Troisi layout: post date: 2014-05-04 url: /how-to-use-fat-free-framework-from-the-command-line/ dsq_thread_id: - 2659771718 categories: - Fat Free framework - PHP - Tutorials

title: Moving to Germany! author: Marco Troisi layout: post date: 2014-08-29 url: /moving-to-germany/ dsq_thread_id: - 2969179948 categories: - News tags: - berlin milan moving job

title: What would your ideal Publishing Platform look like? author: Marco Troisi layout: post date: 2014-10-23 url: /what-would-your-ideal-publishing-platform-look-like/ dsq_thread_id: - 3147392879 categories: - Software Development tags: - cms - ghost - github pages - jekyll - medium - octopress - WordPress

title: My Two Cents on Go description: 'Coming from PHP, my impressions on Golang and a quick script in both languages to test productivity and performance.' author: Marco Troisi layout: post date: 2014-11-20 url: /my-two-cents-on-golang/ dsq_thread_id: - 3245735799 categories: - Golang - PHP - Software Development tags: - benchmark - go - golang - php

title: How technology will open even more doors for people to work together author: Marco Troisi layout: post date: 2015-03-09 url: /how-technology-will-open-more-doors-for-people-to-work-together/ dsq_thread_id: - 3580385515 categories: - Opinions - Startups - Technology tags: - companies - specialisation - startups

title: 'Microservices: A Quick Introduction' description: 'An overview of what Microservices are and why they can be a good choice for your next application.' author: Marco Troisi layout: post date: 2015-03-18 url: /micro-services-a-quick-introduction/ dsq_thread_id: - 3605512010 categories: - Software Development - Technology tags: - microservices

title: 5 Tips for becoming a Productive Programmer description: "Being a Productive Programmer is key to delivering better results. Here are 5 tips that will help you become one, and achieve more." author: Marco Troisi layout: post date: 2015-03-30 url: /productive-programmer-5-tips/ categories: - Opinions - Productivity tags: - discipline - efficiency - productivity - programming - quality - relax featured_image: "https://www.marcotroisi.com/wp-content/uploads/2015/03/mac-glasses.jpg"

title: An example of a Microservice description: "I built a Microservice to use as an example to walk through. See how easy it is to build one for yourself!" author: Marco Troisi layout: post date: 2015-04-14 url: /an-example-of-a-microservice/ categories: - Fat Free framework - PHP - Software Development - Technology tags: - microservices - microtranslator - php featured_image: "https://www.marcotroisi.com/wp-content/uploads/2015/04/microtranslator.png" --- After writing on Microservices, I received a few feedbacks from people who found the topic fascinating but struggled to see how to effectively apply it in reality. So I decided to develop a little microservice, to use as a practical example.

Introducing MicroTranslator

MicroTranslator is a microservice that I have built, which is supposed to handle locale and translations in an application. Its tech stack is the following:

Note: at the time of this writing (14 Apr ’15) I am still working on MicroTranslator. It will be production-ready (documentation included) in a few days. Sorry about that!

It comes with REST API

MicroTranslator provides simple-to-use REST API. For this reason, you need to know little to no PHP to use it. Simply fire up an instance of PHP on whatever machine you like, and then use the APIs to get the translations on the other Microservices that compose your application.

Now this is important, in my opinion. It means that you can quickly begin working on your application without having to focus on a tedious task such as handling translations, but also that, at any point in time, you can completely get rid of it and rewrite it with, perhaps, a faster language. Or you can simply upgrade your hardware and keep relying on it.

“I could have done this myself”

You may think now, “why should I use your stuff when I can write my own translation manager, using the tools that I like the most?” The simple answer here is “You shouldn’t (use my translation manager)!”

But I would also like to point out that, unless translations represent the core of your application, there is no reason why you would want to waste your time rewriting a library that does the same thing. But even if you do, what you should be avoiding is to tie it all up with the rest of your application. Using a Microservices architecture will allow you to replace parts of your application quickly and seamlessly. And, it will give you the power of choosing the right tools, framework, database, etc for the task.

Point by point

Like I said, one of the reasons why I worked on MicroTranslator is because I wanted to create a real-life example out of my previous article on what is a Microservice.

Let’s have a look at the points I outlined back then:

  1. It is a Stand-alone service/application.: Yes, MicroTranslator is stand-alone. It doesn’t need, and actually, it doesn’t want, to be included into your PHP application. You can connect to it, get and send to it all the data that you need, but you will not find MicroTranslator-specific code in your application. Just generic API calls.
  2. It is quick to (re)write.: Absolutely! I wrote MicroTranslator in a weekend plus a few other free hours during the week. You can totally rewrite it in a week or less as soon as you feel like it.
  3. It focuses on one task: It only cares about your translations. It doesn’t even want to know how you use them.
  4. It is Language-agnostic.: Well, MicroTranslator is clearly written in PHP, but you can use its APIs from application, regardless of the language/framework/tools you are using.
  5. It is aware of failures. This clearly depends on the rest of the application. But, for example, you can cache the translations that you get from MicroTranslator, so that, should it be unreachable at a certain point in time, you can still handle the situation graciously. One thing is sure: if MicroTranslator goes down, it won’t directly affect your main application.

In practice, it’s not that difficult

It’s amazing how simple things can look like when we see them in real-life examples. In fact, despite the buzzword-mania and all the hype around Microservices, something that we often fail to understand is how simple they are. Building a Microservice is as simple as a few days of work. Building an entire application based on a Microservices Architecture is as simple as being able to separate everything into small services/applications that are only concerned about one little thing, and they do that very well. This is, by the way, also one the keys of greater productivity.

Question: have you already tried to build a Microservice, or even an entire application based on a Microservices architecture? I would love to have a look and learn from you as well. Share your work on Facebook or Twitter.

In today’s article, I would like to talk about something which I see that, sometimes, developers aren’t too familiar with. Most of us know what the traditional concept of inheritance is: a child class extends a parent class. And, obviously, multiple children classes can extend the same parent class.

What some developers don’t seem to be always aware of (or, perhaps, they just aren’t entirely sure how to use it), is the idea of composition.

What is Composition

Composition can be explained by a child class “incorporating” one or more classes that it intends to extend. In other words, you are declaring inside your class, what other class’ methods do you want to be able to use, without having to strongly tie up your children class to its parent(s).

Has-a VS Is-a

A good way to look at Composition is to think of a class that HAS-A relationship with another class, rather IS-A “son” of that class. In this sense, when you use Composition, the class has an “identity” of its own, and it’s not to be seen as being “only” a son of that other class which it extends.

The Benefits of Composition

While I am not advocating for the complete elimination of traditional inheritance, there are benefits of using Composition that I would like to highlight. And, the way I see it, it is possible that once we realise the power of Composition over Inheritance, we may actually end up using Inheritance less and less. Here are the reasons why Composition is a good pattern:

  1. Flexibility: it is not by chance that I am giving this one the first position in my list. With Inheritance, as mentioned, you tie your Class up to another one, and you define even before starting to design your class, who is going to extend (be a child of) what. But, what happens if you wanted to only use some of the methods that your parent has? Or, on the opposite side, what if you had 5 children of which only 2 needed a couple of additional methods? These things would not have been a problem with Composition. But the truth is that Inheritance is often not flexible enough.
  2. Extension of Multiple Classes: who says you should only extend one Class? Why couldn’t Corolla be a son of Car but also of Toyota at the same time? That obviously makes sense, but it’s normally not possible in traditional programming languages. Interfaces can give us some help here, but they don’t actually implement the methods we need.
  3. Avoid duplicates: Like in the previous example, if we were to use Interfaces for our Corolla Class, we would end up having to write some of our methods for our Yaris or Sedan Classes. That’s not cool. Duplicating code is not a good idea.

There are other benefits to using Composition, but those are the ones I feel are the most worthy of being highlighted here.

How do I use Composition in [insert programming language here]

Composition is available out of the box in many of the mainstream languages. It can be implemented in the form of a Trait in PHP, Python, Scala and others; It’s called a Module in Ruby, and a Role in Perl. Javascript, as per usual, has unique ways to implement Composition, but it’s there. Finally, it’s interesting to note that Go doesn’t even consider Inheritance as an option; Composition is the only game in town, and it’s called Embedding.

Question: what are your thoughts on Composition over Inheritance? Where is it best to use one over the other? Share your ideas on Facebook or Twitter.

More to read on Composition over Inheritance

A while ago, while looking for experiences of companies actually transitioning into a Microservice architecture, I stumbled upon this nicely written, real-world series of articles from Matt Heath, published on the Hailo tech blog. The articles talk about their moving from a mostly-PHP, monolithic architecture, towards one based on Microservices.

It is very interesting to read about the challenges of a company that started that everyone else, and then had to face the inevitable problems of scalability and code maintainability. It is also stimulating to see how they answered the questions almost everyone asks when trying to move into a Microservices architecture.

If you are interested, read the articles, starting from the first one: A Journey into Microservices, and then go ahead with part two and part three.

Question: have you worked on a transition to a microservice architecture? What has your experience been? Share your thoughts on Facebook or Twitter.

Featured photo from the Hailo website

7: https://twitter.com/intent/tweet?original_referer=https://www.marcotroisi.com/hailo-journey-into-microservices/&source=tweetbutton&text=%3F&url=http://goo.gl/MB66xW&via=marcotroisi

title: The Ethics of Code Reviews description: "Code Reviews are a powerful tool not only to improve the quality of our code, but also to make our teammates' life easier. Be a constructive Code Reviewer." author: Marco Troisi layout: post date: 2015-05-06 url: /the-ethics-of-code-reviews/ categories: - Opinions - Productivity - Software Development tags: - code reviews - reviewing - team

title: Apple and the battle for privacy author: Marco Troisi layout: post date: 2015-06-23 url: /apple-and-the-battle-for-privacy/ categories: - News - Opinions - Technology tags: - apple - encryption - google - privacy - security - tim cook

title: What can we learn from Periscope author: Marco Troisi layout: post date: 2015-09-04 url: /what-can-we-learn-from-periscope/ categories: - Opinions - Productivity - Software Development - Startups - Technology tags: - business - development - perfectionism - periscope - twitter

title: A Question about Microservices description: "A question on how to approach a microservices architecture, authentication, and over-bloated frameworks." author: Marco Troisi layout: post date: 2015-09-24 url: /questions-about-microservices/ categories: - Software Development - Technology tags: - authentication - golang - kong - microservices

title: Technical debt is not a unicorn description: "Technical debt is not an abstract concept. It has real and serious effects, and can be avoided." author: Marco Troisi layout: post date: 2015-11-04 url: /technical-debt-is-not-a-unicorn/ categories: - Opinions - Software Development - Startups - Technology tags: - architecture - refactoring - technical debt featured_image: "https://www.marcotroisi.com/wp-content/uploads/2015/11/sanfrancisco_800.jpg"

title: Microservices won’t improve your code quality description: "I am very excited about microservices, but they are not going to make my code quality better. That will always be up to the programmer." author: Marco Troisi layout: post date: 2015-12-16 url: /microservices-wont-improve-your-code-quality/ categories: - Opinions - Software Development - Technology tags: - architecture - code quality - microservices featured_image: "https://www.marcotroisi.com/wp-content/uploads/2015/12/microservices-wont-improve-code-quality-small.jpg"

author: Marco Troisi categories: - Software Development - Php - Opinions date: 2016-05-23T08:34:57+01:00 description: How to write high quality Object Oriented Code draft: false layout: post tags: - OOP - object oriented programming - Php - Javascript - Golang title: Healthy OOP url: /healthy-oop-object-oriented-programming/ --- I enjoy writing code in an Object Oriented fashion. Thinking in terms of objects gives me a model that, when followed consistently, ends up producing code that is well organised, and that I know to be relatively easy to understand, test, and refactor.

Now some people would want to argue that OOP doesn't really work and/or that we don't need it anymore to build modern software. While I by no means think or want to say that OOP is the ultimate paradigm, I would definitely want to maintain that it is helpful and that a bunch of procedural code, however nicely organised (even if that means microservices), is not the answer.

The problem with a lot of the criticism that OOP gets, is that it tends to refer to things that in popular programmer culture have become somehow associated with OOP (like the use of ORM), while that isn't really the case.

Object Oriented Programming done well, or what I call Healthy OOP, comes with a lot of benefits. Here's a number of things everyone needs to know in order to write good quality code in an OOP way.

## ORM? No, thanks

The main problem with using an ORM in an Object Oriented software is, to put it simply, that ORM-related code is overwhelmingly not Object Oriented. I am not saying it is bad per se, and I am not buying into Orm Hate just for the sake of it. But, at least if you're trying to write good quality Object Oriented code, using an ORM is probably not the smartest choice out there.

The biggest issue here is that when you use an ORM you are encouraged to create what you are told to be objects, and use them as mappers to a database table (or collection). While this may sound very convenient on paper, in practice it will inevitably lead you to create big classes, at least as big as your database tables.

Not only that, but it will also encourage you to skip the "thinking" process, or the architectural side of things. In other words, when all you have to do is to replicate the exact same structure of your tables into classes (and please don't make the mistake of thinking of them as objects, because they are not), and when most of this is probably done for you by some sort of automated table-to-class generator, then there is almost no point in which it makes sense to sit down and thinking through what's the appropriate architecture and the best organisation for the software. You're going to create a bunch of classes that represent your tables, and you'll just work with them as they are.

But database tables are meant to be relatively big collections of data, in a structured and easy-to-query fashion. There is very little correlation between that and your Objects, which are supposed to be kept small, cohesive, easy to extend, refactor and manipulate. Not to mention the need to keep your architecture clean, which won't happen if you start tightening up your code with whichever database you've decided to use. It will eventually cause technical debt, and that simply tells you something went wrong at an architectural decision level.

So there is a case to be made against the use of ORMs in general, but even more so if you're doing OOP.

A note of clarification is due here: if you're building software with a clean architecture, and you really, really want to use an ORM, there may be a place for it, and that's at the level of the Interface Adapters, where you would build proper interfaces between your Objects (at the Entities and Use cases levels) and your ORM "mappers". If you have no idea what I'm talking about here, please do yourself a favour and read Uncle Bob Martin's article on the clean architecture.

Personally, my favourite approach would be to build SQL-speaking Objects, as suggested by Yegor Bugayenko in both his blog and his latest book.

At any rate, if you decide to go with an ORM, that's entirely your prerogative, and it's not wrong in itself. But make sure you're building things in a clean fashion, and don't use the ORM-generated mappers as your main objects for your business logic.

## Accessors and mutators vs useful methods

Accessors and mutators, also known as getters and setters, are incredibly popular today. Most IDEs will even automatically generate them for you, which make them even more tempting, as you can have them there and ready to use in just a few seconds.

Why then take the time to think about more appropriate, expressive and useful methods? There are a few advantages:

In OOP, it's better to expose just a limited number of highly focussed and expressive methods, and handle everything else internally.

As a representation of a real world entity, your object should be able to do more than just exposing a bunch of variables through getters and setters.

Ultimately and probably the biggest benefit is that by following a more expressive approach you are always going to force yourself to think about the internal architecture of your object (as opposed to not delegating its functionalities to automatically generated getters and setters) by exposing only relevant information via nice and expressively named methods.

A great approach to doing this is to first create an interface where you would define all the methods that will be exposed by your object. Then, create your object, making it implement the interface you just defined, and then start filling those methods with actual functionalities, all the while writing your tests for the methods you are working on.

## Real world entities are better than Services

This is a point that I keep coming back to: take the time to think about your objects and the overall architecture.

You should see your objects as real world entities, rather than data structures, "helpers", or "services". So, again, instead of replicating your database tables, think about real world examples that would make sense in your case, and expose real behaviour, rather than a bunch of accessors.

Instead of building a class PasswordEncrypter (or class PasswordEncryptionService) that takes in passwords and encrypts them using the algorithm of choice, think in terms of small, more maintainable, composable and extendable objects.

Why not defining a simple interface like this:

type EncryptedPasswordInterface interface {
  func encryptedValue() string;
}

and then have simple, small classes implementing that interface to encrypt a given password using a certain algorithm. Something like Sha1EncryptedPassword. And then something like Sha1EncryptedPasswordWithSalt.

Following this approach, you'll never end up with overbloated, ever-growing "Services", which are really Do-it-all classes, a blatant violation of the Single Responsibility Principle.

The main point here is that you want to build in a way that always allows you to keep things small, composable, and breakable into smaller pieces. Your want your objects to be very specific and single-focussed.

The problem with a PasswordEncrypter would have been that even if at the beginning it supported only one encryption algorithm, the number of such algorithms could have grown with time, and there would have been no obvious way to break things into smaller pieces.

Notice that I am not saying that it couldn't have been done, what I am saying is that there wouldn't have been an obvious way to do it, which is after all my main point of contention with OOP: it's a system that gives you a more obvious way to consistently keep your code organised, easy to break into smaller pieces, easy to understand.

In the example above, the real world entity is the encrypted password, as defined by the initial interface. It is very easy to imagine that this password could have been encrypted with as many encryption algorithms as you can think of, and all you need to do is to have an object representing each one of those algorithms. Want to encrypt a password with an algorithm on top of another one? Create an object for it (probably the best approach), or do something like this:

md5Password := NewMd5EncryptedPassword(unencryptedPassword);
encryptedPassword := NewSha1EncryptedPassword(md5Password.encryptedValue);

In the above example, encryptedPassword will have double encryption, MD5 and SHA1. A different approach would be to build a decorator, which is an invaluable tool in OOP. It would look like this:

// Constructor for Sha1PasswordFromMd5
func NewSha1PasswordFromEncrypted(md5EncryptedPassword *EncryptedPasswordInterface) (p *Sha1PasswordFromEncrypted) {
  return &Sha1PasswordFromEncrypted{md5EncryptedPassword};
}
// Sha1PasswordFromEncrypted is a decorator that takes as an argument
// EncryptedPasswordInterface and returns this value with Sha1 encryption
type Sha1PasswordFromEncrypted struct {
  var Md5EncryptedPassword *EncryptedPasswordInterface;
}
func (p *Sha1PasswordFromEncrypted) encryptedValue() string {
  // here encrypt Md5EncryptedPassword with sha1 and return value
}

As you can see, Sha1PasswordFromEncrypted is a decorator that takes as a parameter an object that implements its very same interface, EncryptedPasswordInterface. It then applies Sha1 encryption on top of the already existing one, and returns the encrypted value as demanded by its interface.

These are all examples of course, and you would have to use the best approach that works for what you're trying to build. But the main idea is to build objects as representations of real world (not necessarily physical) entities.

## Use interfaces

Interfaces can be a controversial topic. Oddly enough, I've found myself having to justify the use of interfaces or making the case for them to other developers more often than would have been reasonable.

Unfortunately, some languages (see Javascript) don't even come with first class support for interfaces (although the excellent Typescript does), whereas in some other languages, like PHP, interfaces were a later addition and some developers don't seem to have ever taken the time to study the matter and understand what the use cases for them are. Golang has had support for interfaces since the beginning, and their use seems to be part of the language's ethos.

There are many reasons to use interfaces. Personally, I tend to create an interface for virtually every object that I create. This has several benefits:

No matter what language you're working with, make it a point to have an abstract signature of your object before you go ahead with the actual implementation.

## Conclusion

There are other good practices that can be kept in mind while doing OOP, such as aiming for object's immutability. But I believe that by at least keeping in mind the practices listed above, you can write high quality Object Oriented Code that makes sense and that you can be proud of.

Further reading:

## Why you need the best tools

Hardly any job can be done without the right tools. You always need something to do what you do. This applies to virtually everyone, from a dentist to a photographer, a journalist to a mathematician. And of course the software engineer is not excused.

Give an old, cheap, faulty camera to a great photographer, and he'll come back to you tired and frustrated, with only a few nice photos and more bad ones than what would be considered acceptable from a professional. Give a fantastic camera to a decent photographer who knows how to use it, and he'll come back with loads of good photos, a few amazing ones, and perhaps a couple of not so great ones.

That's why I'm always amazed at how many software engineers and employers tend to overlook the importance of using the right tools. It's simply astonishing. One reason for that, as I understand it, would be fragmentation, or diversity of opinions. A developer might like a certain tool more than another one.

But here's where I think the controversy starts: it doesn't really matter what you think is better. What's better is what the industry decides it is. Look at it this way: if you're a photographer and you think the best way to take photos of your clients is on a 15-years-old Polaroid, does that make it the best tool for the job? I mean, your customers are paying you real money for professional, high-quality photos that they can not only print, but also store on their hard drives. And you give them a bunch of low quality photos printed from an old instant camera. Does this sound right to you? It doesn't to me.

In the same way, it wouldn't matter how cool and geeky it makes you feel to work on a Raspberry PI Model A. The truth is that you're going to spend twice as much time doing what you have to do, because of the inherent slowness of such a small machine; plus you won't have state-of-the-art tools to help you write code, test, debug and so on, because most development software isn't yet supported on an ARM architecture.

As a software engineer, I need to be an absolute professional in what I do. And I need to be in line with what the industry thinks are the best tools.

These things may and will change in the future, but as things stand now, the industry seems to be saying the following things:

## Writing code

The best way to write code is through a powerfully integrated IDE like the ones from JetBrains, or a faster text editor like Sublime Text or Atom, provided you have the right plugins for your language of choice installed. No, you can't use Notepad, that's just not good enough!

## Version Control

The industry is also saying that the best version control system is Git. It's the system that the biggest number of companies and developers all around the world have found to be the most powerful one. While in terms of usage percentage it may still be fighting against SVN, a quick look at the projects that still use the latter will quickly reveal how the vast majority of them are only using it because of legacy. In other words, those are very old projects, and they were using SVN since before Git was even a thing. But then, why would they keep using such an ancient and inefficient system when there are plenty of ways to migrate to Git? This is something I don't fully understand.

## Code sharing and collaboration

Another thing the industry has been saying for a while now, is that the best way to share code is to use GitHub on top of the already-mentioned Git. Now, I understand that some companies may find that BitBucket or GitLab fit their needs better. But given the choice, and all things being equal, GitHub is the one. It's the most widely supported and most well known collaboration platform out there.

## Code review

Tools for Code reviewing are also important, and they are strictly related to collaboration tools in that the best way to review your peers' code appears to be yet again GitHub. Their code reviewing tool is just too good, and it's simply too easy to use when you're already on GitHub, so there's just no need to be looking for anything else.

## Bug tracking

For a project to work well, you're going to need some kind of bug tracking system. I've personally had to work with several of them, from Redmine to Trello, from Jira to YouTrack, and of course GitHub Issues. Here I'd have to say that I've had decent experiences with pretty much all of them: once you get used to one of them, they can all do their job, no question about it. But there seems to be a general consensus on Jira being the best tool out there, and I think that's right. While every other platform I've used was good enough, every time that I come back to Jira after a while, I am just amazed at how powerful and functional it is. And, every time I use a different tool after having worked with Jira for a while, it always takes me a while to adapt and a good dose of resignation at knowing that I'll be missing some Jira's unique features.

## Continuous integration

Continuous integration is another critical topic. Here, what the industry appears to be saying is that you need to do it. There is no point in looking at tools here if one doesn't even believe in the usefulness of doing Continuous integration. It will make it incredibly easier for you to keep track of what is going on, and to find bugs before they get deployed on production. As far as tools go, no longer that a few years ago the only viable option was to set up Jenkins on some server of yours, and spend days trying to make it work, not to mention the fact that someone will have to keep an eye on it because something might always break. This problem has now been largely solved by the emergence of many excellent, cloud-based CI platform. Prices are pretty fair, usually free for open source and in some cases free for small private projects as well. The most complete, well documented and most supported of them is undoubtedly Berlin-based Travis. Recently, CircleCI has also attracted a lot of attention, mostly because it's very fast, and because it's free for small projects (i.e. if you only run one build at a time). I haven't found their documentation to be outstanding, and there's not (yet) much help to be found online, but with a bit of effort I've always been able to make it work nicely.

## Static analysers

Something else that you should make sure to have in your stack at some point: static analysers. These tools, while obviously far from replacing the need for writing clean code on the side of the programmer, are very helpful in pointing out a lot of code smells, therefore helping immensely especially during (or before) the process of code reviewing. Here things may change based on the language you're using. CodeClimate supports a lot of languages, and it's probably the one you want to go for in many cases. Being open source, you can either download it and use it from your command line, or pay for the cloud version, which offers a nice UI and it's perhaps a better deal overall. I'm also a big fan of Scrutinizer, but it supports only a limited number of languages. The best way to make static analysers part of your development process, is to add it to your GitHub build. This allows you to check in real time, as you create a Pull Request, the quality of code you're trying to push to the master branch. Moreover, you can make this even stricter by using GitHub's Protected Branches feature, and disallowing you and your collaborators from merging into the master branch unless a certain level of quality has been reached.

## Conclusion

While it's totally understandable that from time to time it might not be possible for someone to follow the above guidelines in their entirety, it's probably worth it to ask yourself if there are good reasons for not following them. If there aren't, then it's definitely time to consider implementing some change.

As a software engineer, there's no reason to be left behind by the industry and, most importantly, not to use the right tools to deliver the best possible work. As a company, there's no reason why you wouldn't make it possible for your people to work with the best available tools, making both them and your customers happier.