常連

注目の的

社会貢献

質問力

自己紹介

Golangにおいて，DBから取得したデータを構造体に格納してその構造体を返す関数を作成することを考えた場合，

```Go
type User struct {
    Name string
    Age  int
}

type UserDB struct {
    db *sql.DB
}

func (u UserDB) FindUserByName(name string) (*User, error){
...
}
```
となると思うのですが，
構造体を変更することがない場合，
戻り値はUser構造体のポインタの方が良いのでしょうか．
それともそのまま構造体を返した方が良いのでしょうか．

またその理由を教えていただきたいです．

Go構造体の扱い方(DBからデータ取得時)

### 前提・実現したいこと


numbaを用いて行列計算を高速にしたいと考えています。
numba.jitにおいて型指定を行うとより早くなるそうなので試しています。

### 発生している問題・エラーメッセージ
型推定に失敗？しているようです。

```
Compilation is falling back to object mode WITH looplifting enabled because Function "compute" failed type inference due to: Invalid use of Function(<built-in function zeros>) with argument(s) of type(s): ((Literal[int](10), array(float64, 1d, A)), dtype=Literal[str](f8))
 * parameterized
In definition 0:
    All templates rejected with literals.
In definition 1:
    All templates rejected without literals.
This error is usually caused by passing an argument of a type that is unsupported by the named function.
[1] During: resolving callee type: Function(<built-in function zeros>)
[2] During: typing of call at <ipython-input-45-5c375a54c6a4> (6)


File "<ipython-input-45-5c375a54c6a4>", line 6:
def compute(T):
    <source elided>
    dt = 0.001
    X = np.zeros((N,T),dtype='f8')
    ^

  @numba.jit('f8(f8[:])')
<ipython-input-45-5c375a54c6a4>:3: NumbaWarning: 
Compilation is falling back to object mode WITHOUT looplifting enabled because Function "compute" failed type inference due to: cannot determine Numba type of <class 'numba.dispatcher.LiftedLoop'>

File "<ipython-input-45-5c375a54c6a4>", line 12:
def compute(T):
    <source elided>
    
    for t in range(0,T-1,1):
    ^

  @numba.jit('f8(f8[:])')
C:\Users\takuy\Anaconda3\envs\keras_env\lib\site-packages\numba\object_mode_passes.py:178: NumbaWarning: Function "compute" was compiled in object mode without forceobj=True, but has lifted loops.

File "<ipython-input-45-5c375a54c6a4>", line 4:
@numba.jit('f8(f8[:])')
def compute(T):
^

  state.func_ir.loc))
C:\Users\takuy\Anaconda3\envs\keras_env\lib\site-packages\numba\object_mode_passes.py:187: NumbaDeprecationWarning: 
Fall-back from the nopython compilation path to the object mode compilation path has been detected, this is deprecated behaviour.

For more information visit http://numba.pydata.org/numba-doc/latest/reference/deprecation.html#deprecation-of-object-mode-fall-back-behaviour-when-using-jit

File "<ipython-input-45-5c375a54c6a4>", line 4:
@numba.jit('f8(f8[:])')
def compute(T):
^

  warnings.warn(errors.NumbaDeprecationWarning(msg, state.func_ir.loc))
<ipython-input-45-5c375a54c6a4>:16: NumbaPerformanceWarning: '@' is faster on contiguous arrays, called on (array(float64, 2d, C), array(float64, 1d, A))
  X_2[:,t+1] = -M_inv@K@X[:,t+1]
```

### 該当のソースコード

```python

import numpy as np
from scipy import linalg

m=1
g=9.8
k=100
N=10

#剛性マトリックスの作成
K=np.eye(N,dtype=float)*2-np.eye(N,k=1)-np.eye(N,k=-1)
K[0,0]=2;K[N-1,N-1]=1
M=np.eye(N,dtype=float)
K_inv=np.linalg.inv(K)
M_inv=np.linalg.inv(M)


import numba

#問題の部分
@numba.jit('f8(f8[:])')
def compute(T):
    dt = 0.001
    X = np.zeros((N,T),dtype='f8')
    V = np.zeros((N,T),dtype='f8')
    V[-1,0] = 1.0
    X_2 = np.zeros((N,T),dtype='f8')
    print(V)
    
    for t in range(0,T-1,1):

        X[:,t+1] = X[:,t] + dt*V[:,t]
        V[:,t+1] = V[:,t] + dt*X_2[:,t]
        X_2[:,t+1] = -M_inv@K@X[:,t+1]
        
    
    return (X)

%time X_=compute(int(1e4))



```

### 試したこと

すべてのarrayををfloat64に型指定しましたが,推定に失敗するようです

### 補足情報（FW/ツールのバージョンなど）

jupyter notebook　使用

numpy(行列計算)高速化のためのnumbaの型指定について

デザインパターンの一つであるFactory Methodを調べていて気になった点を質問させてください。

**Factoryパターンのメリット**
Factory Methodに限らず、一般的にオブジェクトの生成のためのFactoryを設けることのメリットは以下の通りと認識しています。

