オブジェクト指向はクソじゃなかったよ Part3 ->画像>3枚

カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。

偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。

一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。

オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96

前前スレ
オブジェクト指向ってクソじゃね？
http://2chb.net/r/tech/1535085129/

前スレ
オブジェクト指向ってクソじゃねぇよ？ Part2
http://2chb.net/r/tech/1539872441/

アナルプレイしたいです

こっちのスレもあんのかよｗ
まともなシステムを開発した経験がある奴いる？

まともなシステム開発 = オブジェクト指向開発ということでいいか？

>>4
限定はしないが

ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのだろうか？

チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンボ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンボ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！

age

スレタイと本文がすでに喧嘩してる

オブジェクトのクラスは概念であり、インスタンスは現物である。

チンポはチンポでも人それぞれいろいろなチンポがある、それはクラスとしてのチンポ。
しかしながら自分のチンポは一つしかない、それがインスタンスなのである。

一般論としてのチンポ論と、自分のチンポが現在どうしているかは、明確に区別して考える！

staticなクラスメソッド・クラス変数は実行時にすでにメモリに呼び出されています。
これに対し非staticな変数やメソッドは、newでインスタンス化した時にメモリに呼び出されます。
staticなクラス変数は、処理の結果によって値が変わるのではなく、クラス毎で統一して持つ値になります。

非 static なメンバはインスタンスと関連して記憶されています。なので、クラスから非 static
なメンバへアクセスしようとすると、どのインスタンスの メンバ にアクセスしたいのかコンパイラは判別できません。
そのためクラスから非 static なメンバにアクセスすると、コンパイルエラーとなります。
同様にクラスに関連付けられた static なメソッドから 非 static なメンバにアクセスすると コンパイルエラーになります。

>そのためクラスから非 static なメンバにアクセスすると、コンパイルエラーとなります。

チンポは他人に見せるものではない！

チンポについて一般論として語るのは良いが、自分のチンポは隠蔽(カプセル化)されるものである！

本体とチンポは、別々のインスタンスとして考えなければならない！

本体とチンポは、マルチスレッドである！

本体とちんぽは着脱可能である!

スレッドはメインルーチンとは独立して動くが、これはチンポが本体とは独立して勃起するのと同じ。

そこでまずこのクラスをスレッドとして動かすことが出来るようにしなければいけません。
スレッドとして動かす為にはThreadクラスのサブクラスとするか、Runnableインターフェースを
実装する必要がありますが、このクラスは既にAppletクラスのサブクラスであるためさらに
Threadクラスのサブクラスには出来ません。よってRunnableインターフェースを実装することになります。

どのタイミングで作成するかは場合によりますが、通常はアプレットが最初に開始された時
にスレッドを作成します。その為initメソッド内でスレッドを作成しましょう。
またThreadクラスのオブジェクトを作成する時に指定する引数にはスレッドとして動かすクラス
を指定するのでしたから、今回の場合は自分自身である「this」を指定します。

アプレットは、アプリケーションのように main メソッドを持っていません。しかし、
代わりにアプレットを実行、コントロールするためのメソッドを持っています。
まず、サンプルプログラムと実行方法を説明します。

import java.applet.Applet;
import java.awt.Graphics;
import java.awt.Color;
public class HelloApplet extends Applet {
String text;

public void init() {
text = "Hello, world!";
}
public void start() {
System.out.println("starting...");
}
public void stop() {
System.out.println("stopping...");
}
public void destroy() {
System.out.println("destroying...");
}
public void paint(Graphics g) {
System.out.println("painting...");
g.setColor(Color.red);
g.drawRect(0, 0,
getSize().width - 1,
getSize().height - 1);
g.setColor(Color.blue);
g.drawString(text, 15, 25);
}
}

継承するクラスをAppletからFrameに変更し，mainメソッドを持つクラスを作ってその中から
Frameのinitメソッドを呼び出す，基本的にそれだけです。
https://qiita.com/shima_masa/items/b4a0edb0caad9e36121e

もちろん逆に、アプレットで作ったソフトを、配布用のアプリケーションにしたい場合も
Appletに代わるFrameを作成し、main()メソッドからインスタンスを生成して実行すればよいのです

/www.cis.shimane-u.ac.jp/~rokui/lecture/QA/lect4.html

ゲームとアニメの違いは、プレイヤーが操作できるか否かだ。

コペルニクス以前に「宇宙」「天体」は存在しない！

アプレットの中でアニメーション(リアルタイムゲームを含む)をするのは結構
面倒である．まず，アプレットにはmainがない(書いても呼ばれない)ので，
明 示的にスレッドを作る必要がある．アプレットは Applet クラスのサブクラス で作らなくてはいけないので，Runnable インタフェースを継承することになる．

処理はマルチスレッド、描画は同一アプレットで！

まずごく簡単なサンプルプログラムを作ってみよう。

描画アプレットは最後でいい

