【調べものメモ】JavaScript系言語|カリー化|フレームワークについて|PHP学習について

(・・・実装ばかりやらずにベースの知識も蓄えないと・・・)

JavaScript系言語いろいろ
http://yohshiy.blog.fc2.com/blog-entry-183.html


カリー化

Play FrameWork
https://ja.wikipedia.org/wiki/Play_Framework
ScalaとJava用Frameworkで、Ruby on Railsに似ているとのこと

on the premises オンプレミス
社内にシステムの設備を持つこと。クラウド、XaaSと対になる考え方。

Hadoop
(未調査)

PHPのフレームワークたち
http://blog.a-way-out.net/blog/2015/03/26/php-framework-benchmark/

※PHP すこし昔のフレームワーク
Mojavi・・・strutsの考え方を持ち込んだらしい struts・・・ruby on railsは設定より規約というが、こちらは設定メインなんだろうか
Ethna


strutsやseaserについて
struts MVCに基づくフレームワーク
seaserはDIコンテナという考え方に基づくらしい。

DIコンテナについて
DI(Dependency Injection)の考え方とインターフェースを組み合わせれば、疎結合が実現できる。(抽象に依存する)
クライアントの実装として、
1. serviceを中でnewしてインスタンス化 → サービスを切り替えられない
2. 引数としてinstanceを受け取る → サービス切り替えが引数の変更だけで可能。だがサービスのインスタンスに依存する点は変わらない。また、受け取れるインスタンスは、ただ一つの具象クラスから発生したインスタンスでしかなく、できることはサービスクラスの柔軟性に依存する。
3. 2の引数の型を抽象化(interface型) → 引数を抽象化することで、サービスの特定の具象クラスに依存しなくて良くなる。
123の順に疎結合性が強まる。

DIコンテナを使えば、
DIコンテナにクラス同士の連携関係を書き、
クラス相互に参照させることなく、DIコンテナに全てぶら下がる形に一元化できる。
さらに、この設定をパターン化・スクリプト化し規約として自動的にクラス間の依存関係をつくってしまうのが「設定より規約」の考え方なのだろう。

※DIコンテナとサービスロケータを取り違えてはいけない・・・クライアントクラスにDIコンテナを組み込んでしまうと、DIコンテナとサービスクラス両方へ依存することになってしまう。
あくまでDIコンテナはDIコンテナとして独立させるべき。


------------
PHP学習
http://zapanet.info/blog/item/994
マンモス本が評判だが、実はPHPマニュアルを直接読むのが一番よい、とのこと。
日本 PHP ユーザ会




コメント

このブログの人気の投稿

分散処理など

VBAでEdge操作は不可能ではないが、ナンセンス

docker+nginx+wordpress リバースプロキシにてはまった件