CDI helps us getting our object trees wired up und ready to start. As soon as we spin up our application, CDI makes sure that every created object gets its dependencies injected. There is, however, one limitation: Once our application starts running, object creation is performed only at certain events by the container, (application startup, conversation start, incoming request) Now what about the cases, where we need to create objects outside of these events, but still want CDI to make sure, that the objects get their dependencies wired up correctly? What we need is an implementation of the factory pattern that lets us create CDI managed objects (or beans, to use the JavaEE jargon).
Express is an unopinionated framework which means that it doesnt require you to follow a certain regarding your project layout. You are free to organize your code in any way you want.
While programming my first programm with Go, I wanted to create an abstraction layer between my domain logic and the actual data sources. In my day work I would use a Java interface to do that. Piece of cake! So why not using Go interfaces just like I would use them in Java? Go does a great job letting interfaces look and feel like pointer to base classes/interfaces, but I encountered a situation where they did not behave like I expected.
Programming has always included the work of managing the location of our source code. After all, the toolchain needs to know where to find our source code. Let’s see how wants to help us here.
Let’s review how Go lets us handle the basic I/O Operations. In this post we will have a look at the functionality Go offers us to handle operations with files.
This is the first post of a series where I try to get my head around Go. Go seems like an exciting alternative to all these OOP languages around. Especially the mechanics for concurrency, which they came up with, using channels. Chances are that it will irritate me more than anything else at first. But lets take one step at a time and start with the basics.