Hi Boris, nice that you're trying something new! As a lot of people say, learning a new language probably will improve your skills at your "first" language even if you don't use the new one during your daily work.
For the moment, I intend to use the same organization for my Go project but I'm a bit confused by the fact that Go files are just a way to split the code but not to isolate it from the rest of the code.
It depends on how you organize your code.
If two files belong to the same package then yes, the splitting is just logic, but they are technically the same unit of work (package) to begin with.
The convention is to name the package with the same name of the directory those files are in. So if you have a directory "store", all the files inside it should belong to the store package. You should also avoid mixing files from different packages in the same directory.
What I mean is that in PHP or any other OOP language, if I put a class in a file, it gets isolated from other classes (except public properties & functions). In Go, if I split my code in two files inside a given folder, it will be re-assembled by the compiler as if it was a single file. Does it mean that I need to create sub-packages for each of my files? I don't think so, but it's too early for me to answer.
Encapsulation in Go is pretty straightforward. In each package, everything whose name starts with a lowercase letter is private to that package, everything with a uppercase letter is visible to other packages, and can be imported.
So func privateFunction() {} will be accessible only inside your package but func PublicFunction() {} can be used in other packages.
To organize a Go project I googled a bit but ended up copying how Go projects on Github organize their code (and failed to adhere in a way). There's no single way but popular Go projects on GitHub are as good a starting point as any.
I've been an OOP developer (PHP, Java) for 15 years now, so switching to a language like Go is not easy. The most difficult is to forget all about classes and objects.
A note: there's not a single way to do OOP, the class based paradigm popularized by languages like Java is definitely the most famous known but you can do OOP in many different ways. Strictly speaking OOP is about objects (and their relationships), not about classes. You need to have objects, with a state and with methods that can operate on such state and alter it. Objects can inherit behavior and state from one another. JavaScript is probably the most famous example of OOP done without classes (well, until ES6 but if I remember correctly that's just syntax on top of prototypes).
Go has taken some concepts from OOP: you have methods that operate on structs that hold data. There's no direct inheritance, though you can use composition to build a new struct from another one (and "inherit" state and methods).
Polymorphism is achieved through interfaces.
So, is Go OOP? Probably. The official FAQ has this to say:
Thus, I'm beginning to play with goroutines and channels...
Hi Boris, nice that you're trying something new! As a lot of people say, learning a new language probably will improve your skills at your "first" language even if you don't use the new one during your daily work.
It depends on how you organize your code.
If two files belong to the same package then yes, the splitting is just logic, but they are technically the same unit of work (package) to begin with.
The convention is to name the package with the same name of the directory those files are in. So if you have a directory "store", all the files inside it should belong to the
storepackage. You should also avoid mixing files from different packages in the same directory.Encapsulation in Go is pretty straightforward. In each package, everything whose name starts with a lowercase letter is private to that package, everything with a uppercase letter is visible to other packages, and can be imported.
So
func privateFunction() {}will be accessible only inside your package butfunc PublicFunction() {}can be used in other packages.To organize a Go project I googled a bit but ended up copying how Go projects on Github organize their code (and failed to adhere in a way). There's no single way but popular Go projects on GitHub are as good a starting point as any.
A note: there's not a single way to do OOP, the class based paradigm popularized by languages like Java is definitely the most famous known but you can do OOP in many different ways. Strictly speaking OOP is about objects (and their relationships), not about classes. You need to have objects, with a state and with methods that can operate on such state and alter it. Objects can inherit behavior and state from one another. JavaScript is probably the most famous example of OOP done without classes (well, until ES6 but if I remember correctly that's just syntax on top of prototypes).
Go has taken some concepts from OOP: you have methods that operate on structs that hold data. There's no direct inheritance, though you can use composition to build a new struct from another one (and "inherit" state and methods).
Polymorphism is achieved through interfaces.
So, is Go OOP? Probably. The official FAQ has this to say:
Have fun, remember that concurrency is not parallelism...
If you're interested in my initial experience with Go I documented it here:
Seven days of Go
rhymes ・ Mar 22 '18 ・ 11 min read
Thanks a lot for your detailed answer!
I'll take a look at your post.
I knew about functions' visibility with upper/lower case and I found it was a great way to simplify the code readability.