科技回声

6 条评论

skywhopper将近 9 年前

Definitely good stuff to think about in the piece, but even as a Go fan, I found the rhetoric to be insufferable. "Go obviously doesn’t have classes—instead we have the far more powerful notion of composition". Go's syntax may frame things differently than Java or Ruby or C++, and I don't discount the impact of syntax and abstractions on code design, _but_ just because you don't call them "classes" doesn't mean they are something entirely different.Go types can have public and private fields, a set of associated functions which can also be public or private, and ways to extend other structs or pose as other types. So you've got encapsulation, inheritance, and polymorphism. Pretending you don't have "classes" is just silly.

评论 #12344759 未加载

tunesmith将近 9 年前

For middle of the road companies with middle of the road developers, I find SOLID is not really a great set of principles to focus on.'S' is pretty good because it helps encourage developers to get away from huge classes that have dozens of methods.'O' is basically useless when applied to a single codebase, because one of the worst parts of middle-of-the-road developers is when they start to realize they can extend classes. You end up with horrendously complicated and deep class hierarchies. I find that when it's time to add functionality, it's far better to just refactor and create new classes for composition.'L' is deeply confusing, and the difficulty in understanding it is what leads to the deep and brittle class structures above.'I' drives intermediate developers to create more and more interfaces that have 1-2 methods, which when combined with their difficulties with 'O' and 'L', just leads to confusion and high cognitive load when trying to maintain the codebase.'D' is good.

评论 #12341626 未加载

评论 #12342583 未加载

评论 #12341618 未加载

评论 #12344781 未加载

评论 #12357924 未加载

评论 #12344095 未加载

kasey_junk将近 9 年前

I am fairly consistent in my criticism of Go. I am also fairly consistent in my insistence that the Dependency Inversion Principle is one of the harder concepts to wrap your head around of the SOLID principles (not least because several other concepts use terms similar).But golang's structural typing actually allows for some of the easiest demonstrations of the implementation of the DIP of any of the strongly typed languages I've used.I find Martin's definition of the DIP counterintuitive. A description that makes more sense to me is "interfaces should be defined by the 'users' of the interface, not by the implementers".With a language like C++ or Java, to achieve this requires either lots of adapter layers or compiler tricks. With golang it is simple.As a for instance, let's say I'm writing a restful client library for a specific application. It is tempting to to hard code a dependency on the std lib http.Client.Do method. If instead with 3 lines of code, I define my own interface for Do that matches the std library definition. I can use the std library, or any other library that matches it (one that is faster say or implements back off).That is one of the few areas where the golang type system is pretty cool in comparison to its peers.

评论 #12342043 未加载

评论 #12342495 未加载

praptak将近 9 年前

There's something strange about application of the Liskov Substitution Principle in the article.Original formulation of LSP was: subtypes should not break supertypes, i.e. caller expecting supertype should not be able to tell the difference when getting an instance of subtype. That was expressed in terms of an explicit subtype/supertype relation, like inheritance in OOP. When there's no such thing in the language, the LSP becomes (quote article):"Two types are substitutable if they exhibit behaviour such that the caller is unable to tell the difference."This sounds almost like a tautology. I understand that it isn't, since "substitutable" is "you substitute class X for interface Y in your code" and "observably same behaviour" is "X behaves like all implementors of Y are expected to".In practice, X doesn't declare it implements Y. If I review a change to X I might miss that fact. If that change breaks behavior expected from Y, it's bad.I'm not sure if this scenario is a real problem, I have written like 100 lines in Go.

评论 #12342704 未加载

akkartik将近 9 年前

eyerollI wonder how Robert Martin was implementing SOLID before the wonder that is Go was delivered unto us. And I wonder why all our buzzword-laden codebases are still knee deep in crap if SOLID is so amazingly awesome. We've been hearing about coupling and cohesion for over 50 years now. At what point does thinking in those terms become part of the problem rather than the solution?Is it possible that Go or any other language du jour just seems cleaner because it's newer and so the cruft hasn't had a chance to form yet? Come back in 10 years, and tell me how amazing it is then.

SOLID Go Design

6 条评论

SOLID Go Design

6 条评论