DEV Community

Cover image for Is Go an Object Oriented language?

Is Go an Object Oriented language?

Lukas Lukac on September 08, 2018

UPDATE: I updated the article with provided extra research on OOP therefore I am removing it from here, damn code duplication and continue in the original Medium article please!


Collapse
 
eljayadobe profile image
Eljay-Adobe

Note that KISS means "keep it simple stupid", rather than "keep it simple, stupid".

The former has the stupid referring to it. The latter has the stupid referring to the developer.

The origins of the acronym are in designing something so simple-stupid that it could be fixed in the field, with minimal tools, under combat conditions.

Collapse
 
web3coach profile image
Lukas Lukac • Edited

Hey Eljay, thx for feedback. Actually, any one of the forms is referring to someone being stupid. I think you misinterpreted it. As far I know, the comma should be there. KISS is an acronym for "Keep it simple, stupid" as a design principle noted by the U.S. Navy in 1960.[1][2] The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design, and that unnecessary complexity should be avoided. en.wikipedia.org/wiki/KISS_principle

Collapse
 
eljayadobe profile image
Eljay-Adobe

As per the URL you linked to, in the Origin section, pointed out that Kelly Johnson, lead engineer at the Lockheed Skunk Works, who coined the term, did not have a comma.

Thread Thread
 
web3coach profile image
Lukas Lukac

You are right! I didn't see the origin section. Good to know there are both alternatives and the without comma is actually the original one.

Collapse
 
alainvanhout profile image
Alain Van Hout

Wikipedia seems to disagree: en.wikipedia.org/wiki/KISS_principle

Collapse
 
theodesp profile image
Theofanis Despoudis • Edited

You forgot to mention that methods also can be applied to any type and not only Structs. For example this is valid:

package main

import (
    "fmt"
)

type Integer int


func (d Integer)Squared() Integer {
    return d * d
}

func main() {
    fmt.Println("Hello, playground")
    var d Integer = Integer(10).Squared()
    fmt.Println(d)
}

Collapse
 
web3coach profile image
Lukas Lukac

That is a great feature indeed you are right but not really forgot. I also didn't mention type functions, Interfaces etc. Maybe in another post :) The main goal is to show the the difference between a classical Struct and a classical Class. Assigning methods to primitive types is a bonus that normal OO languages don't have so not really necessary to compare as there isn't any comparison.

Collapse
 
thomasjunkos profile image
Thomas Junkツ • Edited

I would agree, that go is not object oriented as Java is. Java is the hardcore example, since classes are its pivot point. But if you compare it to python, which is considered object oriented, you find similar goals.
Python has no data hiding too - it was built for adults ;)

Go sacrifices not only encapsulation but on top even inheritance. Go designers have their lesson learned. Go favors composition over inheritance by design, there is only composition.

What go retains is polymorphism and its own flavor of duck typing.
If it walks like a duck and serveHTTP it must be a Handler of a server. But it could be anything.

I would call Go a pragmatic object oriented programminglanguage, if that wouldn't make a bad acronym.

Collapse
 
web3coach profile image
Lukas Lukac

Hey Thomas, I see your point but personally I can't agree Go is object oriented. Inheritance is not that useful, we all learned that therefore is not included in Go design. I would say Go is behaviour driven and has interfaces/typed functions to allow abstraction/extendibility/all kind of useful patterns for maintainable software. That's it. People are forcing the Object Oriented nature on it for no good reason imo.

Collapse
 
thomasjunkos profile image
Thomas Junkツ

Coming from the other side, I agree that go is as far from classical object orientation as e.g. Javascript is. And if you bring your OOP luggage with you, you are perhaps having a hard time.

Not to forget to mention, in Go are functions first class citizens and Go has (of course) closures.

It is hard to clearly categorize Go.

But "kind of" is good enough for me as a category.

Thread Thread
 
web3coach profile image
Lukas Lukac

Fair enough. I mean, the official Go resource I quoted in the article also categorized it only as "kind of" so you are not far away from official Go maintainers! :)

Collapse
 
web3coach profile image
Lukas Lukac • Edited

Hey Michael, thank you for the extensive feedback. I am definitely going to check the link citating Alan Kay and get back to you.

I agree I mainly compare to Java/PHP and C++ because that's the languages majority of developers are coming from when starting with Go and they bring with them the techniques that worked in such a languages.

