令和6年秋期試験 午後問8(情報システム開発)についての投稿を受け付けるスレッドです。

この投稿は投稿者により削除されました。(2024.10.13 16:01)

1 カプセル化  継承  ポリモーフィズム
2-1 データ取得（）
2-2 オ、ア
2-3 フォーマット  プロトコル
3-1 連携データ コネクタ
3-2 フォーマット
にしました

XML, HTTPS
にしました。下の方◯◯クラスで答えちゃいました

3-1が全然わかんなかったなぁ。インスタンス作成だけじゃなんで研究受講記録データを新しいシステムに送信することができないのか。

2-3 g,hは自分もXMLとHTTPSです

それが正しいですね
やってしまった

ポリモーフィズムではなく、オーバーロードだと思います

設問1のcはオーバーロードって書こうとしたけど、違和感があって純粋仮想関数って書いてしまった
絶対に間違っていると思う

設問3-1は、片方は連携データで良いと思ったけど、もう片方は自信なさげに<<interface>>コネクタと書いた
<<interface>>が無駄だったかもしれない

後はあかさたさんと同じです

1-c  はポリモーフィズムだと思います
----------------------------------------
ポリモーフィズムとはオブジェクト指向プログラミングの概念の一つです。
日本語では多態性・多様性などと訳されます。
簡単に言うと同じ名前のメソッドを複数のクラスで使用できるようにし、そのメソッドを通して、暗黙的に複数のインスタンスの動作を切り替えることができるようにします。

継承とオーバーライドの意味違うんだ...

設問3の(1)は、プロトコルとフォーマットにしましたがどうでしょうか？

gはxmlと書いたのにhはプロトコルにしてしまった。。後はあかさたさんと同じです。cは異なる処理、ようは振る舞いを変えることなのでポリモーフィズムと思います。

No.5の件、誰か教えていただけると幸いです。

3-1は「連携データクラス、研修データクラス、コネクタクラス、研修コネクタクラス」と書きました。

新規のクラス名はいらないですね。終わりです

設問5は図2が「組織データを送信する例」におけるクラス図（〔コネクタの利用方法〕参照）なので、研修受講記録データは組織データのインスタンスとしては作成できず、別途連携データクラスの子クラスとして研修受講記録データクラスを作成する必要があるのだろうと思います。
同じく、組織コネクタは組織データを送信する場合に使われるクラスなので、研修受講記録データを送信する場合にはそのためのコネクタを作らなくてはならず、別途コネクタクラスの子クラスとして研修受講記録コネクタを作成する必要があるものと思います。

なので答えは「連携データクラス、コネクタクラス」なのかなと。
自分は脳死で「フォーマットクラス、プロトコルクラス」と書いてしまいましたが確実にミスだと思ってます。

1カプセル化  継承  多相性（ポリモーフィズム）
2(1)データ取得()
(2)オ  ア
(3)XML HTTPS
3(1)コネクタ，連携データ
(2)フォーマット

結論的にはこうなりますかね
3(1)まちがえたなぁ…

親クラスとすべき、か、、、
新規のクラス名を書いてしまった

No.16
ありがとうございます。大変分かりやすかったです。

「組織データ」と「研修受講記録データ」の対比になっていたんですね
CSVデータならなんでも連携できるくらいの雰囲気で捉えてました…
こういうところで実務経験多い人と差が付くんでしょうね。

うわポリモーフィズムじゃなくてポリモフィズムって書いちゃった、これで減点されるのかな

「作成するクラスの親クラスとすべきクラス名」を「作成するクラスの親クラスと、(作成するクラスの)すべきクラス名」って意味だと思って、
「研修受講記録データ(親：連携データ)、研修受講記録コネクタ(親：コネクタ)」
って答えちゃった……部分点貰えるかな

ポリモーフィズムだけ最後まで考えても出てこず...
クラス図のインパクトの割に簡単で良かったです

3(1)で何が問われているか難しかったですよね
新規クラス名は任意の名前で良いので問題になるはずがないって後から思いました

結構簡単じゃんとか思ってたけど、しょっぱなのポリモーフィズムをオブジェクト指向設計って書くレベルには事故ってる。。うわああ

3(1) は部分点とかないですかね。。

オブジェクト指向普段から使ってる人にとってはかなり簡単な内容でしたね

設問1
a  カプセル化
b  継承
c  オーバーロード
設問2
(1)  データ取得()
(2)
e  エ
f  ア
(3)
g  フォーマット
h  プロトコル
設問3
(1)  連携データ、コネクタ
(2)  フォーマット

