- #SINGLE RESPONSIBILITY PRINCIPLE FUNCTIONS HOW TO#
- #SINGLE RESPONSIBILITY PRINCIPLE FUNCTIONS SOFTWARE#
- #SINGLE RESPONSIBILITY PRINCIPLE FUNCTIONS CODE#
What does package server provide? … well a server, hopefully, but which protocol? This focus on names is not just pedantry. A poorly named package misses the opportunity to enumerate its purpose, if indeed it ever had one. When you use another package’s symbols inside your own this is accomplished by the `import` declaration, which establishes a source level coupling between two packages. They now know about each other. encoding/json, which implements encoding and decoding of JSON documents.net/http, which provides http clients and servers.
#SINGLE RESPONSIBILITY PRINCIPLE FUNCTIONS CODE#
In Go, all code lives inside a package, and a well designed package starts with its name. A package’s name is both a description of its purpose, and a name space prefix. Some examples of good packages from the Go standard library might be: To describe the units of coupling and cohesion in a Go program, we might talk about functions and methods, as is very common when discussing SRP but I believe it starts with Go’s package model. In the context of software, cohesion is the property of describing pieces of code are naturally attracted to one another.
#SINGLE RESPONSIBILITY PRINCIPLE FUNCTIONS SOFTWARE#
Two words that describe how easy or difficult it is to change a piece of software are coupling and cohesion.Ĭoupling is simply a word that describes two things changing together–a movement in one induces a movement in another.Ī related, but separate, notion is the idea of cohesion, a force of mutual attraction. So code that has a single responsibility therefore has the fewest reasons to change. And when your code does have to change, it should do so in response to a direct stimuli, it shouldn’t be a victim of collateral damage. Why is it important that a piece of code should have only one reason for change? Well, as distressing as the idea that your own code may change, it is far more distressing to discover that code your code depends on is changing under your feet. Now Go obviously doesn’t have classes-instead we have the far more powerful notion of composition-but if you can look past the use of the word class, I think there is some value here. The first principle of SOLID, the S, is the single responsibility principle.Ī class should have one, and only one, reason to change. So this is what I want to spend some time discussing with you this morning.
#SINGLE RESPONSIBILITY PRINCIPLE FUNCTIONS HOW TO#
This book is a little dated, the languages that it talks about are the ones in use more than a decade ago. But, perhaps there are some aspects of the SOLID principles that may give us a clue about how to talk about a well designed Go programs. In it he described five principles of reusable software design, which he called the SOLID principles, after the first letters in their names. In 2002 Robert Martin published his book, Agile Software Development, Principles, Patterns, and Practices. Wouldn’t it be great if there were some ways to describe the properties of good design, not just bad design, and to be able to do so in objective terms? SOLID Is it just exhausting to use the code? When you look at it, can you even tell what this code is trying to do?Īre these positive sounding words? Would you be pleased to see these words used in a review of your code?īut this is an improvement, now we can say things like “I don’t like this because it’s too hard to modify”, or “I don’t like this because i cannot tell what the code is trying to do”, but what about leading with the positive? Is there code for the sake of having code, are things over-engineered? Is the code hard to refactor? Is it one keystroke away from an import loop? Is the code fragile? Does the slightest change ripple through the code base causing untold havoc? Is the code rigid? Does it have a straight jacket of overbearing types and parameters, that making modification difficult? What are some of the properties of bad code that you might pick up on in code review? Now it’s fine to say “that code is ugly” or ”wow that source code is beautiful”, just as you might say “this painting is beautiful” or “this room is beautiful” but these are subjective terms, and I’m looking for objective ways to talk about the properties of good or bad code. If code review is there to catch bad code, then how do you know if the code you’re reviewing is good, or bad? Who here does code review as part of their job?. How many Go programmers are there in the world? Think of a number and hold it in your head, we’ll come back to it at the end of this talk. How many Go programmers are there in the world? This post has been translated to Russian by Artem Zinoviev.
This post has been translated into Simplified Chinese by Haohao Tian. This post is based on the text of my GolangUK keynote delivered on the 18th of August 2016.Ī recording of the talk is available on YouTube.
0 kommentar(er)