For now, my main argument is, I left out a lot of things like inheritance, polymorphism etc because they are extensions of Objects but the main purpose of an Object is to represent state. Objects expose their API for communication but they mainly maintain the state.

Go seems to work better stateless imo. and the language is optimised for communication, impulses, clear input/output and such design differs greatly comparing to the way we are used to design, encapsulate Objects.

I don't see how Objects behaviour and assosicated techniques would be beneficial in Go world. I am not saying it can't be done, it can, but it doesn't fit.

I will update the article in the afternoon with your feedback (let me know if you would like to add something more) as well will point out clearly why I compare mainly to Java/C++.

UPDATE:

Actually from the source you provided, Dr. Alan Kay stated:

"OOP to me means only messaging, local retention and protection and

hiding of state-process, and extreme late-binding of all things."

  • communication is obvious
  • protection and hiding of state-process (encapsulation), and this was my main point. That's what Objects were mainly designed to do, which Structs were not. Therefore I don't consider Go as primarily OO language
Collapse
 
rhymes profile image
rhymes • Edited

I feel like OOP is more of a pattern/paradigm than a constraint. Some languages have constrained themselves to that single pattern but many (probably Go falls in this category) can be used as OOP, even if they are not constrained to it by design.

An example: the basics of OOP in Python and Ruby are implemented in the C layer. Is C a OOP language? Not really, but you can still use it that way.

Thread Thread
 
web3coach profile image
Lukas Lukac • Edited

Sure, fair point and it surely is not black/white binary answer. That's why the official Go doc states: "kind of". The question is, should you? ;) The only way to use Go as OO language is by abusing pointers for everything and that doesn't make too much sense to me.

Thread Thread
 
rhymes profile image
rhymes • Edited

ahhaha "should you" is another relative question :D

Thread Thread
 
web3coach profile image
Lukas Lukac

unfortunately :D damn IT.

 
web3coach profile image
Lukas Lukac

Would you add something more to the article? Actually it really enhances my historical knowledge of OOP evolution. I was always a huge fun of DDD. Although, what I also found are some good points why OOP sucks:

"I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras — families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting — saying that everything is an object is saying nothing at all. "

Collapse
 
bgadrian profile image
Adrian B.G. • Edited

No

Ah wait it was retorical question.

But .. as u said you can achieve some OOP practices and patterns, up to a point.

Ps: here is a talk called "SOLID in Go" to grasp the extent of the OOP concepts in Go.

Collapse
 
web3coach profile image
Lukas Lukac

Hey Adrian, thx for recommendation. I saw the talk few months ago actually, Is a nice talk. Even though SOLID is mainly OO concept I think it should be and can be generally applied to Structs as well as Functions. I prefer to apply it mainly on a Function level in Go.

 
web3coach profile image
Lukas Lukac

Hey Michael, I am not comparing primitive types and objects. I am saying object was designed to have a state and keep it. Struct is not. That's a huge difference. Go is suppose to be mainly stateless and work based on impulses, communication. input/output. Thx for reading!

Collapse
 
web3coach profile image
Lukas Lukac

Michael, I updated the Medium article and thanked you for providing the resource. I added also a link to your Twitter for more followers :)

Collapse
 
web3coach profile image
Lukas Lukac

@michael , actually, I am still updating the article, want to update it with more information, especially about the idea of "objects" outside of Java world or outside of a Go package. That can be explored way more and is important indeed.

Collapse
 
web3coach profile image
Lukas Lukac

Michael, you can check the article now. Let me know what you think. I extended on the history of OOP and connected more dots ;)

Collapse
 
jeancarlosn profile image
jeann

Very Interesting your post, I don't know this Golang, Thank you so much!

Collapse
 
buzzdan profile image
Dan Mordechay

Nice article!
Q: How would you do dependency injection without structs?

Collapse
 
web3coach profile image
Lukas Lukac

Thx Dan. Like you would normally do, pass it to a function!

Collapse
 
itsdarrylnorris profile image
Darryl Norris

Very good article. I like Golang. The more I work with Golang I feel like is too opinionated but that is the beauty of the language I guess.

Collapse
 
web3coach profile image
Lukas Lukac

yea... haha. But only at the beginning I would say. Once you crack the ideas behind is all straight forward, fast development :)

Collapse
 
ja7ad profile image
Javad Rajabzadeh

Just know Go language is Object-base ...