Go for Classic OO - Revision history

Adamcolton: /* Pointer Madness */

2016-08-11T16:58:13Z

Pointer Madness

← Older revision		Revision as of 16:58, 11 August 2016
Line 29:		Line 29:
	=== Pointer Madness ===		=== Pointer Madness ===
	A type and pointer to that type are not the same type. So Foo and *Foo are different types. This becomes important when fulfilling interfaces and there's one gotcha that can make it confusing.		A type and pointer to that type are not the same type. So Foo and *Foo are different types. This becomes important when fulfilling interfaces and there's one gotcha that can make it confusing.

			Apparently this isn't true any more???? I'd like to find the change log.

	== Techniques ==		== Techniques ==

Adamcolton at 16:55, 11 August 2016

2016-08-11T16:55:16Z

← Older revision		Revision as of 16:55, 11 August 2016
Line 26:		Line 26:
	== Types ==		== Types ==
	Now it gets fun and weird. In Go, you can define a method on any local type except an interface. Yes, you can define a method on a function, you can sub-type an int and put methods on that. Anything.		Now it gets fun and weird. In Go, you can define a method on any local type except an interface. Yes, you can define a method on a function, you can sub-type an int and put methods on that. Anything.

			=== Pointer Madness ===
			A type and pointer to that type are not the same type. So Foo and *Foo are different types. This becomes important when fulfilling interfaces and there's one gotcha that can make it confusing.

	== Techniques ==		== Techniques ==
Line 61:		Line 64:
	==== Struct and Interface Pair ====		==== Struct and Interface Pair ====
	Make the struct private and create an interface for it that includes all the public methods. Have the constructor return the interface rather than the struct. This can get a little annoying because you may need to keep casting back. But you can add a private method to the interface that returns the underlying type. Now a user will be unable to implement the interface outside the package and you'll have an easy casting method.		Make the struct private and create an interface for it that includes all the public methods. Have the constructor return the interface rather than the struct. This can get a little annoying because you may need to keep casting back. But you can add a private method to the interface that returns the underlying type. Now a user will be unable to implement the interface outside the package and you'll have an easy casting method.

			== Closing ==
			So GOO is not COO.

			Structs are a type that are a collection of fields. Any local, concrete type can serve as a method receiver. An interface defines a set of methods. Any type with those methods can be used to fulfill that interface.

Adamcolton at 16:48, 11 August 2016

2016-08-11T16:48:24Z

← Older revision		Revision as of 16:48, 11 August 2016
Line 23:		Line 23:
	=== Use a lot ===		=== Use a lot ===
	It's ok to use a lot of small interfaces. I have one project that deals with a complex graph with many node types. To keep it under control there are many different node interface types. Specifically, terminal nodes (no output), signals (no inputs), multiplexers (many inputs) and demultiplexers (many outputs) as well as nodes with a UI. And there was a core node type. Now a single node could fulfill several of these interfaces.		It's ok to use a lot of small interfaces. I have one project that deals with a complex graph with many node types. To keep it under control there are many different node interface types. Specifically, terminal nodes (no output), signals (no inputs), multiplexers (many inputs) and demultiplexers (many outputs) as well as nodes with a UI. And there was a core node type. Now a single node could fulfill several of these interfaces.

			== Types ==
			Now it gets fun and weird. In Go, you can define a method on any local type except an interface. Yes, you can define a method on a function, you can sub-type an int and put methods on that. Anything.

	== Techniques ==		== Techniques ==

Adamcolton at 16:46, 11 August 2016

2016-08-11T16:46:23Z

← Older revision		Revision as of 16:46, 11 August 2016
Line 27:		Line 27:

	=== Staying DRY ===		=== Staying DRY ===

			==== Embedding Structs ====
			This is one of the key uses of embedding.

	==== Pluggable Method ====		==== Pluggable Method ====

Adamcolton at 16:45, 11 August 2016

2016-08-11T16:45:38Z

@@ Line 25: / Line 25: @@
 == Techniques ==
 === Privacy Tricks ===
 ==== Private abstract ====

Adamcolton at 16:34, 11 August 2016

2016-08-11T16:34:06Z

@@ Line 20: / Line 20: @@
    // does not match
    Name() someStringStruct
 == Techniques ==
@@ Line 27: / Line 30: @@
 ==== Private abstract ====
 Let's say you'll have 3 structs that will share some similarities, may just as simple as having a read-only ID. You can create a private struct with the necessary fields and embed that in the public structs. Externally, that struct is completely hidden, but the public methods and fields will be exposed.

Adamcolton: Created page with "== Key Difference == * Private is package wide * structs are concrete, interfaces are abstract * interfaces ONLY specify methods * embedding * using funcs to customize behavio..."

2016-08-11T16:19:10Z

Created page with "== Key Difference == * Private is package wide * structs are concrete, interfaces are abstract * interfaces ONLY specify methods * embedding * using funcs to customize behavio..."

New page

== Key Difference ==
* Private is package wide
* structs are concrete, interfaces are abstract
* interfaces ONLY specify methods
* embedding
* using funcs to customize behavior
* methods can be defined on any type

== The Basics ==
At first structs seem very classic-object (COB) like. A struct has fields and you can define methods on it. The first difference you'll notice though is that the methods are not in the struct.

== Packages ==
It's also important to talk about the role packages play in Go-OO. Anything starting with an uppercase is public, lowercase is private. But unlike COO, privates are package wide.

== Interfaces ==
=== Interfaces must match ===
one gotcha is that you may run into - interfaces must exactly match.

Name() fmt.Stringer
// does not match
Name() someStringStruct

== Techniques ==

=== Privacy Tricks ===

==== Private abstract ====
Let's say you'll have 3 structs that will share some similarities, may just as simple as having a read-only ID. You can create a private struct with the necessary fields and embed that in the public structs. Externally, that struct is completely hidden, but the public methods and fields will be exposed.