プログラマ専用SNS ミクプラ

僕がC言語を習い始めて４年と２ヶ月、C++の勉強を始めて３年…
なのですが、オブジェクト指向について本格的に勉強をしたことがないため理解が浅かったりします

学校のC++の授業でもクラスの扱い方をアレコレ教わっただけで、カプセル化とかオブジェクト指向そのものについての説明は殆ど無かったりしました
ですが、C++の勉強を始めて３年と節目とも言える(？)今日この頃、今一度オブジェクト指向についてしっかり学ぶ必要が出て来ました（まぁオブジェクト指向を知らずC++を勉強したと言えるのかどうかも怪しいですが(苦笑)）

所が今は「オブジェクト指向＝クラスを使ってカプセル化を徹底する」くらいの認識しかないのが現状です
クラスの扱いについては授業でならったり、手元に参考書があったりでそれなりには理解しているつもりですが…

ネットで調べてみようにも、どこも小難しい事を書いててイマイチ理解できません
まずは漠然とでもいいので簡単に、それから徐々にに理解を深めていこうかと考えていますが
どなたかオブジェクト指向について噛み砕いてでも良いので分かりやすく教えて、または分かりやすいサイトを教えて頂けないでしょうか？
ついでにカプセル化など、オブジェクト指向の具体的な手法なども教えて頂けると嬉しいです。

オブジェクト指向の定義は曖昧なのですが、個人的には

1. インスタンスが複数存在できること
2. インスタンス中心に構造化を極めること

がオブジェクト指向の基本(第一段階)だと思います。

目的はコードの再利用性を高めることです。

C言語でもオブジェクト指向(っぽい)プログラミングは可能です。
C++では
enemy->move(x, y);
とか書くのをC言語では
enemy_move(enemy, x, y);
というふうに書くわけです。
この書き方でもカプセル化は可能です。
#むしろカプセル化に関してはC++より完璧かも。
このレベルで構造化を頑張ってみるとC++のありがたさがより実感できるのではないかなあと思います。
C言語ではいちいち型変換のコードを書いてたのが、多態性があると型変換のコードが要らない上に無理な型変換をコンパイルエラーで弾いてくれる、とか。

オブジェクト指向の説明というより(C++の)クラスについての説明になりますが、「クラスというシステム」は「全く新しい型を作り出すことができるシステム」であると私は考えています。

例えばC++の標準ライブラリには　std::string　というクラスがあります。

この　std::string　を使ってみるとわかると思いますが、クラスの内部で何が行われているのかを私達が気にする必要は全くないわけです。

それ以前に、それがクラスであるということ自体　忘れてしまうのではないでしょうか。

そう。それがまるで「新しい型」であるかのように。

これこそがC++におけるクラスの本質だと私は考えています。


さて、一般的なオブジェクト指向の話となると、そうですね、1つのクラスで1つのプロジェクトを作り上げるイメージでしょうか。

例えば自キャラに関する処理は私に全部任せてください　というクラスをつくったりとか。

関連性の深い変数や関数を一箇所に集めると、外の事を全く気にせずその内部のことだけを考えるだけで済むわけです。

ただ、これはスタティック変数を用いることによって実現できる場合もあります。


「新しい型」という考え方は、オブジェクト指向とは関係がないかもしれません。

ただ、利用者が内部を気にする必要がないという部分には、カプセル化やオブジェクト指向につながるものがあると思います。

何かを題材にオブジェクト指向で書いてみると言うのも良いんじゃないでしょうか。
カプセル化に拘っておられますが、オブジェクト（対象）と言う要素にも拘ってみてください。どの様にデータを保持して、どの様にコンストラクタ・メンバ関数で処理するかと言う点です。
例えばじゃんけんゲームとか初心者向きのテーマがありますが、これをオブジェクト指向で書くなんてどうでしょうか？

僕はオブジェクト指向を使ったソフトウェアの設計をHead Firstオブジェクト指向分析設計で学びました。
この本はプログラミング言語としてJavaを採用していますが、考え方は他のオブジェクト指向言語にも通用します。
それから、外人さん特有のノリで読んでて新鮮で楽しかったです。
参考までにどうぞ。

気持ちよくわかります。
私もなんちゃってC++がなかなか抜けなかった人間です。
CとC++は互換性があるので、オブジェクト指向でなくても実行できてしまうため、ついつい、自分が既に知っている方法で実装してしまい、
結果的に完全なオブジェクト指向で設計出来ないことがあるんですよね。

