常連

###前提・実現したいこと
デザインパターンにおけるシングルトンパターンについて
自分の書き方はシングルトンパターンなのか

###発生している問題・エラーメッセージ
自分の書いているコードがシングルトンパターンなのかわかりません。シングルトンを意識して書いていたわけではないのですが、インスタンスを一つしか生成しない点ではシングルトンパターンっぽいけど本質とは全然違う気がします。そもそもオブジェクト指向になっているのかも分かりません。

###該当のソースコード
```C++
//A.h
class A
{
    //内容A
}
```
```C++
//B.h
class B
{
    //内容B
}
```
```C++
//C.h
class C
{
    //内容C
}
```
```C++
#include<iostream>
#include< A.h >
#include< B.h >
#include< C.h >

int main(){
    A a;//インスタンス
    B b;//インスタンス
    C c;//インスタンス
    /*
            処理
      */
    return 0;
}
```



###補足情報(言語/FW/ツール等のバージョンなど)
言語はC++。Pythonでも同じような感じで作っています。
シングルトンのように専用のクラスを作ったり、コードとして保証している訳ではありません。それは分かって欲しいです。シングルトンで書かれたコードは見たことがあります。それのコードを回答として貼られても回答になっていないのでご容赦ください。

デザインパターンシングルトン、オブジェクト指向について

Spring bootにてWebアプリ開発を勉強中です。Domaでのデータアクセスをしようと思った時に疑問が出たので質問します。

参考にしているプロジェクト内でDaoとRepositoryを分けているプロジェクトを見つけたため何が違うのかと調べていたのですが、イマイチ理解できないでいます。