cはポリモーフィズムなの？
同名のメソッド呼び出しってあるからオーバーロードのことだろって思ったけど、もっと上位概念を聞いてきてるんなら確かにそうかもだけど、どっちでもええやんってなる

オ、アですね。保護はエではないです。

ポリモルフィズムと書きました。ポリモーフィズム、ポリモフィズム、ポリモルフィズム、いずれも参考書によってまちまちなのでどれでも正解だと信じたい

No.16さん、なるほど、ありがとうございます。

自分もオ、アと思ってます。
保護なので子クラスからは参照できるかと

設問1のcはオーバーロードって書いたんだが、文章の流れからはどう見ても矛盾ないでしょう
よく見るとオブジェクト指向に関して問う問題なので、運営側としてはポリモーフィズムと書かせたいのか？？

設問1のc
オーバーライドでも理解できるな

オ、ア  については、普通は公開範囲の緩さ順に、public 、protected、privateにすべきところ(もしくは逆)、なぜか、private,public,protectedと順番がぐちゃぐちゃで、引っ掛かけられた人もいるかもしれません。
出題者の方が普段書いているプログラムは、もしかしたらスパゲッティなのかも(；^^)

オーバーロードでも文が通るは同意なんだけど
選択肢にオーバーロードがある、の1点がメタ推理としてめっちゃ引っかかったからオーバーロードだけは避けたな
結果「多態化」と書いてバツ(多態性ならマル)。開始20分くらいでやっと思い出せて書いたのに。

まー理念的、抽象的な文脈なのでポリモーフィズムが良い答えなのは間違いない

この投稿は投稿者により削除されました。(2024.10.14 00:37)

私もc：オーバーロードと記載しました。ポリモーフィズムで勿論正解だろうけど、「同名のメソッド呼び出し」と細かく書くなら、オーバーロードも正解としてほしい。。。

設問1のcはポリモーフィズムにしました。
「オブジェクトの種類によって異なる処理を実行するc」の部分から
個人的にはオーバーロードの時は、1つのオブジェクト内で同名のメソッドを複数持つイメージなので、
メソッドを実行するオブジェクトが異なった場合かつ同名のメソッドだとオーバーライドに近い気がしたからです。
そしてオーバーライドはもう設問2の(2)で回答してしまっていたので、
ポリモーフィズムにしました。

しかし、「オブジェクトの種類によって異なる処理を実行するc」の「オブジェクト」が「同名のメソッドに引数として渡されるオブジェクト」という意味ならオーバーロードがしっくりくる気がします。

オーバーロードは同名のメソッドを呼出しに対して異なる処理を実行できるようにするものではありますが、"オブジェクトの種類によって"ではなく"引数の型や数の違いによって"実現されるものなので、cの正解はポリモーフィズムでしょう

ポリモーフィズムですが、普段使ってて、実用面では(参考書的な、多態性が～ではなく)どんなメリットがありますか？
また、皆さんどうやって使われていますか？

呼び出したメソッド名が、極論、全部一緒だと、
呼び出しもとをいちいち確認しなければいけないと思いまして。例えば、削除、更新、登録のメソッドを、全部「Resister」という名前にしてもよいということですよね？
クラス名で判別しているのですか？
それとも、「これは～という機能のポリモーフィズムです」みたいなコメントが、呼び出し時に見える？

無学な私にお教えください。
よろしくお願いいたします。

@スタティックは何処？
親クラスまたはインターフェイスのメソッド（sing()とします）をオーバーライドした子クラス（子１、子２）を作成します。

親クラス a = new 子1()
親クラス b = new 子2()
のように、「親クラス」型の変数に子クラスのインスタンスを代入できます。

すると、a.sing(), b.sing()は呼び出せますが、異なった結果を返します。
親クラス側にsing()が定義されているので、a.sing(), b.sing()が存在することは保証され、呼び出すことは出来ますが、オーバーライドされいる場合、呼び出されるメソッドは子クラス側で定義したものとなります。

普段、プログラミングで使っている言語次第で、オブジェクト指向は理解しにくいかもしれませんね。Javaみたいな、静的型付け+オブジェクト指向の言語を使っていればよくわかるのですが。

オーバロードは特に"オブジェクト指向"の目的ではなく、あったほうが便利なので付いている言語機能にすぎないないためcに入れて「実現することが可能である」に続けるのはポリモーフィズムが妥当でしょう。