チンポはそれ自体が独立した生き物であり日々活動しているが、外から見えるのは「皮」だけ。

チンポがシコシコするそのメカニズムは、億兆の数式でも書ききれない。

外から見たチンポは、最後の表面的な描画アプレットにすぎない！

描画はマルチスレッドしない、肉眼で見る光景は一つだから。

もう疲れたよパトラッシュ

アプリケーションとアプレットの共有
これまで、アプリケーションとアプレットを切り離して解説してきました
もちろん、それぞれの機能は別物です

ここで気になるのがアプレットとアプリケーションを組み合わせられないのかということです
つまり、コマンドラインからJDKの java コマンドで実行することができ
かつ、ブラウザでも見ることができるという代物です

オブジェクト指向が万能薬のように扱われて
必要もないのに言語に組み込まれていった暗黒時代はクソだと思いたい

90年代にクソが量産されてその保守で苦しんでるみなさん

public static void main(String [] args )
{
FrameApplet frame = new FrameApplet();

frame.init();
frame.setBounds( x, y, width, height );

frame.addWindowListener(
new WindowAdapter() {
public void windowClosing(WindowEvent e)
{ System.exit(0);}
}
);

frame.setVisible(true);
}

オブジェクト指向そのものはクソじゃなくてそれを使おうとするやつの頭がクソなだけでしょ

2015年6月29日月曜日
System.Drawing.Graphicsのマルチスレッド非対応問題
Graphics.DrawImageはマルチスレッド対応していない。
http://redditchan.blogspot.com/2015/06/systemdrawinggraphics.html

キーリスナーとグラフィックを分離

フォーカスは通常、マウスカーソルによるクリックでセットできる。また、Tabキーによっても変更できる。
フォーカスがセットされた、もしくは外されたといったイベントを受け取るためのイベントリスナーはFocusListenerインターフェイスの実装クラスとする必要がある。

一つのコントローラは同時に一つのイベントリスナーしか実行しないため、
それぞれのリスナーの処理が並列処理されることはありません。
https://www.intra-mart.jp/apidoc/iap/javadoc/platform-all-dev_apidocs/jp/co/intra_mart/common/aid/jdk/util/EventQueueController.html

並行 ： 複数の動作が論理的に順不同、もしくは同時に起こること
並列 ： 複数の動作が物理的に同時に起こること

論理的に順不同wバカなん？w

物を知らない人間は自分を賢いと思い込む
ウーマンラッシュアワーの村本しかり

村本は賢いで？
アイツを叩いとる奴等が自分を賢いと思い込まされた不幸なブタばかりやわ

百田でさえ最近は安倍を見放しとるw

>>47
文春だったか新潮だったかで連載をみかけたことがあります

オブジェクト指向を否定する理由がよく分からんけど
動的ディスパッチと継承まで全部含めないと認めない勢はもっと分からん

https://erologz.com/blog-entry-3246.html

privateはあっても良い。というか、外部から勝手に変数書き換えられる事を防ぐ方法のない言語はないとまずいだろう。それがバグの温床になる。

最近の言語だとクラス変数(プロバティ)はリードオンリーにできたりするのもあるのでそういうのは直接的にprivate変数を作る必要を減らせる。(例えばKotlin等)。
実際には内部的にprivate変数があってゲッターのメソッドを呼ぶようにコンパイルされるだけのことだがわざわざ自分でゲッターを作ったり呼び出したり書かなくて済んで見た目がスッキリする。

プロパティをリードオンリーって最近の言語っていうかC#でもできるじゃん？
Kotlinはそれのパクリでしょ？

いざというときのためのアクセス手段を排除しておく方が
結局は回りくどい事をたくさんしなくちゃいけなくなって
バグの温床になる

いざというときは来ない
ヤグニ原則やでー

関数ポインタを型安全に扱う方法くらいに思っときゃいいよ。

オブジェクト指向プログラムの新人教育には金正恩が解りやすいよね。

クラス→金正恩という概念
インスタンス→金正恩の実体でクラスからいくつでも生成可能
ガベージコレクション→要らなくなった実体の始末

>>57
全然わからんw

月火水木金正日まで読んだ

月火水木金正月

金正恩は設計図で、設計図から影武者と呼ばれる実体を数多く作り出している
これをテキストに書き出せばオブジェクト指向
最近現れた「顔違うじゃんこいつ誰だよ」って影武者は多態性を表している

安倍晋三 = new 金正恩();

文　＝　new 金日成();

>>53
C#は知らんが、まあパクリなんだろうな。
てかKotlinは沢山パクリがあるような気がするが、こちらとしてはそれで使いやすくなるならそれで良い。
むしろもっとパクれと思う。

こちらで同意を得られなかったからニュース速報スレで騒いでるｗ

オブジェクト指向は愚かな考え
http://2chb.net/r/news/1592474015/

age

ニュー速って人間いるのか？

ところで「チンポがシコシコする」という日本語表現は、文法的に正しいのか？

