POINT 構造とそのインスタンスは、データに素早くアクセスするためだけのタスクで あれば、ソリューションには不要なエンティティです。マトリックス経由でアクセスするのがどれだけ簡単か見てみましょう。
int Points[2][10]; //Объявляем в глобальной области.//---------------------//цикл по точкам для вычесления расстояний между ними:
//---------------------
for(int i = 0; i < 9; i++)
{
int x_dist = Points[0][i + 1] - Points[0][i];
int y_dist = Points[1][i + 1] - Points[1][i];
}
//--------------------------
これは、少ないドット数でも明らかだと思いました。それが何千個もあって、さらに複雑な形状を構成していれば、そのメリットはさらに大きくなります。
データを書いて作業する「構文技法」を示しましたね。これらはテクニックであり、OOPの概念ではありません。単純な問題では、あらゆる構造やクラスから実体をくり出すよりも、配列で作業した方が便利なのだが、なぜ解答にしぼられるのかがよくわからない。
メカニズム効率という考え方があります。
単純作業におけるOOPは、効率と可読性を低下させる。釘を打つにはハンマーが必要で、パンチカウンターやフォースメーターが付いたディスプレイがあれば問題ない。
データを書いて作業する「構文技法」を示しましたね。これらはテクニックであり、OOPの概念ではありません。単純な作業では、各構造体やクラスから実体を作るより配列で作業した方が便利なのに、なぜソリューションに詰め込むのかが不明です。
メカニズム効率という考え方があります。
単純作業でのOOPは効率と可読性を低下させる。釘を打つにはハンマーが必要で、パンチカウンターやフォースメーターのついたディスプレイがあれば問題ない。
私の例では、読みやすさは格段に向上し、効率も同じように良くなっています。
OOPコンセプト」というのがよくわからない。
私はプログラマーであり、哲学者ではありません。
私の例では、読みやすさは格段に向上し、効率も同じように良くなっています。
OOPのコンセプトがわからない。
私はプログラマーであり、哲学者ではありません。
OOPの構文技術を小さな問題に転用すると、ソリューションに不要なエンティティが発生します。
まずは最小限の構文と「客観性」で効率的な解を作る方法を学ぶ必要があります。色で動くアルゴリズムに注目 そこに余計なものはない。むき出しのメカニズム。つまり、ハンマーと釘です。そして、より複雑になってくると、「オブジェクト」「クラス」の概念に移行していく...。
それが、私なら。でも、邪魔はしませんよ。
OOPの構文技術を小さな問題に転用すると、ソリューションに不要なエンティティが発生します。
まずは最小限の構文と「客観性」で効率的な解を作る方法を学ぶ必要があります。色で動くアルゴリズムに注目そこに余計なものはない。むき出しのメカニズム。つまり、ハンマーと釘です。そして、より複雑になってくると、「オブジェクト」「クラス」の概念に移行していく...。
それが、私なら。でも、邪魔はしませんよ。
このスレッドでは、抽象的な推論ではなく、具体的な例を求めているのです。POINT 構造は、あなたに対して何をしたのですか？
あなたも邪魔をしないでください。このスレッドもあなたのためです。
何か変わるのでしょうか？
構文が変わる。
obj.val=1; または obj.val(1)。
その逆も然りです。
x=obj.val; または x=obj.val();
構文が変わる。
obj.val=1; または obj.val(1)。
その逆も然りです。
x=obj.val; または x=obj.val();
失礼にあたらない方法を知っている人とは、コミュニケーションをとっています。
そして、あなたは地獄に落ちる。
失礼にあたらない方法を知っている人たちとコミュニケーションをとっています。
そして、あなたは、出て行ってください。
言い過ぎではありませんか？
ああ...メンバーは本当に自分の戯言に付き合わされるのが嫌なんだな。
は基本的にありません。
そして、ここがポイントなのですが、彼らはお互いを舐め合うのも好きなんです。
--
さて、もし私がゲッターとセッターの話をしたらと想像してみると...。
--
コルドゥン・ズロイさん、トピックを「小学生からのLLC」に改名してください。
このスレッドでは、抽象的な推論ではなく、具体的な例を求めているのです。POINT 構造について、どのような問題があるのでしょうか？
私にも迷惑をかけているのでは？このスレッドもあなたのためです。
さて、コードに移りましょう。
どのような課題が設定されたのでしょうか。- 点の座標を格納する。何のために？- クイックアクセスに
POINT 構造とそのインスタンスは、データに素早くアクセスするためだけのタスクで あれば、ソリューションには不要なエンティティです。マトリックス経由でアクセスするのがどれだけ簡単か見てみましょう。
あなたは哲学者ではないとおっしゃいますが、「構造」は哲学的な概念であり、解答におけるその存在は正当化されなければ なりません。
さて、コードに移りましょう。
目的は何だったのでしょうか？- 点の座標を便利に保存するため。何のために？- クイックアクセスに
POINT構造とそのインスタンスは、データに素早くアクセスするためだけのタスクで あれば、ソリューションには不要なエンティティです。 マトリックス経由でアクセスするのがどれだけ簡単か見てみましょう。
あなたは哲学者ではないとおっしゃいますが、「構造」は哲学的な概念であり、解答におけるその存在は正当化されなければ なりません。
どの要素がxで、どの要素がyなのかを知る必要があり、不便です。しかし、構造体を使うと、すべてが明確になり、ミスをなくし、コード量も減らすことができます。
もし、私がゲッターとセッターについてくだらないことを言ったとしたら、どうでしょう。
何がちんぷんかんぷんなんだ？ゲッターの定義を開いて 読んでください。
直接的に制限されるデータを取得 するための特別な方法