・ インスタンスの生成処理を隠蔽化できる
・ そのためクライアントが利用したいオブジェクトの具象から分離される。（具象オブジェクトをnewしない）

```java
interface Producer {
    // いくつかのメソッド
}
class AProducer implements Producer {
    // Producerの実装
}

// ファクトリ
class ProducerFactory() {
    public Producer createProducer() {
        return new AProducer();
    }
}

// クライアント
class Main() {
    public static void main(String[] args) {
        Producer p = ProducerFactory.createProducer()
    }
}
```

**Factory Methodパターン**
Factory Methodパターンの場合、生成したいオブジェクトの種類に応じてファクトリを用意することになるので、
「クライアントが利用したいオブジェクトの具象から分離される。」メリットを完全に失っている気がします。

※実際に利用したいオブジェクトには依存してませんが、そのオブジェクトを生成するためのファクトリに依存している（newしている）ため。利用するオブジェクトが変われば当然ファクトリも変えざるを得ず、クライアントのコードに修正が発生します。

```java
interface Producer {
    // いくつかのメソッド
}
class AProducer implements Producer {
    // Producerの実装
}

class BProducer implements Producer {
    // Producerの実装
}

// ファクトリ
abstract class ProducerFactory {
    public abstract Producer createProducer();
}
class AProducerFactory extends ProducerFactory {
    public Producer createProducer() {
        return new AProducer();
    }
}
class BProducerFactory extends ProducerFactory {
    public Producer createProducer() {
        return new BProducer();
    }
}

// クライアント
class Main() {
    public static void main(String[] args) {
        Producer ap = new AProducerFactory().createProducer()
        Producer ap = new BProducerFactory().createProducer()
    }
}
```

このようにFactory Methodパターンはクライアントと具象クラスが密結合になってしまうデメリットがあると考えます。
オブジェクトの生成処理においてテンプレートメソッドを利用する場合は意味があるとは思いますが、
それ以外の場合に敢えてFactory Methodを用意するメリットはありますでしょうか？
むしろオブジェクトの生成処理は1ファクトリクラスに集約したほうが、疎結合なつくりにできるのではないかと考えています。

ご意見頂けますと幸いです。

参考
http://think-on-object.blogspot.jp/2011/11/factoryfactory-methodabstract-factory.html
http://d.hatena.ne.jp/asakichy/20090414/1239718537
http://d.hatena.ne.jp/asakichy/20090331/1238472501
http://www.nulab.co.jp/designPatterns/designPatterns2/designPatterns2-2.html

【デザインパターン】Factory Methodパターンでは具象クラスとの依存度を下げることはできない。

ずっとゲーム制作ソフトを作っているのですが、その事で1つ分からなくなっている事があります。
通常のプログラミングとRPGツクールやWOLF RPG エディターに代表されるイベントコマンドとどちらが使いやすいのか？
という事です。

ゲーム制作ソフトの開発のブログをずっと書いているのですがその中で「ゲームの戦闘やメニュー画面といったゲームの根幹のシステムをプログラミング言語（ツクールでいうRGSSのようなスクリプト言語）ではなくRPGツクールやWOLF RPGエディターのようなイベントコマンドで全て作って欲しい」という意見がかなり書かれます。

ところが私のようなプログラミング畑の人間にとってツクールやWOLF RPG エディターのイベントコマンドは「ゲーム中の会話を表示する」程度なら非常に簡単で良いのですが、それらを駆使してゲームの戦闘やメニュー画面などの根幹のシステムを作る事は非常に苦痛です。

現在のプログラミング言語はオブジェクト指向を始めに大量のプログラミングに対する支援機能が有ります。一方、これらのオブジェクト指向を始めとする支援機能はツクールやWOLF RPGエディターのイベントコマンドには搭載されていません。言わばアセンブラやC言語でシステムを組むような物でRubyやC++と比べればかなり制作しづらい環境です。

これらの支援機能がRPGツクールなどのイベントコマンドについてないのは初心者にとって理解しづらいからです。ですが、メニューや戦闘のようなシステムを改造できるような人間はプログラミングの素養があり、RubyやC++のようなプログラミング言語も十二分に使いこなせるはずです。

にも関わらず、上記のようなイベントコマンドでシステムを作って欲しいという意見が多いのは何故でしょうか？ちょっとしたイベントならともかく、ゲームの根幹のシステムはプログラミング言語を学んで作ったほうが遥かに作りやすいし、その方式で作られたシステムのほうが遥かに改造しやすいはずです。

その意見が書かれているブログの記事のURLを載せます。一番下にコメント欄が有ります

[http://kurete.blog.shinobi.jp/condition/85](http://kurete.blog.shinobi.jp/condition/85)
[http://kurete.blog.shinobi.jp/condition/82](http://kurete.blog.shinobi.jp/condition/82)
[http://kurete.blog.shinobi.jp/column/58](http://kurete.blog.shinobi.jp/column/58)

長文になってしまいましたが、宜しくお願いします。