[参考にしているプロジェクト](https://github.com/miyabayt/spring-boot-doma2-sample.git)

その中でDaoとRepositoryを分けている箇所は以下のような実装をしています。
```userdaojava
package com.sample.domain.dao.users;

import java.util.List;
import java.util.Optional;
import java.util.stream.Collector;

import org.seasar.doma.*;
import org.seasar.doma.boot.ConfigAutowireable;
import org.seasar.doma.jdbc.SelectOptions;

import com.sample.domain.dto.user.User;
import com.sample.domain.dto.user.UserCriteria;

@ConfigAutowireable
@Dao
public interface UserDao {

    /**
     * ユーザーを取得します。
     *
     * @param criteria
     * @param options
     * @return
     */
    @Select(strategy = SelectType.COLLECT)
    <R> R selectAll(final UserCriteria criteria, final SelectOptions options, final Collector<User, ?, R> collector);

    /**
     * ユーザーを1件取得します。
     *
     * @param id
     * @return
     */
    @Select
    Optional<User> selectById(Long id);

    /**
     * ユーザーを1件取得します。
     *
     * @param criteria
     * @return
     */
    @Select
    Optional<User> select(UserCriteria criteria);

    /**
     * ユーザーを登録します。
     *
     * @param user
     * @return
     */
    @Insert
    int insert(User user);

    /**
     * ユーザーを更新します。
     *
     * @param user
     * @return
     */
    @Update
    int update(User user);

    /**
     * ユーザーを論理削除します。
     *
     * @param user
     * @return
     */
    @Update(excludeNull = true) // NULLの項目は更新対象にしない
    int delete(User user);

    /**
     * ユーザーを一括登録します。
     *
     * @param users
     * @return
     */
    @BatchInsert
    int[] insert(List<User> users);

    /**
     * ユーザーを一括更新します。
     *
     * @param users
     * @return
     */
    @BatchUpdate
    int[] update(List<User> users);
}

```

```UserRepository
package com.sample.domain.repository.users;

import static com.sample.domain.util.DomaUtils.createSelectOptions;
import static java.util.Optional.ofNullable;
import static java.util.stream.Collectors.toList;

import java.util.Optional;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Repository;

import com.sample.domain.dao.system.UploadFileDao;
import com.sample.domain.dao.users.UserDao;
import com.sample.domain.dao.users.UserRoleDao;
import com.sample.domain.dto.common.Page;
import com.sample.domain.dto.common.Pageable;
import com.sample.domain.dto.user.User;
import com.sample.domain.dto.user.UserCriteria;
import com.sample.domain.dto.user.UserRole;
import com.sample.domain.exception.NoDataFoundException;
import com.sample.domain.service.BaseRepository;

import lombok.val;

@Repository
public class UserRepository extends BaseRepository {

    @Autowired
    UserDao userDao;

    @Autowired
    UserRoleDao userRoleDao;

    @Autowired
    UploadFileDao uploadFileDao;

    /**
     * ユーザーを取得します。
     * 
     * @param criteria
     * @param pageable
     * @return
     */
    public Page<User> findAll(UserCriteria criteria, Pageable pageable) {
        // ページングを指定する
        val options = createSelectOptions(pageable).count();
        val data = userDao.selectAll(criteria, options, toList());
        return pageFactory.create(data, pageable, options.getCount());
    }

    /**
     * ユーザーを取得します。
     * 
     * @param criteria
     * @return
     */
    public Optional<User> findOne(UserCriteria criteria) {
        // 1件取得
        val user = userDao.select(criteria);

        // 添付ファイルを取得する
        user.ifPresent(u -> {
            val uploadFileId = u.getUploadFileId();
            val uploadFile = ofNullable(uploadFileId).map(uploadFileDao::selectById);
            uploadFile.ifPresent(u::setUploadFile);
        });

        return user;
    }

    /**
     * ユーザー取得します。
     *
     * @return
     */
    public User findById(final Long id) {
        return userDao.selectById(id).orElseThrow(() -> new NoDataFoundException("user_id=" + id + " のデータが見つかりません。"));
    }

    /**
     * ユーザーを追加します。
     *
     * @param inputUser
     * @return
     */
    public User create(final User inputUser) {

        // 1件登録
        userDao.insert(inputUser);

        // 役割権限紐付けを登録する
        val userRole = new UserRole();
        userRole.setUserId(inputUser.getId());
        userRole.setRoleKey("users");
        userRoleDao.insert(userRole);

        return inputUser;
    }

    /**
     * ユーザーを更新します。
     *
     * @param inputUser
     * @return
     */
    public User update(final User inputUser) {

        val uploadFile = inputUser.getUploadFile();
        if (uploadFile != null) {
            // 添付ファイルがある場合は、登録・更新する
            val uploadFileId = inputUser.getUploadFileId();
            if (uploadFileId == null) {
                uploadFileDao.insert(uploadFile);
            } else {
                uploadFileDao.update(uploadFile);
            }

            inputUser.setUploadFileId(uploadFile.getId());
        }

        // 1件更新
        int updated = userDao.update(inputUser);

        if (updated < 1) {
            throw new NoDataFoundException("user_id=" + inputUser.getId() + " のデータが見つかりません。");
        }

        return inputUser;
    }

    /**
     * ユーザーを論理削除します。
     *
     * @return
     */
    public User delete(final Long id) {
        val user = userDao.selectById(id)
                .orElseThrow(() -> new NoDataFoundException("user_id=" + id + " のデータが見つかりません。"));

        int updated = userDao.delete(user);

        if (updated < 1) {
            throw new NoDataFoundException("user_id=" + id + " は更新できませんでした。");
        }

        return user;
    }
}

```

このようにRepositoryにてDaoをAutoweredしてメソッドを使用しています。

### 私の中のDaoとRepository
私の中で２つは「デザインパターンレベルでのデータを取得したり、操作するもの」という認識で、大きな違いはないと理解していました。
ただ今回使い分けているんだからなんか違うんだろう、そして同じプロジェクトで同じ階層で使用すべきものなのだろうと思って調査をしました。

１.DaoとRepositoryのすみ分け

```ここに言語を入力
Repositoryはドメインオブジェクトを見て、DAOはデータ・ソースのマッピングするDTOの方を見る

```
「ベクトルが違うのはなんとなく伝わるけどまだわからない」
次！！！

2.[リポジトリとDaoの住み分け方](http://blog.fukuchiharuki.me/entry/use-repository-and-dao-according-to-the-purpose)より

```ここに言語を入力
・リポジトリはドメインオブジェクトのコレクション
・DAOはデータアクセスのメカニズムを隠蔽する

・リポジトリの実装はドメインオブジェクトの構築です。

```
んー、頭の中で噛み砕けない。。。
恥ずかしながら私はデザインパターンを学んだ事がなく、こういう話は理解するのに苦労します。


SESの世界に例えた時に、簡単に言うと「二次請け企業と三次請け企業」のようにレイヤーが異なるという事でしょうか？
もう少し抽象的で構わないので子供に理解できるレベルの日本語で解説するとしたらどのような感じになりますでしょうか？
ご意見をよろしくお願いします。
また、皆さんの現場ではDaoとRepositoryは分けられていますか？

DaoとRepositoryの使い方

### 前提・実現したいこと
ViewModel(VM)とModelの区別が未だにつきません。

以下の記事のコードの例を出しますと、
[サンプルコードを見ながら理解するMVVMの基礎的な実装](http://kaorun.hatenablog.com/entry/20141202/1417532472)

チュートリアルとして、Personクラスが最初にModelとして実装されています。
しかしこれでは更新されないので、INotifyPropertyChangedを実装してPersonViewModelにしています。

Modelとして実装したはずのPersonクラスが、Viewと結びつかせるためにVMになりました。
そうなるとModelとはいったい何なのでしょうか。
データを保持したり、その処理を書くのがModelだと聞きますが、上の例だとVMがModelのようにデータを保持しているように感じます。

###
最初は、VMとModelを完全に別にするとなると、以下のようにPersonVMクラスの中にPersonのインスタンスを作ってラップするのではないかと考えました。
```C#
PersonVM : INotifyPropertyChanged //(1)
{
    Person person = new Person();
    public int Age{
        get => person.Age;
        set {
            person.Age = value;
            NotifyPropertyChanged(nameof(Age));
        }
    }
}
```
しかしこのようにVMとMを分けると、Personに対して操作しても変更通知されません。

また、ReactivePropertyの意味や使い方がよくわからなくなってしまいます。

```C#
//こう書くのがReactivePropertyの使い方だと思っていたが、VMとModelを兼任しているためMVVMにはならない？
PersonVM : INotifyPropertyChanged //(2)
{
    public ReactiveProperty<int> Age{get;} = new ReactiveProperty<int>();
}

//Modelに代入させることはできても、結局Modelのインスタンス内の変更通知はVMにもVにも飛ばない。
//逆に、ModelからVMに変更通知が必要な設計が間違い？
PersonVM : INotifyPropertyChanged //(3)
{
    Person person = new Person();

    public PersonVM(){
        Age.Subscribe(x => person.Age = x);
    }
    public ReactiveProperty<int> Age{get;}= new ReactiveProperty<int>();
}
```

このPersonクラスをバイナリなりテキストなりでエクスポートする実装をするとして、
ViewModelのCommandの中で出力処理を書いてしまうのはNGだと聞きます。

(1)や(3)ならPersonクラスにメソッドを入れるなり、Personクラスを引数にするメソッドをどっかに作ったりとやりようがありますが、
(2)のようなパターンだとPersonVM内に作るか、PersonVMを引数にとらなくてはならなくなってしまいます。

データ出力のためにVMが必要ならば、それはVMがデータを保持している。つまりVMでもありModelでもあるという状況になっていないでしょうか。

このように、私の中でModelとVMの境目、分け方がわからなくなってしまい混乱しています。
どこかにMVVMの解釈に関して誤解がないか。また、どのような形でMVVMを実装するのが正しいのかの助言をいただきたいです。

よろしくお願いいたします。

MVVMにおける、ViewModelとModelの違い、境界線について

## テーマ、知りたいこと

PCゲームにある「チャレンジ」とか「実績」
ってきれいに実装する方法とかありますでしょうか？
やっぱり、コードのあちこちに判定とかフラグを埋め込むことになりますかね？

## 背景、状況

たとえば簡単な例で4桁の数を当てるゲーム（ヒットアンドブロー）だとこんな感じです 

チャレンジ
・1発であてる
・1分以内にあてる
・奇数だけのものを当てる
・午前中に10回プレイする
・100回遊ぶ

これはあくまで自分の妄想アイデアなんですが、
ゲームをみてる監視者をおいて、監視者にこういったロジックを分離したら
きれいになりそう、と夢想しますが、具体的にどうなるのか想像もつきません

自分はプロじゃないし、実際チャレンジを作れないとどうしても困る、というわけではないのですが、
こんな感じでやりました、やってるのを聞きました、みたいな体験談を聞けたらとても嬉しいです

読んでいただきありがとうございます



ゲームの「チャレンジ」とか「実績」の実装方法

複数のクラスで共通で利用する変数がありますが、どのように管理するのが良いのでしょうか。

例えば、ClassA,ClassB,ClassCで共通で利用する変数があります。この変数は、それぞれのクラスで読み込んで利用したり、値を変えたりします。

この変数を仮にClassAのメンバー変数にしてgetter、setterのメソッドを作りClassB,ClassCにClassAのsetterメソッドを作りそれでsetして上記の変数をそれぞれのクラスで利用出来るようにしたのですが、密結合だし、なんか変です。

どのようにすべきかご教示お願いします。

```Java

class A {
        int value;

        int getValue() {
            return value;
        }

        void setValue(int value) {
            this.value = value;
        }
    }
    
    class B {
        A a;

        void setA(A a) {
            this.a = a;
        }
    }

    class C {
        A a;

        void setA(A a) {
            this.a = a;
        }
    }
```

複数のクラスで共通で利用する変数をどのように管理するか。

現在javaの勉強中なのですが
以下のような流れの処理をボタンを押された際に呼び出されるメソッドに丸ごと詰め込んでいる状態です。

1.トランザクション開始
2.テーブルAからデータ取得
3.なんかいろいろ処理
4.テーブルBにデータ登録
5.トランザクション終了（コミット）

これをDAOを使った作りに書きなおしてみたいと思ったのですが、
その場合トランザクションの管理はどこで行うべきなのでしょうか？

パッと思いついたのは以下の2つです。
①1～5全てをDAOの1つのメソッドに詰め込む。
　トランザクションの管理はDAOのメソッド内で行う

②1,3,5はビジネスロジックにして2,4は個別のメソッドとして定義する。
　トランザクションの管理はビジネスロジックで行いDAOには引数等でトランザクションを渡すようにする。

しかし、①にした場合DAOにビジネスロジックが入っていしまう上にメソッドの粒度が大きくなりすぎる気がします（呼び出し元が何もしないでDAOのメソッド呼び出すだけなので元々と変わらないですし）。
②の方法にすると何となく解決は出来そうなんですがDAOを使った開発のパターンとして正しいものなのかどうかがわからないです。

フレームワーク等を使えばそれらが上手いことやってくれるらしいので気にしなくていいのかもしれませんが、
別の言語でも同じ問題にぶつかる可能性が高いですし、初学者なのでそれらに頼らずに自分で管理するように書いてみたいと思っています。

よろしくお願いします。

DAOを使う場合にトランザクション管理は何処で行うべきでしょうか？

xxxManagerというクラス名はアンチパターンであるという話を度々聞きます。
これがアンチパターンとされる理由にも納得はいきます。

ただ、外部のAPIを使いやすくするために、そのAPIのラッパーライブラリを作ったりする場合、
外部APIのあるまとまりのあるクラスのメソッドをまとめるラッパークラスを自分は作るのですが、
このラッパークラスにxxxManagerとつけるのはやはりアンチパターンなのでしょうか？

例えば、Google Apps Scriptのスプレッドシート周りのメソッドを使いやすくするために、SpreadsheetManagerというクラスを作って、その中で以下のようなメソッドを外部に公開するといったやり方をしているのですが、これはよろしくないのでしょうか？

以下のコードではSpreadsheetManagerクラス内部でGoogle apps ScriptのSpreadsheetAppクラス、Spreadsheetクラス、Sheetクラス、また、Rangeクラスのメソッドを呼び出しています。

```TypeScript
let spreadSheetManager: SpreadsheetManager = new SpreadsheetManager("スプレッドシートファイルID");
spreadSheetManager.selectSheetByName("シート名(タブ名)");
spreadsheetManager.appendTableData([[1,2,3],[1,2,3],[1,2,3]);
```

以下のリンク先ページを見ると、xxxManagerというよりはxxxFacadeというクラス名がこのような場合は適切ということなのでしょうか？

[http://qiita.com/KeithYokoma/items/ee21fec6a3ebb5d1e9a8](http://qiita.com/KeithYokoma/items/ee21fec6a3ebb5d1e9a8#%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E3%81%B8%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%82%92%E7%B5%B1%E5%90%88%E3%81%99%E3%82%8B%E3%83%AC%E3%82%A4%E3%83%A4)

xxxManagerというクラス名がアンチパターンとされる理由は、そのクラスが具体的に何を担当しているかが抽象的でわかりづらいという点と、一つのクラスにいろんな役割を持たせるべきではないという点だと思うのですが、後者の理由に関してはFacadeのようなものは例外でしょうか？(そのクラス内で細かな役割を持った複数のクラスを操作しているような場合)

まとまりのない文章で恐縮ですが、xxxManagerという名前の付け方がアンチパターンとされる理由を深く理解したいと思いまして、このような質問を投稿させて頂きました。

よろしくお願い致します。

**参考 - Google Spreadsheet Service **
[https://developers.google.com/apps-script/reference/spreadsheet/
](https://developers.google.com/apps-script/reference/spreadsheet/)

**参考 - 命名規則に関する記事**
[http://qiita.com/magicant/items/8134edf969f9629fa66e](http://qiita.com/magicant/items/8134edf969f9629fa66e)
[http://qiita.com/KeithYokoma/items/ee21fec6a3ebb5d1e9a8](http://qiita.com/KeithYokoma/items/ee21fec6a3ebb5d1e9a8)
[http://gihyo.jp/dev/serial/01/code/000204](http://gihyo.jp/dev/serial/01/code/000204)

## 更新
**更新**
頂いた回答を読んで、まず、今回の例の場合はxxxManagerというクラス名はふさわしくないことは理解致しました!!

**補足**
サンプルコード内のSpreadsheetManagerクラスは以下のSpreadsheet Service全てを網羅するラッパークラスではありません。初期化時に引数に渡すファイル名に紐づくスプレッドシートファイルを読み込み、そのシートに対する読み書きなどの操作を、単純なインターフェイスを外部に公開し利用出来るようにするものです。
[https://developers.google.com/apps-script/reference/spreadsheet/
](https://developers.google.com/apps-script/reference/spreadsheet/)
** Facadeクラスの命名に関する参考記事
[What's a good name for a façade class?](http://stackoverflow.com/questions/6737423/whats-a-good-name-for-a-fa%C3%A7ade-class)

クラスの名前の付け方について（xxxmanagerクラスはアンチパターン？)

「Java言語で学ぶデザインパターン入門」を元にデザインパターンを学習していますが、
Iteratorパターンを使うべきケースが理解できません。

書籍内のサンプルでは本の集合を表すBookShelfクラスにて、下記2つのメソッドを定義しています。
 ・本の冊数を返す。 int getLength ( )
 ・index番目の本を返す。 Book getBookAt ( int index )

MainクラスにてIteratorパターンを用いて、下記のように走査してますが、
```lang-java
Iterator it = book_shelf.iterator();
		while(it.hasNext()) {
			Book book = (Book)it.next();
			System.out.println(book.getName());
		}
```
Iteratorパターンを用いずに下記のようなfor文で問題ないと考えてます。

```lang-java
		for (int i = 0; i < bookShelf.getLength(); i++) {
			Book book = bookShelf.getBook(i);
			System.out.println(book.getName());
		}
```
Iteratorパターンのメリットは
> BookShelfクラスの実装を、現状の配列ではなく、Vectorを使うようにしても、BookShelfクラスを利用する側は変更しなくて済む。
と説明されてますが、これは「int getLength()」メソッドと「Book getBookAt()」が同じように機能するのであれば、forループの場合と比べて何ら変わりありません。

上記を踏まえた上で、Iteratorパターンのメリット、使うべきケースについてご教示頂けますと幸いです。

# なお、似たような記事を見つけましたが、こちらの内容ではいまいち理解できませんでした。
# http://www.aerith.net/design/Iterator-j.html

下記、参考までにソースを記載致します。

Aggregate.java
```lang-java
public interface Aggregate {

	public abstract Iterator iterator();
}
```
Iterator.java
```lang-java
public interface Iterator {
	public abstract boolean hasNext();
	public abstract Object next();
}
```
BookShelf.java
```lang-java
import java.util.*;

public class BookShelf implements Aggregate {

	private List<Book> books = new ArrayList<Book>();
	public Book getBook(int index) {
		return books.get(index);
	}
	public void appendBook(Book book) {
		books.add(book);
	}
	public int getLength() {
		return books.size();
	}
	public Iterator iterator() {
		return new BookShelfIterator(this);
	}
}
```
BookShelfIterator .java
```lang-java
public class BookShelfIterator implements Iterator {

	private BookShelf bookShelf;
	private int index;

	public BookShelfIterator(BookShelf bookShelf) {
		this.bookShelf = bookShelf;
		this.index = 0;
	}

	public boolean hasNext() {
		if (index < bookShelf.getLength()) {
			return true;
		} else {
			return false;
		}
	}

	public Object next() {
		Book book = bookShelf.getBook(index);
		index++;
		return book;
	}
}
```
Main.java
```lang-＜ここに言語を入力＞
public class Main {

	public static void main(String[] args) {

		BookShelf bookShelf = new BookShelf();
		bookShelf.appendBook(new Book("Around the World in 80 Days"));
		bookShelf.appendBook(new Book("Bible"));
		bookShelf.appendBook(new Book("Cinderella"));
		bookShelf.appendBook(new Book("Daddy-Long-Legs"));

		Iterator it = bookShelf.iterator();

		while(it.hasNext()) {
			Book book = (Book)it.next();
			System.out.println(book.getName());
		}

		//for (int i = 0; i < bookShelf.getLength(); i++) {
		//	Book book = bookShelf.getBook(i);
		//	System.out.println(book.getName());
		//}
	}
}
```