チンポ「を」シコシコするのではなくて、チンポ「が」シコシコする。この場合、「チンポ」は主語となる。

オブジェクト指向で言う「集約」は２種類あって、全体（俺）と部分（チンポ）が繋がっている場合と、
全体（俺）と部分（チンポ）が別々になっている場合とが考えられる。けれども「チンポ」はそれ自体
が独立した生き物であり、所有者の意思とは無関係に、勃起して「シコシコする」。
例えば寝てる時にエロい夢みて朝起きてみたらチンコが勃起して射精してたとか。

違うか？

「胸がドキドキする」は良いが、「チンポがシコシコする」はダメな理由を、５０字以内で述べろ！

自動詞と他動詞の違い

日本語に文法もクソもない

多重継承は曖昧だというが、自然言語処理はその曖昧さが大切になる。チンポは随意筋であり不随意筋である。

最終的に，クラス階層は最上位クラスを含めた
最大8 階層から構成され，「伝統的な日本の絵画」
に属する用語に対応する 55 クラスと解説文中か
ら抽出した139 クラスが配置された。ただし，そ
のうち 32 クラスが複数の上位クラスをもつとい
う多重継承が示された。例えば，「ngyc:絵巻物」
は「ngyc:伝統的な日本の絵画」と，「ngyc:表具の
形式」の下位クラスである「ngyc:巻子」の 2 つの
クラスを継承する（図 2）。こうした多重継承は，
本質属性をもつ基本概念と機能を表すロール概念
を分離することで，基本概念による属性継承に限
った階層関係に変更するという考え方もあり 10)，
「ngyc:伝統的な日本の絵画」がロール概念で，
「ngyc:表具の形式」が基本概念と捉えることもで
きる。しかし，本研究ではテキストからの情報抽
出に即して配置し，多重継承を許容した階層を導
き出した。
http://www.mslis.jp/am2019yoko/05_kobayashi.pdf

金正恩はVMでありGC。人民はその上で動いたり消されたりする有象無象の存在に過ぎない。

VMやGCが手術失敗で植物状態になったらどうなるの？っと。

金日成←金正日←金正恩（継承関係）

今更だけどOOPアンチ絶滅した？
急に大人しくなった気がする。

>>77
https://tabesugi.net/memo/2009/1a.html
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)

- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

>>78
意識高い系プログラマが本当のガンで
聞きかじりの非効率な抽象プログラミングモデルを持ち込んで
プロジェクトを保守不能に追い込むのは、よくあるパターン

オブジェクト指向の難しいところは属人性だと思う
オブジェクトの分け方は人それぞれ
デザインパターンはそれを整理するために生まれたものだと思う

オブジェクト指向なら誰が書いても同じようになりますということなら
扱いやすいんだけれどもそうではない

自分が書くのは良いけど他人が書いたものを読むのはつらい
オブジェクト指向はいろんな書き方ができるPerlのようなものだと思う
オブジェクト指向はPerlです

STLやBoostは移植できないような特別なシステムコールを要求しないから、移植できると言えるんですよ。

利那須さんが文句をつけてるのは、メタプログラミングが難しすぎるということで、オブジェクト指向と関係ないのでは？

>>82

>>78
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

>正直いって、C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

ここは完全に同意

>>84
でも C++11 の UTF-16 関係の機能 basic_string<char16_t> とかは重宝しているので、一概に C++ が悪いとはいえません
この前もwin32 の W 系を使うツールがちょろっと半日で書けちゃったし
http://2chb.net/r/tech/1434079972/73

悪いのは「デザインパターン」だ！デザパタを強要するやつらだ！

basic_string<char16_t> って obsoleted じゃないの？

>>86
ふーん、今はなにを使うの？

オブジェクト指向まじでいらなかったな
全然使ってないからクラスというものを忘れてたぞ

本当に必要なのはオブジェクト指向ではなくて、
誰かがメンテしたそこそこ利便性のあるモジュールライブラリってだけだよな
そんなのFortranの時代からあるってーのw

誰かが作った便利なライブラリがあるから言えることだろ
鳥の雛が親鳥が餌を運んできてくれるから翼なんていらないと言ってるようなもの
便利なライブラリはオブシコで作られてるってことを認識したが良い

Cが出た時(すぐには)FORTRANからの置き換えが進まなかったのは
多次元配列のメモリ順が違ってたからだろうな

>>90
オブシコってｗ

オブジェクト指向型ライブラリってこれだろ
v = クラスnew
v.setter(1234)
v.func()


別に関数のみを提供する形で
func（ :a => 1234 ）

newもセッターもゲッターもない風にデザインしたって余裕で作れる

>>93
それ、ドメインモデル貧血症じゃね？
https://en.m.wikipedia.org/wiki/Anemic_domain_model

new可能な状態でsetter／getterつければオブジェクト指向って訳では無いよ
...ってことがURLの先で解説されてるから読んでみて