なので、一度JAVAやC#のように完全にクラス単位でなければコンパイル出来ない言語で学んでみると良いと思います。
特にC#は最近ドンドン便利な機能が追加され、適切な設計がしやすくなっています。
C++には直接その機能は無くとも、C#で学んだ概念をC++で活かすということは出来るので、非常に有効だと思います。
（Boostもありますしね）
# ちなみに私は最近もうC++でコードを書きたくありません。。。

私は最近Androidアプリを作ることにはまっているのですが、これはすごくおすすめです。
アプリは小さなActivity単位で分割されていて、他のActivityとの直接的なつながりは無いため(Intentによる間接的なつながりのみ)
大きなアプリになっても、大規模な設計をする必要がなく、一つつまずいたから全部やり直しなんてことにはなりません。
それでいて、SDKの仕組みがオブジェクト指向で、またリスナーを実装しなければないため、自然とインターフェイスの理解が進み、
まとまりが小さいので、デザインパターンも小規模な物からチャレンジ出来ます。

他の言語に手を出すのがハードルが高いということであれば、やはり定番で、お手本を読みつつ実装することでしょうか。
C++でゲームを作る解説本なら沢山あるので、一度書店に行って自分に合いそうなものを探してみてはいかがでしょうか。

まずは「ポリモーフィズム」というキーワードを元に学ぶと良いと思います。

うわぁ…
予想以上に錚錚たる方々からの回答が…！　今度はどんな事を教えてくれるんだろうって名前を見ただけでちょっとだけ心が躍ってました(笑)

＞ISLeさん

オブジェクト指向の定義は曖昧なのですが、個人的には
1.インスタンスが複数存在できること
2.インスタンス中心に構造化を極めること
がオブジェクト指向の基本(第一段階)だと思います。

目的はコードの再利用性を高めることです。

インスタンス…つまりクラスのメンバが持っている実際の値、ですよね？

画像なら画像を専門に扱うクラスがあって、そのクラスは画像のハンドルや描画座標・拡大率や透明度等の必要な情報(これらがインスタンス？)を全て持っており、また描画や画像の読み込み・破棄等の関数も全てクラスの中に組み込まれている
そしてその画像クラスは宣言の時に配列で宣言したり、別の名前で宣言すれば同じ型を持った複数のクラスを扱うこともできる…

つまりはこう言うことでしょうか？
これくらいならば今の知識でも問題無く出来そうですが…


＞MoNoQLoREATORさん
なんだか前半が哲学的ですね(汗)

さて、一般的なオブジェクト指向の話となると、そうですね、1つのクラスで1つのプロジェクトを作り上げるイメージでしょうか。

C#でXNAを使ってゲームを作った時も、"ゲーム"というひとつのクラスを作りましたが、つまりはそう言うことでしょうか？
つまるところ、自キャラは自キャラのクラス、敵キャラは敵キャラのクラス、エフェクトはエフェクトのクラスを作って
それぞれの情報の管理と処理は全てそれらのクラス内の関数で行う、ゲームのクラスはそれらを然るべき順番で処理させるためのモノ、と言うことでしょうか？
やっぱりカプセル化を徹底すること、でしょうか。　…どうしても思考がそこに行きついてしまいます(苦笑)


＞softyaさん
いつもお世話になっています。　冗談抜きでDixqさん・ISLeさんと並んで一番お世話になっているきがしますね(笑)

う～ん、昨年C#を使った作品制作を行ったことがあるのですが
ゲームの動きそのものをクラスで処理するのにはかなり手間取った覚えがあります（汗）
C#でしかも経験がなおXNAだったから、なのかもしれませんけどね…。

オブジェクト指向を強く意識してゲームを作ってみる、ですか。　良いかも知れませんね！
もしくは今制作中のモノが出来上がった後でリファクタリングする時になるべくカプセル化を徹底して見るとか…
プログラミングで”習うより慣れろ”と言うのは一瞬どうかと思いましたが、ある程度下地があるならむしろアリかも知れませんね

今作成中のものか、次に作る予定のものかは分かりませんが、とにかく実践してみますね！


＞beatleさん
ありがとうございます～

しかし参考書で４０００円オーバーとは…(汗)
サブPCを新しく買おうと思ってお金を溜めている僕には厳しいものが…！

でも確か教務員室の本棚に参考書が一杯ありましたから、明日にでもそこを探してみますね…ｗ


