分割代入について。 配列からデータを変数に代入する、さまざまな方法が書いてあった。
未サポートのブラウザが多いので注意。
自分は読み飛ばしたが、リンクには、オブジェクトからの取り出しについても記載がある。
分割代入について。 配列からデータを変数に代入する、さまざまな方法が書いてあった。
未サポートのブラウザが多いので注意。
自分は読み飛ばしたが、リンクには、オブジェクトからの取り出しについても記載がある。
ソフトウェアは複雑だ。すぐ人間に管理できなくなる。 言い換えると、仕様変更があったとき、どこを変更すればいいのか、すぐわからなくなる。 そうならないために、プログラムを分割して複雑さを低く保つという考えがある。分割したひとつひとつをモジュールと呼ぶ。どういうふうにモジュールを区切ればいいかの指標として、結合度と凝集度という考え方がある。
モジュール内の要素がすくないほど複雑度は減る。とはいえ、ひたすら細かく別モジュールに分けるべきではない。管理の手間がむしろ増える。関わりの強い要素をうまくひとつのモジュールとして切り出すべきだ。モジュール内の要素の関わりの強さを凝集度と呼ぶ。 じつは、すべての入出力操作をひとつにまとめたモジュールというのは、凝集度が低い。論理的な関係よりも、機能の関連度で評価するべきだからだ。そういう意味で、オブジェクト指向の多くのクラスは凝集度が低い。各メソッドで凝集度を高くなるように意識すべきだ。 ひとつの機能を実行するためにすべての命令が関連しているモジュールは、凝集度が高い。たとえば、秒速を時速に変換するメソッドだ。
モジュール内の変更が他のモジュールに影響を及ぼさないように注意すべきだ。他のモジュールへの影響しやすさのことを結合度と呼ぶ。結合度は低いほうが良い。 たとえば、あるモジュールが他のモジュールの内部を直接参照する実装は結合度が高く、避けるべきだ。 結合度が低い(=良い)状態とは、入力データと出力データをやり取りする形でモジュールが結合しているという状態だ。モジュール内を変更しても、入出力形式が同じなら、ほかのモジュールへの影響はない。
MySQLでは、テーブルごとに「テーブル型」を設定できる。これをストレージエンジンと呼ぶ。 ストレージエンジンが違うと、データの格納、取り出しの内部的な処理が変わる。 各々のエンジンに特徴があり、開発者は目的に応じて使い分けるのが望ましい。 ストレージエンジンには、たとえばMYISAM、InnoDB、BLACKHOLE、MEMORYといったものがある。 使用できるエンジンは、
mysql> SHOW ENGINES;
で確認できる。ちなみに横長すぎて見づらければ
mysql> SHOW ENGINES\G
とすれば出力形式を縦長にできる。
現在存在するテーブルの型を知りたい場合、
mysql> SHOW TABLE STATUS;
で確認できる。
Railsアプリを作るにあたり、ストレージエンジンを考えてみた。 トラブル時に対応が載っている可能性が高いため、人気なのを使用したい。InnoDBかMyISAMに絞られるだろう。 比べてみると、InnoDBはトランザクション処理が可能、外部キー制約が使える、クラッシュ時比較的復旧しやすいとのこと。 MyISAMはレコードのカウントが高速、オーバーヘッドが小さいらしい。
Railsの場合、トランザクションをsave,save!,destroyといったメソッドで活用しているらしい。また、アソシエーションで外部キー制約を活用している。さらに、デフォルトでInnoDBのテーブル型を指定している。ならInnoDBでいいかな?
ほとんどのRailsアプリは、InnoDB使っておけばいいんじゃないかなと思った。
以下参考
MySQL :: MySQL 5.6 リファレンスマニュアル :: 15 代替ストレージエンジン
MySQL :: MySQL 5.6 リファレンスマニュアル :: 14.1.1 デフォルトの MySQL ストレージエンジンとしての InnoDB
UNIX系OSでは、ファイルごとにアクセス権(パーミッション、モードなどとも呼ばれる)が設定されている。 これらアクセス権により、ユーザーからのファイルの見え方、操作できることが決まる。
アクセス権は基本的に3種類ある。Read、Write、eXecuteだ。また、権限を設定する対象(クラス)が3種類ある。User、Group、Otherだ。アクセス権と対象の組み合わせで、3×3=計9種類のアクセス権が存在する。このほかに、実行に関係する特殊なアクセス権がある。SetUserID、SetGroupID、sTickyの3種類だ。よって計12種類。それぞれの権限の有無が、ファイルごとに設定されている。
後述の八進数表記を鑑みるに、特殊権限、Userの権限、Groupの権限、Otherの権限、の順にビットがならんでいるのかな?
ls -l
を実行すると、ファイルのアクセス権が確認できる。ちなみに左端の文字の意味は下記の通り。
アクセス権は chmod
(CHange MODe)コマンドで変更できる。chmodコマンドでのアクセス件の指定方法には、記号表記と八進数表記の二種類がある。
ファイル作成時のデフォルト権限は、"umask"というビットマスクで決まる。通常、新規ファイルは0666,新規ディレクトリファイルは0777からそれぞれumaskの値を引いた権限が設定される。
umaskでは許可しない権限を指定している、と言い換えても良い。
多くの場合は0022が設定されている。
umask
で確認可能である。
クラスのメンバーにはプロパティとメソッドがある。 キーワードを指定することで各メンバーへのアクセス権を設定できる。 キーワードはpublic,private,protectedの3種類。定義時にキーワードを宣言する。
あるクラスのメソッドを呼び出したいとき、 メソッドをpublicにしておけば、インスタンスからアクセスすることができる。 privateだと直接アクセスできない。(そのクラス内からしかアクセスできない)
<?php class MyClass { public function PublicFunc() { echo "useful function." , PHP_EOL; } private function PrivateFunc() { echo "another useful function." , PHP_EOL; } } $obj = new Myclass(); $obj->PublicFunc(); //呼び出せる $obj->PrivateFunc(); //Fatal error
ただ、安易にpublicにするのは危険な気がする。どういう危険があるのか、どういうときならpublicにしてもいいのか、わかったら書こう。
<追記>
単にメソッドを使いまわしたいな、というときは、staticを宣言したほうがインスタンスを作らずに済むので良い。
<?php class MyUtil { public static function StaticFunc() { echo "useful function." , PHP_EOL; } } MyUtil::StaticFunc(); //=> "useful function."