struct に依存しない処理は function に切り出すのか、method に切り出すのか - pospomeのプログラミング日記
以前少し考えて自己解決して終わったんだけど、 ちょっとしたきっかけがあったのでアウトプットしてみる。 以下のような Person があって、 Hello(), Goodbye() には全く同じ「複雑な処理」がある場合・・・ type Person struct { name string } func (p *Person) Goodbye(input string) { //複雑な処理のつもり fmt.Println("common logic " + input) fmt.Println("goodbye " + p.name) } func (p *Person) Hello(input string) { //複雑な処理のつもり fmt.Println("common logic " + input) fmt.Println("hello " + p.name) } 以前はこれを以
Go における FunctionalOptionPattern と MethodChaining について考える - pospomeのプログラミング日記
きっかけ FunctionalOptionPattern MethodChaining MethodChaining の問題点 Error フィールドによる解決方法 Error フィールドによる解決方法の問題 1. 各メソッドでエラーが発生しないような印象を受ける 2. エラーチェックを忘れそう その1 3. エラーチェックを忘れそう その2 FunctionalOptionPattern による解決方法 MethodChaining としての解決方法 Error フィールドの問題点は本当に問題なのか? どちらを使うべきなのか? まとめ きっかけこの記事を書くきっかけは以下のブログで、 MethodChaining の代わりに FunctionalOptionPattern を利用したという記事。 https://www.calhoun.io/using-functional-option
golangの正規表現は遅いのか? - pospomeのプログラミング日記
golangの正規表現は遅いって聞くけど、実際どーなんだろ? って思ったよっていう記事です。 おそらく、この記事を読んでも何も得られないと思います。 -----追記 2016/11/26 ------- 書籍「みんなのGO言語」で少し言及されていました。 golang の正規表現は場合によっては perl に負けるほど遅く、 「コンパイル言語としては遅い」ということみたいです。 とはいえ、ちゃんとベンチ取らないとダメですね。 ------------------------------- http://qiita.com/naoina/items/d71ddfab31f4b29f6693#正規表現はスイスアーミーナイフではない ↑ ここにあるとおり、正規表現は遅いらしい。 正規表現のベンチを見ると、 643 ns/op。 これは正規表現を1回評価するのに643ナノ秒かかってるってこと。 正
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