＞Dixqさん

CとC++は互換性があるので、オブジェクト指向でなくても実行できてしまうため、ついつい、自分が既に知っている方法で実装してしまい、
結果的に完全なオブジェクト指向で設計出来ないことがあるんですよね。

余りにも今の僕に当てはまり過ぎていてちょっと悲しみが(オイ)

C#での開発は２回行ったことがあります、でも上でも書きましたがゲームの流れそのものをクラスで管理するのにはとても手間取った覚えがあります。

龍神録みたいに、メイン関数は独立していてそこから必要に応じて自由に必要な関数を自由に呼び出せる
というスタイルがかなりやりやすかったりします(苦笑)
Dixqさんご自身は「あまり良くない例」と言っていましたが、最初に本格的に触れたゲームプログラミングがアレだったお陰で、あのやり方が大好きだったりします。
もっともBGMの管理だとか、他のプロジェクトに使い回せそうな所は既に自分用のクラスを作って纏めていたり
なるべく何処にも属さないグローバル変数を減らしたりはしていますけどね。
やっぱりあのやり方を完全に脱却できておらず、カプセル化とも程遠いのが現状です(苦笑)

「ポリモーフィズム」…？　聞いたことのない単語が…。
調べてみますね！　ご教授、ありがとうございます。

これは私見ですが、オブジェクト指向について重要なことについて3点ほど書いてみます。
それぞれ、「独立性」「カテゴライズ」「実装とアクセスの分離」というのが重要なキーワードだと思います。

・独立性

　これは、一つのオブジェクトが、その役割について完結した形でその責任を果たすようにするということです。これは、他の回答者様も仰っているように、「『オブジェクトの内部で何が行われているか？』ということは、オブジェクトの外部からは分からないけれども、『そのオブジェクトがやるべき仕事』はちゃんと実行すること」だと思ってください。MoNoQLoREATORさんが挙げた、stringクラスの例で言えば、stringクラスの内部については分からないけれども、「文字列を扱うこと」に対してはきっちりと責任を果たさなければならないということです。
　隠蔽というのは、独立性を保証するために必要なことだと私は考えています。

・カテゴライズ

　これは、クラスの継承と密接に関わる話ですが、オブジェクトとして扱われるクラスについては、「基底－派生」の間では、カテゴリが一致しかつ派生されたものの方がより具体的なものでなければならないということです。要するに、「鳥類」から「ふくろう」・「わし」とか、「人間」から「大人」・「子供」といった派生でなければならないということですね。「タイヤ」から「車」を派生するなどといったカテゴリを無視した派生は、少なくともオブジェクト指向の観点からすればよろしくないということです。

・実装とアクセスの分離

　要するに、インターフェイスの扱い方の話ですね。例えば、鳥類と飛行機は共に空を飛ぶわけですが、カテゴリが違いますから、鳥類と飛行機が同じ基底クラスを持つというのはありえない話です。しかし、「空を飛ぶ」という点では同じことなので、IFlyable（空を飛べる） のようなインターフェイスを、鳥類クラスと飛行機クラスが共に実装するというのはおかしな話ではないわけです。
　ですが、確かに、「空を飛ぶ」というのは共通するかもしれないけれども、鳥類と飛行機では全くそのプロセスが異なりますから、同じ実装を提供することは不可能です。つまり、「空を飛ぶ」インターフェイスと、それぞれの「空を飛ぶ」実装は完全に分離されることになります。これが、「実装とアクセスの分離」という話です。

