pythonを使ってファクトリメソッドパターンを実装する方法について
python を使ってファクトリメソッドパターンの実装をした際に試した内容です。
ファクトリメソッドパターンの作り方としては二通り知っていますが、そのうちの「カテゴリによって実行するインスタンスを決める」方法の実装を紹介します。
今回はデコレータを使ったパターンと、使わなかったときのパターンを比較して、どちらを選択したほうが良いか考えます。
結論としては、デコレータを使ったパターンの方がコード量が少なく、メンテ時の修正範囲も少なくなると思いました。
環境について
- python3.9.0
題材について
以下の条件を満たすクラス設計をします。
- 従業員が存在する
- 従業員は2つのカテゴリで分類される
- エンジニア
- 営業
- 各従業員には名前がある
- 各従業員はカテゴリ別に通勤方法が決まっている
- エンジニアは徒歩で通勤する
- 営業は電車で通勤する
- 従業員の名前と通勤方法を出力できる
デコレータを使ったパターン
デコレータを使うことで、どのクラスがファクトリーの対象となっているのかがわかりやすくなっています。
from enum import Enum class Employee: def __init__(self, name): self._name = name def commute_method(self): # 本来は出社方法を集約かコンポジションで管理するのが良いです。 # 簡易的な実装にするために関数を実装するようにします。 # もしくは、出社するためのクラスを別に用意するのが良いと思います。 raise NotImplementedError @property def name(self): return self._name class CategoryTypes: engineer = 'engineer' sales = 'sales' class EmployeeFactory: class_ = {} @classmethod def register(cls, category): def wrapper(cls_): if not issubclass(cls_, Employee): raise TypeError cls.class_[category] = cls_ return cls_ return wrapper @classmethod def create(cls, category): cls_ = cls.class_[category] return cls_ @EmployeeFactory.register(CategoryTypes.engineer) class Engineer(Employee): def commute_method(self): return '歩いて出社' @EmployeeFactory.register(CategoryTypes.sales) class Sales(Employee): def commute_method(self): return '電車で出社' class EmployeeInfo: def __init__(self, employee_): self._employee = employee_ def print(self): print('\n'.join([ f'名前: {self._employee.name}', f'通勤方法: {self._employee.commute_method()}', ])) if __name__ == '__main__': employee = EmployeeFactory.create(CategoryTypes.engineer) sales = EmployeeFactory.create(CategoryTypes.sales) EmployeeInfo(employee('Aさん')).print() EmployeeInfo(sales('Bさん')).print()
実行結果
名前: Aさん 通勤方法: 歩いて出社 名前: Bさん 通勤方法: 電車で出社
デコレータを使わない例
デコレータを使った例を基に、デコレータを使わなかったときのコードを考えてみます。
from enum import Enum class Employee: def __init__(self, name): self._name = name def commute_method(self): # 本来は出社方法を集約かコンポジションで管理するのが良いです。 # 簡易的な実装にするために関数を実装するようにします。 # もしくは、出社するためのクラスを別に用意するのが良いと思います。 raise NotImplementedError @property def name(self): return self._name class CategoryTypes(Enum): engineer = 'engineer' sales = 'sales' class Engineer(Employee): def commute_method(self): return '歩いて出社' class Sales(Employee): def commute_method(self): return '電車で出社' class EmployeeFactory: FACTORY_MAP = { CategoryTypes.engineer: Engineer, CategoryTypes.sales: Sales, } @classmethod def create(cls, category_type): if category_type in cls.FACTORY_MAP: return cls.FACTORY_MAP[category_type] raise TypeError class EmployeeInfo: def __init__(self, employee_): self._employee = employee_ def print(self): print('\n'.join([ f'名前: {self._employee.name}', f'通勤方法: {self._employee.commute_method()}', ])) if __name__ == '__main__': employee = EmployeeFactory.create(CategoryTypes.engineer) sales = EmployeeFactory.create(CategoryTypes.sales) EmployeeInfo(employee('Aさん')).print() EmployeeInfo(sales('Bさん')).print()
デコレータを使った場合と異なるのは、ファクトリを作成するクラス(EmployeeFactory
)です。
また、カテゴリを管理するクラスがEnum
になっています。
なぜEnum
になっているのかというと、デコレータを使った場合の実装だと、Enum.field.value
のようにvalue
を書く必要があったからです。
value
を書くのを忘れてエラーになってしまうことが多いため、あえてEnum
での実装を避けています。
class CategoryTypes(Enum): engineer = 'engineer' sales = 'sales' class EmployeeFactory: FACTORY_MAP = { CategoryTypes.engineer: Engineer, CategoryTypes.sales: Sales, } @classmethod def create(cls, category_type): if category_type in cls.FACTORY_MAP: return cls.FACTORY_MAP[category_type] raise TypeError
比較する
デコレータを使った場合と、デコレータを使わなかった場合を比較すると、デコレータを使った場合の方がカテゴリの追加時(更新時)に修正範囲が小さいです。
例えば、新しく「カスタマーサポート」を追加する際を考えてみます。
デコレータを使った実装の場合は以下の修正が必要になります。
class CategoryTypes: engineer = 'engineer' sales = 'sales' customer_support = 'customer_support' @EmployeeFactory.register(CategoryTypes.customer_support) class CustomerSupport(Employee): def commute_method(self): return '自転車で出社' customer_support = EmployeeFactory.create(CategoryTypes.customer_support) EmployeeInfo(customer_support('Cさん')).print()
このように、カテゴリを追加して、そのクラスを用意するだけで修正が完了します。
デコレータを使わない場合についても同様に考えてみます。
class CategoryTypes(Enum): engineer = 'engineer' sales = 'sales' customer_support = 'customer_support' class CustomerSupport(Employee): def commute_method(self): return '自転車で出社' class EmployeeFactory: FACTORY_MAP = { CategoryTypes.engineer: Engineer, CategoryTypes.sales: Sales, CategoryTypes.customer_support: CustomerSupport, } # 略 customer_support = EmployeeFactory.create(CategoryTypes.customer_support) EmployeeInfo(customer_support('Cさん')).print()
このように、FACTORY_MAP
を修正するひと手間が必要になってしまいます。
今回はとてもシンプルな例で比較したため、1箇所のみの差しかありませんでしたが複雑になれば大きな差になるため気をつけたほうが良いです。
結論
ファクトリメソッドパターンを python で実装する場合は、デコレータを積極的に使うことで、修正箇所が少なくなります。
指定したキーをdictから再帰的に検索して削除する方法
Djangoを使っているなかで、apiのテストをする際に特定のkeyを取り除きたいということがありました。
例えば、レスポンスにcreated_at
が含まれている場合、レコードが作成された日が入ると、assertDictEqual
では期待値と一致しないためエラーとなってしまいます。
その際にcreated_at
を取り除くことが目的です。
これによって、一つ一つのkeyを取り出して期待値と一致するか検証する必要がなくなり、assertDictEqual
を使って検証することができるようになります。
※ 値を取り除くよりも、freezegun
を利用してdatetime.now
にパッチするのが良いと思われます。
コード
remove_keys
を実行することでdictから指定したキーを取り除けます。
また、valueがlistやdictであった場合も対応できます。
def remove_keys(d: Dict, _remove_keys: List[str] = None): if _remove_keys is None: raise ValueError('keys must be required.') for k in list(d.keys()): v = d[k] if k in _remove_keys: del d[k] if isinstance(v, dict): remove_keys(v, _remove_keys) elif isinstance(v, list): for vd in v: remove_keys(vd, _remove_keys)
使い方
sample = { 'id': 1, 'name': 'sample', 'description': 'sample', 'created_at': int(datetime.now().timestamp()), 'modified_at': int(datetime.now().timestamp()), 'obj': { 'id': 1, 'name': 'sample', 'description': 'sample', 'created_at': int(datetime.now().timestamp()), 'modified_at': int(datetime.now().timestamp()), }, 'list_obj': [ { 'id': 1, 'name': 'sample', 'description': 'sample', 'created_at': int(datetime.now().timestamp()), 'modified_at': int(datetime.now().timestamp()), }, { 'id': 2, 'name': 'sample', 'description': 'sample', 'created_at': int(datetime.now().timestamp()), 'modified_at': int(datetime.now().timestamp()), }, ] } remove_keys(sample, ['created_at', 'modified_at']) assert sample == { 'id': 1, 'name': 'sample', 'description': 'sample', 'obj': { 'id': 1, 'name': 'sample', 'description': 'sample', }, 'list_obj': [ { 'id': 1, 'name': 'sample', 'description': 'sample', }, { 'id': 2, 'name': 'sample', 'description': 'sample', }, ] }
pythonを使ってツイートをlikeした人の一覧を取得する方法
twitter api
を利用して自身のツイートをいいねしたユーザの一覧を取得します。
このapi
は2021年7月6日段階でtwitter-python
ライブラリには実装されていませんでした。
なのでrequests
ライブラリとrequests_oauthlib
を利用してAPIを実行します。
環境
requirements.txt
certifi==2021.5.30 chardet==4.0.0 future==0.18.2 idna==2.10 oauthlib==3.1.1 python-twitter==3.5 requests==2.25.1 requests-oauthlib==1.3.0 urllib3==1.26.6
コードについて
結構簡単に実装できるので、解説はせずにサンプルコードを示します。
サンプルコード
import requests from requests_oauthlib import OAuth1 import settings def _make_url(tweet_id): return f'https://api.twitter.com/2/tweets/{tweet_id}/liking_users' if __name__ == '__main__': url = _make_url('xxxxx') auth = OAuth1( 'CONSUMER_KEY', 'CONSUMER_SECRET', 'ACCESS_TOKEN_KEY', 'ACCESS_TOKEN_SECRET', ) r = requests.get(url, auth=auth) print(r.text)
コードの中のOAuth1
に渡している値については、twitterでプロジェクトを作成したときに作った値を入れてください。
_make_url
に渡しているxxxxx
については、ツイートのIDを指定します。
このIDはツイッターをブラウザで開き、ツイートをクリックすることで確認できます。 クリックしたあとのアドレスバーが以下のようになります。
https://twitter.com/{Sample}/status/{tweet_id}
このときの{tweet_id}
に入っている値を指定します。
このコードを実行すると、以下のような結果を取得できます。 ※ 例として取得した値は編集されています。
{ "data": [ { "id": "1", "name": "サンプルA", "username": "sample_a" }, { "id": "2", "name": "サンプルB", "username": "sample_b" } ], "meta": { "result_count": 2 } }
あとはこれを使うだけです。
今回はテキストで出力したかったのでr.text
を使いましたが、以下の例のようにr.json()
を使うことでdict
形式で取得できます。
liking_users = r.json() users = liking_users.get('data') for user in users: print(user.get('username'))
注意
今回紹介したAPIは15分あたり75回の実行制限があります。 https://developer.twitter.com/en/docs/twitter-api/tweets/likes/api-reference/get-tweets-id-liking_users
1分あたり5回実行できるので、12秒に1回実行できる計算です。
一度エラー制限に引っかかるように使用し、その際に起きるエラーやステータスコードを確認した上で実装することをおすすめします。
2021年版 pythonの開発環境を整える
概要
pythonの開発環境を整えて、スクリプトを実行できるのを目標にします。
pythonの開発環境ですが、2021年7月現在で私が使用している構成を基にご紹介します。
私の場合は、pyenv
で任意のバージョンをインストールし、venv
を使ってローカル環境を作成しています。
以下その環境を導入するまでの目次です。
- 作業環境について
pyenv
をインストールするpyenv
の使い方- pythonをインストールする
- 使用するバージョンを設定する
- 仮想環境を使う
- 注意すること
作業環境について
- ProductName: macOS
- ProductVersion: 11.2.3
- BuildVersion: 20D91
- Homebrew 3.2.0
- zsh 5.8 (x86_64-apple-darwin20.0)
pyenv をインストールする
(公式のドキュメント)https://github.com/pyenv/pyenv通り、brew
を使ってインストールします。
brew install pyenv
git
を使った方法もありますが、管理が若干面倒なのでおすすめしません。
ただし、最新のバージョンを使用することができるので、バージョンを切り替えたりしたい方にはおすすめです。
一般的にwebの開発をしている方にとっては不要だと思います。
pyenv
をインストールできたら、~/.zshrc
に以下の記述を追加します。
###################################################### # python settings ###################################################### # pyenv export PYENV_ROOT="$HOME/.pyenv" export PATH="$PYENV_ROOT/bin:$PATH" if command -v pyenv 1>/dev/null 2>&1; then eval "$(pyenv init -)" fi
(見やすくするためにpython
用の設定とわかるようにしています)
pyenv の使い方
pyenv
のヘルプを確認する場合は、以下のコマンドを実行すると確認できます。
pyenv --help
pythonをインストールする
pythonの3.9.4
をインストールする
pyenv install 3.9.4
python2
環境用に2.7.18
をインストールする
pyenv install 2.7.18
使用するバージョンを設定する
pyenv
のグローバルにデフォルトで3.9.4
を使用するようにし、python2用に2.7.18
を使うようにする
pyenv global 3.9.4 2.7.18
カレントディレクトリで使用するバージョンを指定する
pyenv local 3.9.4
仮想環境を使う
python
コマンドを利用して、仮想環境を用意する
python -m venv venv
上記コマンドを実行すると、venv
というディレクトリが作成されます。
仮想環境を使用する
source ./venv/bin/activate
すると、ターミナルが以下の様になります。
(venv) ➜ ~/sample ✗
この状態でpip
コマンドを利用してライブラリをインストールできます。
ためしに、requests
をインストールするコマンドを例として出します。
pip install requests
仮想環境の利用をやめる
deactivate
deactivate
と打つと仮想環境の利用をやめることができます。
注意すること
venv
を利用した開発の場合、作成されるバージョンはグローバルのpython
のバージョンと一致します。
今回の場合だと3.9.4
で仮想環境が作成されます。
例えば、以下のコマンドを実行すると、バージョンが3.9.1
の環境を用意できます。
pyenv install 3.9.1 pyenv local 3.9.1 python -m venv venv_391 source ./venv_391/bin/activate python --version
--version
の結果
Python 3.9.1
これを利用すると、1つのプロジェクトに複数のバージョンの環境を用意できます。
virtualenv
を使った場合、特定のバージョンを利用して名前をつけて環境を用意する必要がありました。
これがローカルファイル(venv
等)で用意できるので、環境の切り替えが簡単になります。
Bootstrap5を使ったレビュー一覧画面を作りました。
概要
2019年に作成したプログラムを改修し、bootstrap5を利用したレビューの一覧画面を作成しました。
テンプレートはWordPress用ではなく、自ら開発する方向けとなっています。
例えば、現在作成しているサービスのレビューサイトへ追加するといったことが可能です。
開発時にvuejsやreactjsに移行しやすいようにjavascriptの実装は最低限としているため、動きのあるテンプレートではありません。
ご利用方法や詳細については下記を参考にお願いいたします。
ビルド済みのファイルについては含まれません。
理由としては、webpackを利用してファイルをビルドしているため、ビルド済みのファイルを含めると参照パスが正しく設定されないためです。
動作を確認する場合、後述のビルドコマンドを実行してください。
サンプル画像
購入はこちらからできます。
https://samplecodes.uc.r.appspot.com/checkout/start/3
レビュー一覧テンプレートについて
以下の機能が含まれています。
- レビュー評価のプログレスバー
- レビューの一覧
- レビューの一覧をソートするセレクトボックス
- レビューを投稿するためのモーダルウィンドウ
- ページング用のリンク
- mobile向けのレスポンシブ機能
- 表示しているレビュー位置 (例: 1 - 10 of 20 review)
レビューの内容は以下の要素が含まれています。
- タイトル
- 投稿日時 (例: 2019-07-25 post)
- レビューの内容
- レート (星の数を表示)
利用する際に必要なスキルについて
- htmlを書けること
- javascript or typescriptを書けること
- webpackによるビルド方法がわかること
- css or scssを書けること
購入ファイルについて
. ├── package-lock.json ├── package.json ├── readme.md ├── src │ ├── assets │ │ ├── reset │ │ │ ├── normalize.scss │ │ │ └── scripts.ts │ │ └── review │ │ ├── scripts.ts │ │ └── styles.scss │ └── html │ └── index.html ├── tsconfig.dev.json ├── tsconfig.json ├── tsconfig.prod.json ├── webpack.base.config.js ├── webpack.dev.config.js └── webpack.prod.config.js
動作環境について
- node: v16.1.0
- npm: 7.11.2
利用方法について
利用する際は以下のように利用してください。
- npm install
- npm run webpack-dev
- webpackによってビルドが行われ、distフォルダが作成されます。
- src/html/index.htmlを開きます。
webpack-prodを実行すると、プロダクション環境へデプロイするためのコードを生成できます。 具体的な設定については、以下のファイルを確認してください。
- tsconfig.prod.json
- webpack.prod.config.js
購入はこちらからできます。
https://samplecodes.uc.r.appspot.com/checkout/start/3
「会社はムダが9割」という本を読んでみた感想
本のタイトルから気になって読んでみました。
エンジニアの立場からするとムダなことを簡略化して、無くすということを考えることがあります。
その参考にしようと思って読んでみました。
感想
1回読んだときは内容が頭に入ってきませんでした。
ISO?なにそれ。そんなことよりも、ムダの改善方法や事例を教えてくれと。
「○○はムダ」という章に対して、それがなぜムダなのかがわかりやすく書かれていないこと、どのような基準で「ムダ」といっているのかが分からなかったからです。
例えば「社員同士で遠慮するムダ」という章があるのですが、最後の方でようやく「遠慮を無くすことで仕事が上手く回り始めた」といった記載がありました。
ただ、それも結局「仕事をどんどん振って現場に連れて行く」ということをやるようにアドバイスをしたからと読み取れました。
定価で買うだけの価値はないかな?
という感想がはじめに来ました。中古本かKindleUnlimitedで0円で読むのが良いと思います。
分かりづらい部分もありますが、参考になる箇所もあります。
話の中には実は自分もやっているかなと思うものがありました。
例えば「実行しないムダ」「自分のことがわからないムダ」という章があります。
前者は計画を立てただけでは意味が無く、走りながら修正する。
実際に運用しながら微調整を加えて精度を上げるというものです。
後者は自分の性質を知るということ。
何をしたいのか、何が好きなのか、何が嫌いなのか。
現状分析を行い、ゴールから逆算して計画を見直すことで結果が出せるというものです。
まとめ
私が「会社はムダが9割」という本で得られたことは、会社内のムダを知るというよりも、自分のための気づきでした。
今の自分が何を改善すればよいのかという指標を得るためのツールとして、この本を使うのが良いと思います。
DjangoでPageNotFound時にjsonを返す方法
Djangoでapiを作っている際に、自分で定義していないpathをリクエストしたところ404ページが表示されました。
apiを使うため、これをjsonで返すように変更したいと考えて、実現する方法を調べてみました。
参考にしたページ一覧
Error handling
https://docs.djangoproject.com/en/3.0/topics/http/urls/#error-handling
handler404
https://docs.djangoproject.com/en/3.0/ref/urls/#handler404
Customizing error views
https://docs.djangoproject.com/en/3.0/topics/http/views/#customizing-error-views
実現方法
まずはproject/urls.py
を以下のようにします。
from django.http import JsonResponse from django.urls import path, include def handle_404(request, exception): return JsonResponse({"status": "page not found."}) def handle_403(request, exception): return JsonResponse({"status": "forbidden."}) def handle_500(request): return JsonResponse({"status": "server error."}) urlpatterns = [ path('api/', include('api.urls')), ] handler403 = 'project.urls.handle_403' handler404 = 'project.urls.handle_404' handler500 = 'project.urls.handle_500'
この記述の中のhandlerXXX
が重要な部分です。
この記述はurls.py
に書くようにドキュメントにかかれています。
また、参考にできるコードはdjango.views.defaults.page_not_found
から確認できます。
import用のパスをproject.urls.handle_403
のようにしていますが、これは以下のように関数を代入しても良いです。
handler403 = handle_403 handler404 = handle_404 handler500 = handle_500
handle_404
関数についてはurls.py
に書く必要はなく、別のファイルに書いても大丈夫です。
例えば、restframework
用の例外ハンドラと同じ場所に書くのが良いと思います。
検証
検証する際にDEBUG = TRUE
ではできないのでFALSE
にします。
curl
を利用してリクエストします。
curl http://localhost:8000/api/hoge/piyo
結果
{"status": "page not found."}
このときのexception
変数のインスタンスはResolver404
でした。
404
でハンドリングしているため、Http404
で例外が出ていると予想していたのですが間違っていました。
というかdocstring
に以下のように書かれていたのでわかっていませんでした。
The message from the exception which triggered the 404 (if one was supplied), or the exception class name
なんのインスタンスなのか書いておいてほしいです。
Resolver404
だったので、api内部でraise Http404
としてもハンドラでキャッチされませんでした。
私の場合はdjangorestframework
用の例外ハンドラを用意していたので、そちらでキャッチされました。