  |
はてなキーワード: オブジェクトとは
の２段階で説明できる。
問題は後半の「使い方」で、どうしてそんな使い方をするのか？という部分。
実装の前の、設計の話を持ち出すと、情報量が増え過ぎて、何が基本か見えづらくなる＝初心者だと頭がパンクしてしまう？
あと、OOPを教える材料として、Javaじゃなくても良いと思う。
https://anond.hatelabo.jp/20181015215004
「今の状況は辛いし、職場でどうすればいいのか分からなくなっている。気持ちを整理するため書いたけど、誰か、知恵を授けて下さい。」
と書いてる訳だが、俺が見るに、さほど参考になるようなトラックバックがついている様にも思われぬ。元増田に届くかは分からんのだが、初心者状態からC++で実験データ解析用ソフトを二か月で仕上げる必要があった俺が取った手段を整理しておきたい。
ゼロの状態から仕事に叩き込まれて、尚且つ、初歩の初歩からのチュートリアルもないという状況の辛さは理解できる。俺自身が、何も知らんのに卒業まで2か月で実験データ解析ソフトをVC++で作れという状態にぶち込まれた事がある。その際に、取った手段について述べる。
与えられた仕事について、全くの初心者なので導入まではチュートリアルがあればいいが、ないならば、参考になるプログラムはないか？と尋ねるのがいいと思う。プロジェクトの中の、どのコードのどの関数が参考になるのか？と尋ねればいい。それを理解するところから始めるのがいい。俺のケースであれば、Web上に落ちてる似たようなことをしてるサンプルコードになる。英語系のコードを公開してるサイト(今ならgithubなど)で探していた。Draw Bitmap on Panel VC++ とかで検索して、サンプルを入手していた。
例えば、VC++でパネル上に、ビットマップ画像を描画していくようなプログラムには雛形というか良くできたサンプルが存在する。元増田の場合は、既に動いているプログラムで、尚且つ自分が触る必要のある関数がプロジェクトの中に存在するはず。（関数と言う言葉が分からない場合は、調べて欲しいが、既存のプログラムの意味で良い）それを実際に動かしながら、理解を深める事を行う。
これについて、一行づつ何をしているのかを調べて、コメント行を追加して必要なら本やネットを見ながら、各行の動作を紐解いていく事をする。その際に、その行を少しだけ書き換えてみて（元のプログラムはコメント行としてコピペしておく。gitなどが使えるならば必要ないが。）、動作の違いを予想し理解を深めるのも良い。
パネル上にビットマップを描画したい場合、最初は構造体の事なんか全く分からないけど、画像の幅と高さをとってくるとか、描画位置を決めるにはどうすればいいのか？という実際に自分が何かをやるにあたって浮かぶ疑問があると思う。それを、理解する為に1行づつ弄っていく。
万が一、ラムダ式や、C#で言う所のLINQの様なもの（SelectManyで集めてたものをToListでリストにして、ForEachでループ処理する様な）に出くわしたら、最初はおまじないだと思って逃げるが勝ちだろうと思う。無理しちゃいけない。
自分の場合で言うと、最初はwinmain の冒頭からWindowsのメッセージループは何をしているものなのか？全く理解できずに、おまじないだと考えて、各イベントの処理内容を書いてソフトを完成に近づけることにだけ意識を払った。分からなくても動いている、触る必要はないというものについては無視する勇気は必要だと思う。BitMapの構造体について完全に把握したのは、結構後になってからだったりするし、初めから完璧な理解を目指さず曖昧に行こう。
自分で調べてみて、理解が及ばない点については、遠慮なく尋ねるべき。質問したい内容が整理できた段階で、即尋ねていいと思う。逆に言うと、何が知りたいのか整理できてなければ質問自体が無駄になるので、もうちょっと頑張れって感じになる。
例えば、ボタンを押した後の動作に定義した動作を追加をしたいと思いました。イベントのリストに関数を追加すれば、既にあるイベントの後に実行される事を予想していましたが、イベントの追加が間違っているのか？追加した関数が実行されません。ちょっと見てもらえませんか？
ここまで言えば、ヘルプが入るはず。ここまで整理するのは最初は大変かもしれないけど、分からない事を自分で理解して整理するのは、初心者にとって最もいい訓練になるので、あきらめずやってほしい。
１，２の繰り返しだと思う。
プログラムのベーシックな構造と、基本的な構文を理解できれば関数単体での動作が理解できるし、あるいは全くわからないところからでも自分で整理は出来たら、次は関数ごとの組み合わせによる動作を追う事が大事。やるべきことは、関数単体の動きを追う事と違いはないが、ここで意識してほしいのは、関数のデータの入出力の動きをトレースする癖をつけることだと思う。関数という単位は、入力を貰って結果を返すのだけど、その入出力の連続した動きは、良く設計されたAPI関数を使ったものより、ユーザー定義の関数では複雑になりがちなので、メモを取りつつ整理すると言い。
例えば、VC++でのツールづくりの例で言えば、各メッセージイベントに対して、例えばマウスを押したメッセージの後に、どんな関数が呼ばれて、どんな引数が入力として与えられて、自分は何をして、何を出力すべきか、という事を理解する必要がある。
Javaであれば、クラスの構造を理解する必要があるけど、上記のステップを踏んで自習の勘を掴めば、それほど難しい事ではないと思う。クラスを理解するようになると、コード全体の設計思想を理解できるようになるので、ここまでくれば初心者は脱したと思ってよいのではないかと思う。後は勝手に成長していくはず。
何人か新人の面倒を見てきているけど、元増田の会社は酷いと思う。
酷いながらも粘ろうとしている元増田は立派ではあると思うので挫けないでほしくはある。実際に何かを作りながらプログラムを覚えるのは、ある意味では効果的な勉強の仕方なんだけど、どう勉強していいのか？を教えてくれないのであれば酷い話。
自分で試したプログラムを理解していく為の手法を改善しながら、少しづつ勉強の仕方を確立していけばいいんだけど、その際に他の社員を使ってアドバイスは求めた方がいい。意外に長くなって済まん。頑張れよ。ネット上のどこかで応援している。
書き方は釣りっぽいけど、今30代前半以下のPCユーザーにはフロッピーディスクを実際に見たことがない人達が多いはずで、あのアイコンが「保存のメタファー」として直感的でなくなってるのは確かだと思います。
ただ、検索を虫眼鏡アイコンで、電話を黒電話アイコンで、電気を稲妻アイコンで表象するのと同じように、ひとたびユーザーの側に「これはこういうもの」という強力な連想が確立・共有されてしまえば、ユーザーが必ずしもその表象されてる実物を知らなくても大きな問題は起きないようにも思います。
それより何より、自分が昔から気になってるのは、この保存アイコンに代表される「機能アイコン」の特殊性についてです。多くの人々が感じているように、機能アイコンには意味がわかりにくいものが多い。たとえばWordやExcelだとこんな感じ：
https://gyazo.com/c0d77ae6fd252d756b40f95da10c9cc7
https://gyazo.com/f2807738b32978daa8edb8ab9f9b8441
「これアイコンにする意味あんのかな、単体で見ても全く意味わからんな」というものがたくさんあるよね。
何で機能アイコンってわかりにくいか、考えたことありますか？ デスクトップメタファーでは、コンピューターの中にあるオブジェクト（ファイルやディレクトリ）を実世界に存在する書類やフォルダに見立てて、それをアイコンとして表現することで直感的に理解・操作できるようにしているわけですが、機能アイコンはそうじゃないんですよね。機能アイコンが表現したいのは、オブジェクトではなく、アクション（行動・働きかけ・変化）なんです。
①その機能を表象するモノをそのまま使う（フロッピーや虫眼鏡や錠前など）
②その機能を表象するモノに、動作や変化を示唆するプラスやマイナスやバツや矢印を重ねる（削除行に×マークをつけたスプレッドシートなど）
③その機能を実行したときの視覚的結果を表す（中央寄せや下罫線など）
このうち①は、実世界での活動になぞらえられるような基礎的機能にしか使えない。②は、もともと小さい機能アイコンにさらに小さい意味素を付け加えることになるので、とても見にくいうえに、似たような機能アイコンを区別しにくい。③は、ごく簡単な結果であればよいけれど、複雑だったり抽象的だったりする結果を表現することはほとんどできなくなる（たとえば、上のExcel機能アイコンの「アイテムの後ろの空行を削除する」や「XPS形式の添付ファイルとして電子メールで送信」など）。①②③のいずれも、アクションをオブジェクトで表現することに本質的に無理があるからわかりにくいわけです。
じゃあ、なんでそんな「本質的に無理がある」ものがここまで普及して広く使われているのか。この問いを突き詰めると、機能アイコンはもはや直感的理解を助けるためのメタファーではないからだ、という答えにたどり着きます。
例えば、わかりにくい（アイコンとしての具象性が劣っている）からといって機能アイコンを取り去るとどうなるか考えてみると、「いや、やっぱちょっと困るな」となる人は多いのではないでしょうか。もしリボンUIに文字だけで機能がずらずら並んだらものすごく見にくいし、目的の機能を探しにくい。つまり機能アイコンの利点は、今では①UIの省スペース性（たくさんの機能を有限のUI領域に整然と詰め込める）と、②瞭然性（学習さえ済んでいれば、文字列の読解処理を経ずに瞬時に判別できる）の2つにあるのです。
機能アイコンはデスクトップメタファーとは違って、ユーザーの学習コストは下げてくれない（直感的理解は全く支援しない）けど、一度学習してしまえば、日々その機能を利用するときの操作コストは格段に下げてくれます（元増田も、保存アイコンがないよりは、フロッピーアイコンのままのほうがずっと楽なはずです）。これが確実にユーザーエクスペリエンスを向上してくれているわけですね。
個人的には、だから機能アイコンのことは機能シンボルって呼ぶ方が実態に則してるんじゃないかなと思ってます。アイコンは偶像だけど、シンボルは約束事、協約ですからね。
AIの仕組み自体は人間の能力を遥かに超えたものかもしれないし、それによって社会の利便性を更に向上させるものであるかもしれないけれど、そのAIを設定するのは人間だということ。
その人間が男性優位社会で育ってくれば当然男性優位AIが爆誕するんだし、
リンクしたアマゾンの採用AIの件を含めて、機械学習の仕組みを理解してるとは思えない。AIに対する現状の理解として、この表現はありえない。
id:fujii_yuji 機械学習の仕組みをご存知ないようですね。Amazonのは過去データからそうなったのであって、設計者の思想が反映されたのではないでしょ。 > "当然男性優位AIが爆誕する(略)AIは一握りのエリートに偏ったエリート優位AI"
id:fujii_yuji さんは、概要を理解しておられる様に思える。ブコメを見る限りで言えば、はてなーの理解度は1割程度といった感じがするけど、本当はもうちょっといるかも。
機械は未だに設計に従って自発的に成長し新たな発明を行う様な、いわゆる、ひらめきは獲得していない。今のAIと呼ばれているものは、学習したデータを参考にして、入力されたデータに対して最適な分類を行うことが出来るという程度の物。
モーリス・コンティ: 直感を持った人工知能が生み出すすごい発明 | TED Talk
例えば、この動画を見て欲しい。オブジェクトを設計するコンピュータが行うのは、与えられたアルゴリズムに従って答えを出す事だけだ。どんな形にしたいのかという目的、どんな材料を使うのかという制約、それを与えられると、高い強度とより少ない重量で目的を達成しろという最適化問題を解く。結果として、その答えが人間が持つ常識を裏切る答えを出した事に対して「直感を持っている」と言っているにすぎない。アルゴリズムを作成した研究者には、常識的な設計を裏切る答えも、理解できるものであり納得のいく答えでしかなかったはずだ。
将棋の人工知能が行う計算とは何か？既存の棋譜を大量に予め学習し、現在進行中の将棋の盤面上で起こり得る可能性のある駒の配置パターンを１手1手進めながら、棋譜と照らし合わせ、一手ごとに勝ちやすさがどの程度高まっていくか？を計算する。研究者は、盤面に表れる駒の並びを、どの様に評価するのか？駒を動かすごとに増えていく全てのパターンから、どこまでを用いて、何を捨てるか、評価と選択を行うアルゴリズムを機械に与える。その結果として現れた奇想天外な一手も、研究者にとっては蓋然性の高い答えでしかない。（あくまで一般的な人工知能の話だが）
完全に想像でしかないが、アマゾンの採用AIは、10年分の採用者の履歴書の中から、学歴や経歴、職務内容、スキルなどの性別に依存しない情報と採用後の実績を学んだのではないか。研究者は馬鹿ではないから、初めから性別情報など使っているとは思えない。これまで採用した人物に男性が多かったことは間違いなく影響があったという事は言えるが、可能な限り男女ごとのサンプルサイズの差に引っ張られる事なく、性別には中立な結果を出すように、用いるべき学習データとアルゴリズムを設計していると予想する。それでも、性別を隠されたある個人の履歴書から採否を判定した時に男性優位の答えを出したのは、活躍する社員に男性が優位になる傾向があったということ。その現実がポリコレとの間で齟齬をきたした場合に、計算結果としては蓋然性の高い納得できるものでありながらも、不誠実な結果と言われてしまった研究者の悔しさはいかばかりだっただろうか？
女性が優位になる様にアルゴリズムを作り直すときに、自分は科学者として真実に背を向けた事を理解したはずだ。にもかかわらず、どれほど女性優位のバイアスをかけてもAIが正しい答えを求める以上は男性優位の結果は覆らない、とマネージャーが判断して、非難を避けるために開発を停止した時の、その悔しさは想像するに余りある。
この件で、改めて、ジェンダー論は滅びろと心から思った。科学者には、政治的正しさではなく、真実を追求させてくれ。科学とは時に残酷なほど正しいものだ。
steel_eel 日本語のニュースで書いてたか知らんが、英語の方でみたが『××女子大学』『女子××部部長』とかを低評価してたみたいで、わりとダイレクトに性別を他の手がかり(というほどでもないか？)から判断して下げてた模様。
情報ありがとうございます。徹夜明けでして、ソース未確認で書いてますので、適当な事をいいます。すみません。
もしも学習データに、女子○○部長、というデータが入っていた場合にマイナスにする様なアルゴリズムを入れていたとは考えにくいです。というのは、そうであれば性別そのものを負のファクターにする方が早いです。ですので、他の素因でマイナスにせざるを得ない（不採用だった、あるいは解雇したなど）人物と女子○○部長の情報が結びついてしまったのでしょう。つまり、現実の採用では女性である事をマイナスに評価せざるを得ない様な学習データになっている、それを修正しようと思うと、女性のデータそのものを学習データから除外するしかないですが、そんな事をすれば、アマゾンは女性の居ない世界を仮定しなければ女性は採用できないという、矛盾にぶつかってしまいますね。
これではなく、入力情報に女子という単語が入っている場合に直接マイナスした場合。前述の理由で性別そのものをマイナスにしたのと同等でしかなくなります。これなら修正は容易ですので、そうではないでしょう。おやすみなさい。
手続き型と違うみたいなことを書いてるのをみるけど、
データをオブジェクトにまとめて、それ専用の関数をクラスに定義できるのは便利だけど、構造体と関数でもできるわけだし
オブジェクトに対して、あれする、これする、それする、と書けば内部はブラックボックスだけでメソッドに応じたことが起こる
使う側が for 分であーしてこーしてみたいな処理を順に書いてるだけだから読むときに結局何がしたいのかをじっくり読まないとわからない
最適化のためか一つの処理であれもこれもやってるようだとすごく解読が辛い
関数型の考え方だとけっこう違うし制限が多いからか読み方さえわかればあまり分かりづらいコードは少ない
何するかがそのまま書かれている感じ
とは言っても、前に関数型は考え方と書くのがそもそも難しいからある程度できる人しか使わないから簡単に使える手続き型みたいに能力ない人が書くケースが少ないから読みやすいコードが多いと聞いたことはある
そもそもオブジェクト指向そのものが40年以上前の技術だろが。
生物が単純な細胞の組み合わせと相互作用で複雑なシステムを構成するモデルに習って、単純なオブジェクトとメッセージパッシングの組み合わせでプログラムを表現する事で、プログラムを完結する小さなオブジェクトという単位に分割し、管理困難な複雑さに対処する事がオブジェクト指向の本質だろ。
構造化との違いはデータ構造も管理の単位に含めた事で、これによって複雑な状態管理をオブジェクトの中に閉じ込め、インターフェースだけ意識すれば良くなった点。
本質を理解していればオブジェクト指向でプログラム作るのにオブジェクト指向言語とか必要ない。ジェネリクスとかそもそもオブジェクト指向と関係ないし、後付けのいろんな用語に騙されて本質を見失うなよ。
日本語とオブジェクト指向が相性良いと言われてたのは日本語の語順がオブジェクト→メソッドというプログラム上での表現に似ているから、日本語話者にはすんなり理解しやすいよねって点。
もともとコンピュータか人間かなんてチェックボックスひとつクリックするだけで区別できるんじゃなかったんかい
それがチェックボックスクリックしたらいつもの画像選択させやがって
しかもそれがただ選択するだけならまだしも指定したオブジェクトが消えるまで選択し続けるとかマジでかったるすぎ
ほんで3x3から選択じゃなくてタイル選択してくださいのフリー形式な
判定基準ガバガバだし３回も４回も続けて選択しないといけないのめんどくさすぎ欠陥だろ
タイル選択だったらすかさず再読込して3x3から選択するやつに変えてるわ
そんでもって最近良く見るようになったのが画素荒くしてあるやつね
サマータイム関連でマウント取りたいプログラマーがブコメやブログ書いてるけど
もしかしてこんなびっくり低レベルプログラマーが世の中のいろんなプログラミングしてるの？
サマータイムよりそっちの方が怖い。
プログラムで時刻を扱う場合はほぼほぼ１００％ライブラリの機能を使う。
日付なり時刻を表すオブジェクトを作る。
そうしないと単純な引き算とか足し算が面倒だろ？
今から10日後ってどうやって計算する？一ヶ月は必ず30日じゃないんだぞ？
だからライブラリに任せる。そこそこのプログラマーなら面倒なことをいちいち実装しない。
で、そういう実装をすると内部で保存されてる時間情報と表示する情報は別物になる。
たいていは内部ではUTCで保存されていて、そいつを表示の時にJSTにする。
OSなりのロケール情報から何で表示するべきなのかを取って来てそれに合わせて表示させる。
サマータイム対応をする場合はこのロケール情報を変えるのであって、内部の時計は変更しない。
だからほとんど全ての時間的演算は影響を受けないし、コードを変える必要もない。
だから正確に言うとサマータイムが導入されても「時計は変更しない」
表示を変えるだけだ。内部時計と表示の関係をわかってない人が多すぎる。
はてなの（おそらくエアプ）プログラマーがその辺をわからずに記事にしてるのがほんとキモい。
で、そんじゃ影響はないか、っていうとそうじゃない。
さっきの10日後、みたいな演算は影響を受ける。２時間ずれる。
あと、簡単なところだとcronなんかのスケジューラは影響を受ける。
夜中の1時に実行するっていうcronの設定はロケールに応じて意味が変わるので、切り替えの時に1日に２回実行されたりするかもしれない。
ただ、利用者側に見えないところのスケジュール実行なら、ぶっちゃけサマータイム対応させる必要はないと思ってる。
サマータイムなんて所詮は人間が見たときの時間であって、内部の時計の話ではないからだ。
エクセルがタイムゾーンに対応していないとかの話もあるが、スタンドアローンで動いてるなら全く問題ない。
影響は皆無ではないしかなり大きいと思うが、OSの更新とかそんな大それた話ではないはずだ。（もちろん、将来的に変更する必要はある）
じゃぁサマータイム賛成なのか？って言われるとそれは別だ。
おそらくスケジューラの影響だけでも相当大変だし、それに関連したシステムの再検証とかどう考えても時間が間に合わない。
内部のコードがどうなってるかわからないから時間に関係してる・していないに関わらずシステムは全て再検証だろう。
どう考えても無理なのは無理だが、根本的に無理かと言われたらそうでもないはずなんだ。
もしかしてハードコードでJSTって書いてたり、独自の時間管理ライブラリを使ったりしてる人って結構いるのか？
String time = "2018-08-16 13:41:00"
とかやってんの？
スタンドアローンならそれでもいい（勝手に電源落として時計あわせりゃいい）が、そうじゃないシステムでそんなアホなことしてる人って多いの？
http://mizchi.hatenablog.com/entry/2018/07/31/124354
念の為言っておきますがOOPの呪いについては特に異論はありません。
古いJavaのような、クラスにしかメソッドが所属できないモジュールシステムばかりの時代じゃありません。 クラスは基本的に不要だと思います
Javaは今でも「クラスにしかメソッドが所属できないモジュールシステム」でしょ。クラスに属していないように見えるのは糖衣構文に過ぎない。
https://twitter.com/mizchi/status/1024103868613812225]
オブジェクト指向の呪い、ほとんどの言語のモジュールシステムでは関数参照がそのままexportできるのに、すべての関数を static メソッドまたはクラスメソッドとして表現する人が未だに多く、見るたびに指摘してる…
関数参照ってなんですか?「exportする」ってそんなに一般的ではない気がする。
もしfunctionオブジェクトをimportするのを指しているのならば、所詮オブジェクトなので状態が含まれない保証はない。
https://twitter.com/mizchi/status/1024104303907065856]
そりゃJSみたいに柔軟なインポートができる言語ばかりじゃないし…
https://twitter.com/mizchi/status/1024151165703938048]
JSの似非OOP慣習と向き合うのに class の導入は必要だったと思うけど、それはそれとして class 使わないのは別
これはそう。結果論的にはclassそもそも導入されるべきではなかった気もするけど。
https://twitter.com/mizchi/status/1024155163399876609]
Dijkstraのijkが好き
めちゃくちゃわかる
湧いてきたら追加する
って書いておきながら、引数で持ってくるのかnewするのかは書かないって、片手落ちじゃん
ロジックは実装に任せるっていうなら、設計はDBまでかもしくは、外部インタフェース仕様ぐらいまでにして、内部で使うクラスもメソッドも実装側に任せろよ
C言語でプログラミングの基礎を学び、今はJavaベースのシステムを設計し、プログラマに実装をお願いする立場。
まず、完成した設計を渡すと高確率で質問とともに突っ返されるのだが、その時の質問が、ほぼいつも
「『AオブジェクトのBメソッドを〜』とありますが、そのAオブジェクトはどっから引っ張ってくるんですか？それともnewするんですか？」
なのが閉口する。
俺は業務の詳細を俯瞰し、処理のフローチャートに落とすのが仕事なんだけど、そんなトコまで書かないといけないのかよ？
なんでインスタンスだnewだのって話になるんだよこっちはJavaの専門家じゃねーんだよ。ぶっちゃけそんな低レベルな話は知らねーよ。
コード書くのが俺の仕事じゃねーのに、なんでコード書きがするべき仕事を押し付けられるんだ。
まあそんな事を言っても仕方ないので、「引数で持ってくる」と直して実装させるじゃん？
「その修正は仕様変更になるので許可取ってください。てか、ビルドエラーになるのでやめてくれ」
そして、それもこれも、全て設計のせいになるので納得が行かない。
