[t-isechi]

リモートリポジトリ参考
http://amaebi.jp/?p=334

[t-isechi]

2/23変更
https://help.sakura.ad.jp/hc/ja/articles/206208121

[t-isechi]

payloadはチェックにカテゴリ情報を付加するためのAPI

[t-isechi]

表作成の際のDEFAULTオプション

11g以前では列のデフォルト値に、順序オブジェクトを参照するNEXTVAL疑似列やCURRVAL疑似列は指定できませんでしたが、12cから指定可能になりましたとさ。

CREATE SEQUENCE test;
CREATE TABLE sample(
t_id　　　　　number　　　　default test.nextval,
name　　　　varchar2(10)
);

[t-isechi]

【プロトタイピング】

いわゆる試作品を用いてシステム開発を行う手法。
プロトタイピングは用途に合わせて大きく２種類に分かれる。

１．検証や資料用
短時間で作成し、設計の実現性やリスク抽出、対応策の検証用に使用するもの。品質レベルやコーディング規則などは設定せず、用途が済めば破棄される。まだ受注が確定していない企画作業段階で作成されることが多い。

２．継続的に改良していくための土台
満たすべき品質や設計規約を定め、顧客との要求分析作業を経て改良していくためのもの。要求分析の段階で、顧客にシステムの具体的なイメージを持ってもらい、開発側との認識のズレを回避することができる。最終的にシステムとして使用する。

[t-isechi]

自分もこの機会に、インターフェースと継承の役割を再度考えて見ます。
多分に私見入ってるので、参考程度に。。。

まずは、ポリモーフィズムとは何ぞやってところから。
【ポリモーフィズム】
操作を依頼する側は相手のオブジェクトのクラスを意識しなくても、異なる操作が実行される仕組み

次にインターフェースと継承で、ポリモーフィズムを実現する場合ですが、

・インターフェース　⇒　実現
実現は、シグネチャ(操作名)のみで定義された実装のない抽象操作(抽象メソッド)を持つインターフェースと、それを実装するクラスとの関係。
インターフェースを実装することにより、メソッドの使い方を統一することができる。
また、インターフェースを実装したクラスのオブジェクトは、インターフェース型の参照変数に代入できるので、オブジェクトを意識することなくインターフェースを利用してメソッドを呼び出せる。

・継承　　　　　　　⇒　汎化
汎化は、共通部分を表すクラスと詳細部分を表すクラス間における分類の関係。
既存のクラスをもとに新しいクラスを作成することによって、クラスの再利用性を高めている。
複数のサブクラスで、共通のスーパークラスのメソッドをオーバーライドすれば、操作を依頼する側はスーパークラスの定義でメソッドを呼び出せば、各サブクラスの実装の違いは意識しなくても呼び出されたオブジェクトによって異なる結果を得られる。

どちらも特徴を理解して使いこなせば、メリットになるのは間違いないです。
どちらで実現するかは場合次第って感じですが、システム開発の面で考えたときにはどうでしょう。

システム開発の流れが以下だとします。
・企画作業
　開発するシステムのシステム構想を決定する
↓
・要求分析作業
　顧客業務のデータや業務の流れを理解し、システムとしてどのような機能が必要であるかを抽出する
↓
・仕様分析作業
　システム機能を実現するために、どのようなデータと処理が必要であるか、利用者の視点から明確にする
↓
・方式設計作業
　システム機能をどのように実現するか、基本方針(開発言語,システムの構造,データベース)を決定する
↓
・詳細設計作業
　仕様分析作業で明らかにしたデータと処理を、方式設計作業で決定した開発言語、システムの構造に従って、開発者の視点から実装ができるレベルまで詳細化する
↓
・実装作業
　設計作業で詳細化したデータと処理に従って、オブジェクトを実装し、ソースコードを作成する。クラス単位または関連を持つクラス間の仕様を検証する
↓
・結合テスト作業
　作成した全クラスを結合し、システムの処理が、仕様どおりに動作するかを検証する。
↓
・システムテスト作業
　総合的なテストを行い、システムの処理が、仕様どおりに動作するかを検証する。

こうして整理してみると、実装作業に入ってクラス間の仕様を決定するケースが一般的って言われてますね(実際はイレギュラーいっぱいあるだろうけど)。
そういう意味ではJava言語における単一継承が、設計に大きく関わることになってくるから、継承でポリモーフィズムを実現する予定だったけど、実装中に顧客の追加注文や、思わぬ設計の落とし穴が見つかった際に、実現不可に陥るパターンもあるかもしれない。
そのリスクを考えてポリモーフィズムはインターフェースメインで実現する方向で、実装が形になった段階で汎化できるところはまとめちゃうってのもありじゃないかな。

企画作業の段階で、顧客にイメージを持ってもらうためにプロトタイピングで仮システムを作ることもあるだろうし、納期も絶対関わってくる以上は色々な状況に対応できる引き出しが必要ってことっすね。

設計とか開発工程に関しては、今後も議論していきましょう。

[投稿者]

投稿