FAQ
技術的な質問> チュートリアル> アプリケーション開発チュートリアル（実践編）
技術的な質問> チュートリアル> アプリケーション開発チュートリアル（実践編）
Q5：電卓Lesson13 複合コンポーネントの使用方法。
Q5-1：
チュートリアルの電卓Lesson13で複合コンポーネントの使用法が説明されています。複合コンポーネントとサブルーチンは良く似た使われ方をしますが、明確な違いはどこにあるのでしょうか？また、複合コンポーネントを使用して幾つもの階層を作成する場合の利点はどこにあるのでしょうか？複数の階層に分けてプログラムを設定すると全体が把握しづらく、バグを発見しにくいのではと推測しますが、私の推測は的を射ているでしょうか？
A5-1：
MZPlatformの[複合コンポーネント]は確かに一般的なプログラミング言語での『サブルーチン』の概念に近いかも知れません。
MZPlatformの[サブルーチン]は階層は変わるということはなく、一つに纏めておきたい処理を接続しておき、必要な時に「メソッド：処理を呼び出す」で、その処理を呼び出せるという利点があります。
[複合コンポーネント]の主な利点を挙げますと
①使用しているコンポーネント数が多くなった場合、[複合コンポーネント]内に纏めることによって、上位の階層でのコンポーネント数は減り、全体の処理が把握しやすくなります。
②[複合コンポーネント]のみを保存することができ、それを複数のアプリケーションで利用することもできます。
特定の機能を予め作成しておき、それを利用することで開発作業の効率化ができます。
ご指摘の通り、複数の階層に分けると全体が把握し辛くなるという欠点もございますので、あまり幾層にも分けることはお勧めしておりません。
ただバグに関しては、既に開発済みの複合コンポーネントを利用する場合には、発生の可能性は低くなっていきますから、一概には言えません。
[複合コンポーネント]には「公開メソッドの設定」など固有の設定があり、使用方法に慣れるのに時間が掛かる面もありますので、使用するコンポーネント数が少ない場合は［複合コンポーネント］を無理に使う必要はないかと存じます。
MZPlatformの[サブルーチン]は階層は変わるということはなく、一つに纏めておきたい処理を接続しておき、必要な時に「メソッド：処理を呼び出す」で、その処理を呼び出せるという利点があります。
[複合コンポーネント]の主な利点を挙げますと
①使用しているコンポーネント数が多くなった場合、[複合コンポーネント]内に纏めることによって、上位の階層でのコンポーネント数は減り、全体の処理が把握しやすくなります。
②[複合コンポーネント]のみを保存することができ、それを複数のアプリケーションで利用することもできます。
特定の機能を予め作成しておき、それを利用することで開発作業の効率化ができます。
ご指摘の通り、複数の階層に分けると全体が把握し辛くなるという欠点もございますので、あまり幾層にも分けることはお勧めしておりません。
ただバグに関しては、既に開発済みの複合コンポーネントを利用する場合には、発生の可能性は低くなっていきますから、一概には言えません。
[複合コンポーネント]には「公開メソッドの設定」など固有の設定があり、使用方法に慣れるのに時間が掛かる面もありますので、使用するコンポーネント数が少ない場合は［複合コンポーネント］を無理に使う必要はないかと存じます。
Q5-2：
実践編Lesson.13のStep.5「複合コンポーネントの利用」
複合コンポーネント内で「挿入」を押すとアプリケーションとフレームのコンポーネントの実行部分は、複合コンポーネント内にロードされないのは、それらの部分は、上位の階層だけに留めておけば良いからと判断して宜しいでしょうか？
実践編Lesson.13のStep.5「複合コンポーネントの利用」の「２）複合コンポーネントの編集」
複合コンポーネントにGUI部品を含めないとした理由は、各処理部分ごとに複合コンポーネントにまとめることにしたからでしょうか？ここでのGUIとはグラフィカルユーザーインターフェースのことでしょうか？
数値のボタンなどを上位の階層にまとめた利点はどこにあるのでしょうか？
ある1つのプログラムを複合コンポーネントとその上位のビルダーにわけるとき、何か制限はあるのでしょうか？それとも、どのようなプログラムでも適当な部分で分けることができるのでしょうか？
実践編Lesson.13のStep.5「複合コンポーネントの利用」の「４）サブルーチンの利用」
ここでのサブルーチンの利用は、何を目的としているのでしょうか？
これらのサブルーチンを設定しなければ、プログラムとして機能しないのでしょうか？「押し下げ処理」とは、ボタンを押す処理のことでしょうか？ボタンを押す部分は、複合コンポーネントではなく、それよりも上位の階層にまとめることにしたのではないのでしょうか？
実践編Lesson.13のStep.5「複合コンポーネントの利用」の「５）複合コンポーネントの中のメソッドを公開する」
公開することによって、上の階層のコンポーネントでメソッドとして設定できるようになるのでしょうか？
実践編Lesson.13のStep.5「複合コンポーネントの利用」の「６）公開メソッドを上の階層から使用する」
すべての接続元のコンポーネントを電卓モデルのコンポーネントにつなげる必要があるのでしょうか？ビルダーの上層において複合コンポーネントと連結しているコンポーネントのみ電卓モデルのコンポーネントと連結させれば良いように思えますが、この「電卓モデルのコンポーネント」をすべてのコンポーネントと連結させる概念は、何を元に構築されているのでしょうか？
電卓モデルのコンポーネントを結合させるコンポーネントには何か決まりがあるのでしょうか？それともすべてのコンポーネントをただ単に結合させれば良いのでしょうか？
複合コンポーネント内で「挿入」を押すとアプリケーションとフレームのコンポーネントの実行部分は、複合コンポーネント内にロードされないのは、それらの部分は、上位の階層だけに留めておけば良いからと判断して宜しいでしょうか？
実践編Lesson.13のStep.5「複合コンポーネントの利用」の「２）複合コンポーネントの編集」
複合コンポーネントにGUI部品を含めないとした理由は、各処理部分ごとに複合コンポーネントにまとめることにしたからでしょうか？ここでのGUIとはグラフィカルユーザーインターフェースのことでしょうか？
数値のボタンなどを上位の階層にまとめた利点はどこにあるのでしょうか？
ある1つのプログラムを複合コンポーネントとその上位のビルダーにわけるとき、何か制限はあるのでしょうか？それとも、どのようなプログラムでも適当な部分で分けることができるのでしょうか？
実践編Lesson.13のStep.5「複合コンポーネントの利用」の「４）サブルーチンの利用」
ここでのサブルーチンの利用は、何を目的としているのでしょうか？
これらのサブルーチンを設定しなければ、プログラムとして機能しないのでしょうか？「押し下げ処理」とは、ボタンを押す処理のことでしょうか？ボタンを押す部分は、複合コンポーネントではなく、それよりも上位の階層にまとめることにしたのではないのでしょうか？
実践編Lesson.13のStep.5「複合コンポーネントの利用」の「５）複合コンポーネントの中のメソッドを公開する」
公開することによって、上の階層のコンポーネントでメソッドとして設定できるようになるのでしょうか？
実践編Lesson.13のStep.5「複合コンポーネントの利用」の「６）公開メソッドを上の階層から使用する」
すべての接続元のコンポーネントを電卓モデルのコンポーネントにつなげる必要があるのでしょうか？ビルダーの上層において複合コンポーネントと連結しているコンポーネントのみ電卓モデルのコンポーネントと連結させれば良いように思えますが、この「電卓モデルのコンポーネント」をすべてのコンポーネントと連結させる概念は、何を元に構築されているのでしょうか？
電卓モデルのコンポーネントを結合させるコンポーネントには何か決まりがあるのでしょうか？それともすべてのコンポーネントをただ単に結合させれば良いのでしょうか？
A5-2：
(1)挿入操作でアプリケーションコンポーネントのメソッド起動がロードされない等について
「アプリケーション」コンポーネントは，一つのアプリケーション内に一つしか存在できません。
後から挿入するファイル内の「アプリケーション」コンポーネントは、もともとの「アプリケーション」コンポーネントとは「別のもの」であり、複数存在できないことから、ロードしない仕様になっております。
また、複合コンポーネント内にアプリケーションコンポーネントを配置することも出来ません。お気づきのように、アプリケーション自身の開始・終了に関係する処理は、最上位の階層で定義するのが好ましいと考えます。
(2)複合コンポーネントにGUI部品を含めないとした理由
アプリケーションの作成においてその構成方法は一つではありません。アプリケーション作成者の考え方により様々な構成が考えられます。
チュートリアルの本文中で「どうしてこのような構成にするのか」についての説明が不足していることをお詫び申し上げます。
このチュートリアルでは、概念的に「画面表示」と「計算処理」は違うものと考え、「画面表示」部分と「計算処理」部分を整理した構成にさせていただいております。
このようにすることによって、アプリケーション開発者にとって、全体の処理が把握しやすくなり、開発作業や後のメンテナンス作業が効率化できると考えております。
GUIとはグラフィカルユーザーインターフェースのことです。
MZプラットフォームでは、画面に表示され、ユーザが画面上で操作できる部品のことをGUI部品と呼んでおります。
複合コンポーネントの分け方に制限はございません。
(3)サブルーチンの目的、メソッドの公開について
「押し下げ処理」とはボタンを押した際に実行する処理です。
ボタンは上層にありユーザはこのボタンを押しますが、実際の処理は複合コンポーネント内で実行します。
(2)で申し上げましたように、画面表示と実際の処理とを分けた構成になっております。
サブルーチンにする必要は必ずしもありませんが、このようにすることにより、上層のコンポーネントから、公開されたサブルーチンのメソッドを一つ呼ぶことによって、続く処理を実行することが出来ます。
複合コンポーネントでメソッドを公開することにより、上層からこのメソッドを呼び出し出来るようになります。
(4)電卓モデルのコンポーネントにつなげる必要性
(2)で述べましたように、画面表示と処理とが分離しておりますため、接続しなければボタンを押しても何も実行されません。各ボタンのアクションイベントに、対応する実行メソッドを接続する必要があります。
「アプリケーション」コンポーネントは，一つのアプリケーション内に一つしか存在できません。
後から挿入するファイル内の「アプリケーション」コンポーネントは、もともとの「アプリケーション」コンポーネントとは「別のもの」であり、複数存在できないことから、ロードしない仕様になっております。
また、複合コンポーネント内にアプリケーションコンポーネントを配置することも出来ません。お気づきのように、アプリケーション自身の開始・終了に関係する処理は、最上位の階層で定義するのが好ましいと考えます。
(2)複合コンポーネントにGUI部品を含めないとした理由
アプリケーションの作成においてその構成方法は一つではありません。アプリケーション作成者の考え方により様々な構成が考えられます。
チュートリアルの本文中で「どうしてこのような構成にするのか」についての説明が不足していることをお詫び申し上げます。
このチュートリアルでは、概念的に「画面表示」と「計算処理」は違うものと考え、「画面表示」部分と「計算処理」部分を整理した構成にさせていただいております。
このようにすることによって、アプリケーション開発者にとって、全体の処理が把握しやすくなり、開発作業や後のメンテナンス作業が効率化できると考えております。
GUIとはグラフィカルユーザーインターフェースのことです。
MZプラットフォームでは、画面に表示され、ユーザが画面上で操作できる部品のことをGUI部品と呼んでおります。
複合コンポーネントの分け方に制限はございません。
(3)サブルーチンの目的、メソッドの公開について
「押し下げ処理」とはボタンを押した際に実行する処理です。
ボタンは上層にありユーザはこのボタンを押しますが、実際の処理は複合コンポーネント内で実行します。
(2)で申し上げましたように、画面表示と実際の処理とを分けた構成になっております。
サブルーチンにする必要は必ずしもありませんが、このようにすることにより、上層のコンポーネントから、公開されたサブルーチンのメソッドを一つ呼ぶことによって、続く処理を実行することが出来ます。
複合コンポーネントでメソッドを公開することにより、上層からこのメソッドを呼び出し出来るようになります。
(4)電卓モデルのコンポーネントにつなげる必要性
(2)で述べましたように、画面表示と処理とが分離しておりますため、接続しなければボタンを押しても何も実行されません。各ボタンのアクションイベントに、対応する実行メソッドを接続する必要があります。
Q5-3：
複合コンポーネントをもちいた場合の階層化についてお伺いします。ビルダーの一番上層で複数の複合コンポーネントを作成した場合、これらの階層は、いずれも上から2番目の階層となるのでしょうか？すなわち、幾つもの階層が並列して存在できるのでしょうか？また、複合コンポーネントで作成した階層の中で複合コンポーネントを作成すると 更にその下にそのコンポーネントの階層が作成できるのでしょうか？
A5-3：
複合コンポーネントは階層的に作成することが出来ます。最上層で複数の複合コンポーネントを作成した場合、それらはすべて2番目の階層となります。
その中に更に複合コンポーネントを作成し、3番目、4番目・・・の階層を作成することも出来ます。
その中に更に複合コンポーネントを作成し、3番目、4番目・・・の階層を作成することも出来ます。