難しいお話は他の方がしてくださるでしょうし私も初心者なんで思ったことだけ書きますね(^_^;。
というかみなさんの答えにはとても経験が詰まっているのを感じます。
読んでいて「あるぇ？私が話すことなくね？？言われちゃってるジャン」ってなりました。何度も反復して読み直すといいかもしれませんね。

管理人様も言っているようにC++ってマルチパラダイムですから、意外とオブジェクト指向「を」C++で学ぼうと思うと他より混乱する気もします。
(でも私個人的にはそれはC++の柔軟性なんですが・・・関係ないか

オブジェクト指向でよく言われることとして「カプセル化」があって。でもなんで隠蔽するんだ？そう思ったことがあります。
これの答えは小難しい言葉を並べることも出来ますが、正直私は「安全に～、効率よくするため！」に落ち着くと思います。
きっと他の「ポリモーフィズム」とかも全部「安全に～、効率よくするため！」でいいんじゃないでしょうか。正しい思想とかを学ぶ前に、
「わかりやすい結果としてどんな恩恵があるか」について調べたり考えてみたりすると良いと思います。

「安全に～、効率よくするため！」というだけ？とか思います。もちろん他にもありますがねｗ
小難しいことばかり書くサイトはほんとうに多いです。いえ、それは今後役に立つので悪いものではないのですが。

それでもやっぱり、「ゲーム？何に使うのかわかんないけど使ってみるか」と「これはゲームと言って、遊ぶと楽しいのか！！使ってみよう」じゃ違うかな、とか思いました　まる
まぁ、難しいお話は他の人任せでまずなんのための手法なのか調べてみてはいかがというお話でした

わたしはクラスとかカプセル化とかポリモーフィズムとかはオブジェクト指向プログラミングを支えているに過ぎないと思います。
オブジェクト指向プログラム言語を使ってコーディングしていてもオブジェクト指向プログラミングには到達できない壁があります。

それが複数インスタンスです。
複数のインスタンスを作成できることと、複数のインスタンスが存在できることというのは意味が違います。
シンプルな表現が見付かりませんが、存在できるというのは独立性を確保できていて且つ機能するとかいうことで、設計の話なんですよね。

例えばJavaアプリケーションやAndroidアプリは起動毎にプロセスが作られるので、インスタンスの独立性が不完全でもアプリを複数動かせます。
なのでクラス変数をグローバル変数のように使うことができてしまいます。
ところが、同じJavaでもウェブページに埋め込むアプレットはひとつのプロセスで動作するので、ウェブページに複数埋め込むとすべてのアプレットがクラス変数を共有してしまいます。
複数のインスタンスが存在することを念頭に置いて作成されたプログラムでないと動作がおかしくなります。

Javaアプレットで試すのが簡単ですが、ゲームプログラムならひとつのプログラムで画面分割して左右別々に遊べるように作ってみてください。
オブジェクト指向プログラム言語を使えなくても作れますが、オブジェクト指向を理解しないと作れません。

オブジェクト指向プログラミングに必須の機能は「カプセル化」ですから、カプセル化を十分に理解すれば他の概念の理解も容易になります。
カプセル化だけならCでも十分実現できますので、カプセル化した場合、しない場合のそれぞれをCで試してみれば、その利点が見えてくるはずです。
ちなみに、Cを使ったカプセル化は上のようにします。
（structが抜けていたので修正）

jay さんが書きました:＞beatleさん
ありがとうございます～

しかし参考書で４０００円オーバーとは…(汗)
サブPCを新しく買おうと思ってお金を溜めている僕には厳しいものが…！

でも確か教務員室の本棚に参考書が一杯ありましたから、明日にでもそこを探してみますね…ｗ

まあ600ページを超える本ですから、妥当な値段だと思いますよ。
掲示板でいろいろな人に意見を聞くのはとても大事だと思いますが、やはりどうしても体系的に学びにくいと思います。
その点、書籍なら体系的に学びやすいです。
僕が紹介した本は演習問題も載っています。
本の構成は全体を通して「ある顧客の要望を聞いて、ソフトウェアシステムを実装し、改良していく」というものです。
一番最初に作り上げたソフトウェアの悪いところを修正したり、ソースコードをより柔軟にしたり、時々顧客から機能の追加要望が入ったり。
実際のソフトウェア開発現場を小さくしたようなストーリーですので、結構本格的なオブジェクト指向が身につくと思います。

この本で解説してあるのは「オブジェクト指向分析設計」であって、単なる「オブジェクト指向による実装」ではありません。
オブジェクト指向言語での実装方法だけでなく、オブジェクト指向を用いた要件定義のやり方だとか、クラス設計のやり方だとかが解説してあります。

掲示板などで得られる知識は実装面に偏ってしまいがちです。このメソッドはこのクラスに入れるべきだ、この変数はprivateにすべきだ、インターフェースを定義してそれを継承するようにすべきだ、など。
ソースコードを書くのが好きな人はどうしてもそういう話をしたくなるんだと思います。僕も含めて。

でも、実際のソフトウェアを作る上で、要件定義（ユースケース図を含む）やクラス設計など、ソースコードを書く以外に重要な部分が沢山あります。
そういうものを学びたいなら、掲示板よりは書籍がおすすめです。

＞tkmakwins15さん
おお！　分かりやすい例え！　こういうのを求めていました！

「独立性」と「カテゴライズ」についてはすんなり頭に浸透しましたが
「実装とアクセスの分離」については少しクエスチョンマークが…

空を飛ぶという共通の目的を持っていても、"飛び方"が違うのだから
それぞれを構成するパーツも違ってくる、だから定義も別々にするべき、ということでしょうか？

読解力に乏しくて申し訳ないです…。


＞新月獅子さん

「わかりやすい結果としてどんな恩恵があるか」

なるほど、こういうアプローチの仕方もありますね！

考えてみれば僕は殆ど「やらなければならないから」オブジェクト指向の勉強をやろうとしていただけであって
結局オブジェクト指向はなんの為に編み出された考え方なのか、考えたことも無かったですからね。

これはちょっと調べてみますね！　ありがとうございました～


＞ISLeさん
なんだか非常に難しいお話が…
これはISLeさんが最初におっしゃっていた「オブジェクト指向の定義」に繋がるのでしょうかね

ここで言うインスタンスとは
僕が考えていたクラスのメンバ変数が持っている値より、もっと大きな単位で考えるべきでしょうか？

「独立性を確保できていて且つ機能する」
独立性というのは
キャラクターはキャラクタークラス
エフェクトはエフェクトクラス
と言ったように、それぞれのクラスで役割を完全に分担させる、余計なモノは実装しない
と理解していたのですが、もっと大きな規模で考えるべきなのでしょうか？

オブジェクト指向の定義、目的など
僕はまずはやり方より理屈から理解していくべきなのかもしれませんね…


＞たかぎさん
やはりまずはカプセル化を徹底することから、ですか
(やはりと言ってもこのスレ立てるまではそれ以外にオブジェクト指向について知らなかったのですが)

助言の通りに、まずはカプセル化を徹底して開発を行ってみますね
言語は…C++ですけど…(笑)


＞beatleさん
そんなものですかね～
あ～、でも僕の手元にある参考書で一番高い奴は3800円しますね(笑) 400ページ弱ですけれど

僕は最初に高校の授業でＣ言語の基礎の基礎を習った後は、ずっと今の学校に入るまでの１年間
独学で勉強をしていましたからね、あんまり参考書で勉強した事がなかったりします。
まぁ、ネットでは限界を感じて参考書を求めた事もありますけれどね(苦笑)

要件定義やユースケース図は今まさに授業で教わっているのでいいですが、クラスを設計するときに気をつけた方がいいこと等
学んだ事は無いですからね、そういうのを学んでみるのもいいかもしれませんね
というか勉強したいですし…(笑)



そう言えば先ほどふと思ったのですが
オブジェクト指向＝クラスを使う、と言うのが一般的なようですが、どうしてなのでしょう？

ことＣ＋＋ならばクラスでも構造体でもデフォルトのアクセス指定子が違うだけで
後は全く同じな筈ですが、どうして構造体ではなくクラスを使うのでしょうか？

やはりＣ言語など、他の言語では２つは違ってくるから、でしょうか？

beatle さんが書きました:掲示板などで得られる知識は実装面に偏ってしまいがちです。このメソッドはこのクラスに入れるべきだ、この変数はprivateにすべきだ、インターフェースを定義してそれを継承するようにすべきだ、など。

少なくとも今回の質問にかぎっていえば、「オブジェクト指向プログラミング」についてなので、それでよいのではないでしょうか？

jay さんが書きました:ことＣ＋＋ならばクラスでも構造体でもデフォルトのアクセス指定子が違うだけで
後は全く同じな筈ですが、どうして構造体ではなくクラスを使うのでしょうか？

C++に関していえば、構造体も共用体もクラスの一種です。
共用体はともかく、用途に応じてclassとstructのキーワードを使い分けるのは悪いことではないので、そういうコーディングルールがよく見られるだけかと思います。

jay さんが書きました:そう言えば先ほどふと思ったのですが
オブジェクト指向＝クラスを使う、と言うのが一般的なようですが、どうしてなのでしょう？

ことＣ＋＋ならばクラスでも構造体でもデフォルトのアクセス指定子が違うだけで
後は全く同じな筈ですが、どうして構造体ではなくクラスを使うのでしょうか？

やはりＣ言語など、他の言語では２つは違ってくるから、でしょうか？

ちなみにJavaScriptはクラスを使わないオブジェクト指向言語なのだそうです。

聞くところによると、「プロトタイプベースのオブジェクト指向」という分類で、プログラムの実行中に、空のオブジェクトを複製し、プロパティやメソッドを追加していって新しいオブジェクトを作るとか作らないとか。

う～む、これはWeb用の言語だからこそ成し得ているんだろうなぁと思います。

正直よくわかりません（笑）

MoNoQLoREATOR さんが書きました:

jay さんが書きました:そう言えば先ほどふと思ったのですが
オブジェクト指向＝クラスを使う、と言うのが一般的なようですが、どうしてなのでしょう？

ことＣ＋＋ならばクラスでも構造体でもデフォルトのアクセス指定子が違うだけで
後は全く同じな筈ですが、どうして構造体ではなくクラスを使うのでしょうか？

やはりＣ言語など、他の言語では２つは違ってくるから、でしょうか？

ちなみにJavaScriptはクラスを使わないオブジェクト指向言語なのだそうです。

聞くところによると、「プロトタイプベースのオブジェクト指向」という分類で、プログラムの実行中に、空のオブジェクトを複製し、プロパティやメソッドを追加していって新しいオブジェクトを作るとか作らないとか。

う～む、これはWeb用の言語だからこそ成し得ているんだろうなぁと思います。

正直よくわかりません（笑）

javascriptは動的型付け言語でObjectから派生させて関数など追加してオブジェクトを定義していく言語です。
「プロトタイプベース - Wikipedia」
http://ja.wikipedia.org/wiki/%E3%83%97% ... C%E3%82%B9
ゲームスクリプトで有名なLuaもプロトタイプベースのオブジェクト指向言語ですね。
まだ、私はjavascriptのプロトタイプベースのオブジェクト指向は使いあぐねている状況です。

たかぎ さんが書きました:

beatle さんが書きました:掲示板などで得られる知識は実装面に偏ってしまいがちです。このメソッドはこのクラスに入れるべきだ、この変数はprivateにすべきだ、インターフェースを定義してそれを継承するようにすべきだ、など。

少なくとも今回の質問にかぎっていえば、「オブジェクト指向プログラミング」についてなので、それでよいのではないでしょうか？

わたしは、beatleさんが指摘している内容は「オブジェクト指向プログラム言語を使ったプログラミング」であって「オブジェクト指向プログラミング」とは違うものだと考えます。

jay さんが書きました:オブジェクト指向の定義、目的など
僕はまずはやり方より理屈から理解していくべきなのかもしれませんね…

実際に作らないと理解できないですよ。

巷にあるオブジェクト指向プログラム言語の解説のほとんどはオブジェクト指向の理解が不完全なままでも読めてしまうのです。
プロセスという大きなインスタンスに保護されてたまたまうまく動いているのに理解できたと勘違いしてしまうほうが怖いと思います。

確かにキャラクターとかエフェクトとかをクラスで実装するのと考え方は同じなのですけど
ひとつのエントリポイントからスタートして同じアプリが同時に複数動くように作る、というのが最終確認になると思うのです。
この最後の一山を越えられないひとはけっこういるのですよ。
最後の一山だからと言って取り組むのに時間が掛かるわけでもないですし。
キャラクターとかエフェクトとかをクラスで実装するのと考え方は同じなのですから。
油断しないでアプリレベルでもカプセル化(ここでは隠蔽化の意味はなし)をしっかりできれば良いだけなんですよ。

極端な話ですが標準で用意されているものでもグローバルに呼び出せる関数を使うのは油断に繋がる気がします。
グローバルnewも例外でなく。

思ったより返信が遅くなってしまった…
答えてくださった皆様、申し訳ないです

＞たかぎさん

C++に関していえば、構造体も共用体もクラスの一種です。
共用体はともかく、用途に応じてclassとstructのキーワードを使い分けるのは悪いことではないので、そういうコーディングルールがよく見られるだけかと思います。

ふむふむ、なるほど～
コーディングルール次第と、じゃあ個人制作でも適当ではなく
明確な基準をもって使い分けた方がよさそうですね

度々ありがとうございます


＞ISLeさん
う～ん、やはりその定義…
というか最終到達地点でしょうか、それがイマイチ理解できないですね。
少なくとも今は、ですが。

まずは他のお方もおっしゃっているように、何かをオブジェクト指向で作ってみようと思います
またそこから分からない事を聞いたり、調べたりして
少しずつ理解していこうと思います



ひとまずは満足する答えを手に入れることができましたので、これにて「解決」とします
ご教授して下さった皆様、どうもありがとうございました