>>40
メソッド名が実際の処理に合わせて適切であることは開発の前提です。
今回の問題でいえば「FTPS」「HTTPS」クラスの「送信」メソッドは当然データ送信処理を行うメソッドである必要があり、実は送信を行ってくれないということは論外なので考慮しません。
その前提で「送信」処理を呼び出すときに「どのように」送信するのかについては呼び出し元が把握しなくて済むように設計すると変更がしやすくなるというのが今回の問題のテーマです。
もともとの設計ではコネクタを連携先サービスに合わせて個別に開発しており、例えば当初FTPSで接続していたサービスがHTTPSでの接続に変更になった場合はその部分の処理を大きく書き換える必要があったのでしょう。
一方新設計のコネクタは「具体的な方法は分からないが送信機能を持っている"プロトコル"クラスのインスタンス」を受け取って、データを送信したいときは送信メソッドを呼び出すように作成されています。
そのためFTPSからHTTPSに連携方法が変わった場合でも、単に組織コネクタを生成する際に渡すプロトコルクラスのインスタンスをHTTPSクラスに変えるだけで、変更を完了できます。
これはポリモーフィズムのメリットの一例に過ぎませんが、参考になれば幸いです。

出題者の意向を汲むなら
図のメインのクラスがインタフェースなので
ポリモーフィズムでしょうね。

@だってねこだものさん

a.sing,
b.sing
それぞれメソッド名は同じでも、実行結果が異なるということですよね？

a.sing→ソーラン節を歌う
b.sing→アイドルを歌う

Soran.sing
Yoasobi.sing

みたいに普段は定義されているということですか？

@aki
メソッド名が実際の処理に合わせて適切であることは開発の前提です。
今回の問題でいえば「FTPS」「HTTPS」クラスの「送信」メソッドは当然データ送信処理を行うメソッドである必要があり、実は送信を行ってくれないということは論外なので考慮しません。
その前提で「送信」処理を呼び出すときに「どのように」送信するのかについては呼び出し元が把握しなくて済むように設計すると変更がしやすくなるというのが今回の問題のテーマです。
もともとの設計ではコネクタを連携先サービスに合わせて個別に開発しており、例えば当初FTPSで接続していたサービスがHTTPSでの接続に変更になった場合はその部分の処理を大きく書き換える必要があったのでしょう。

これはつまり、
コネクタ.送信()に
{

URI uri = new URI("～");
            URL url  = uri.toURL();
            HttpsURLConnection conn = (HttpsURLConnection)url.openConnection();
            conn.setRequestMethod("GET");
            conn.connect();
・
・
・
}
のようなものがあり、FTPS のときは、{}のなかのその都度処理をまるまる変えていたということですか？

これを、
コネクタ.送信()=プロトコル.送信()=
HTTPS.送信() OR FTPS.送信()
のようにしたということですか？

まず、
共通的なコネクタクラスがあって、
その下にプロトコルクラスがあって、
さらにその下のHTTPSクラスやFTPSクラスが実体である、ということですか？

@スタティックは何処？
改善前の作りについてはご認識の通りと予想します。
改善後についても、概ねあっていると思います。ただ「その下に」という表現はやや語弊があるかもしれませんので念の為補足します。
この問題ではコネクタ、フォーマット、プロトコルの全てにおいてポリモーフィズムを活用できるよう共通部分を親クラスやインターフェースに括りだしつつ実行時の実体はそれらを継承した子クラスとしています。
コネクタはおそらくさらに上位層の管理モジュールから生成され、そのタイミングでフォーマットとプロトコルの実体を受け取ります。コネクタは受け取ったプロトコルの実体が何であるかを意識せずに送信メソッドを呼び出すためプロトコル.送信を呼び出すようにコード上は記述しますが、実際に受け取ったインスタンスはHTTPSやFTPSであるためそれらの具体的実装に従った送信処理が行われます。
例えば上位モジュールがコネクタごとの使用プロトコルなどを設定ファイルから読み取り、それに合わせたクラスインスタンスを生成する仕組みなら設定ファイルを変えるだけで変更が済むようになるため保守上大きなメリットがあります。

ポリモーフィズムにはこのようにモジュール間の関係を動的に上位モジュールから変更できるようにして切り離す役割があるため、コネクタやプロトコルなどの関係は上下関係とはいいにくいかもしれません。

どなたか2-3の解説いただけないでしょうか。
g  フォーマット
h  プロトコル
としてしまいました。

>>47
①図2において、フォーマットとプロトコルは斜字体ですので抽象クラスであることが分かります。
②g,hの穴あきとなっている本文を見ると、「生成したインスタンスを引数に」とあることからインスタンス化したオブジェクトを渡していることがわかります。
①と②から抽象クラスはインスタンス化出来ませんから、抽象クラスのサブクラスが入ると予測し、XMLとHTTPSとしました。