search

jbrukh / ggit

ggit
17 stars 2 forks source link

Separate interfaces from implementations #48

Open MikeBosw opened 11 years ago

MikeBosw commented 11 years ago

Every go file in API seems to depend transitively or directly on every other one. It could hardly be coupled more tightly.

To have a real API we want disk and non-disk separate (at least separable).

Separating the object model types from the rest is a start.

jbrukh commented 11 years ago

I think we've been pretty careful to separate DiskRepository from the objects via Repository interface. It would definitely not be a bad idea to put repository implementations into their own package (e.g. api/repo), and it would be straightforward to separate out DiskRepository from everything else.

MikeBosw commented 11 years ago

Yeah, but I wrote that description pre-coffee after a refactoring fight with Go.

I like the api/repo suggestion. After trying a couple different approaches, I think there are some prerequisite refactorings that we'll need to do first no matter what. The first of the first from what I saw will be the one I mentioned - separation of the object models and their construction interfaces from the rest of the behavior. If for no other reason than that it turns out to be the low-hanging fruit (pardon my Corporish).

jbrukh commented 11 years ago

I'm guessing you're referring to the fact that each object type has its own parse method, and that parse method presupposes the binary format for each object. Note that these methods do not assume anything about disk, they work on any old buffered byte stream, they are general.

If we start supporting a proprietary serialization protocol for git objects, then we can still keep the logic for this protocol in the API, and there is no need to create interfaces for business objects (yet). If the protocol is in another package, it may have trouble building up our business object structs. This can be addressed in several ways, one of which is constructors, and this still doesn't necessitate business object interfaces. (Note public constructors are probably necessary in the long-term to facilitate programmatic writing operations.)

With the ignorance of not having tried a refactoring, I ask: what is the case for business object interfaces?

MikeBosw commented 11 years ago

When I said "interface," I didn't mean the Golang interface keyword. Or were you not talking about the Golang interface keyword either?

On Mon, Nov 5, 2012 at 11:12 AM, jbrukh notifications@github.com wrote:

I'm guessing you're referring to the fact that each object type has its own parse method, and that parse method presupposes the binary format for each object. Note that these methods do not assume anything about disk, they work on any old buffered byte stream, they are general.

If we start supporting a proprietary serialization protocol for git objects, then we can still keep the logic for this protocol in the API, and there is no need to create interfaces for business objects (yet). If the protocol is in another package, it may have trouble building up our business object structs. This can be addressed in several ways, one of which is constructors, and this still doesn't necessitate business object interfaces. (Note public constructors are probably necessary in the long-term to facilitate programmatic writing operations.)

With the ignorance of not having tried a refactoring, I ask: what is the case for business object interfaces?

— Reply to this email directly or view it on GitHubhttps://github.com/jbrukh/ggit/issues/48#issuecomment-10076393.