「オブジェクト指向」を含む日記 RSS

はてなキーワード: オブジェクト指向とは

2018-08-08

「○○おじさん」は小動物的かわいさの為に使われるべき

そうなんだおじさん「そうなんだ」  ← かわいいレタス好きそう。すき。

staticおじさん「オブジェクト指向きらい」   ← 敵意を込め過ぎ。きらい。

2018-08-01

オブジェクト指向呪いと、その避け方」と、その読み方

http://mizchi.hatenablog.com/entry/2018/07/31/124354

念の為言っておきますOOP呪いについては特に異論はありません。

クラスしかメソッド所属できないモジュールシステム

古いJavaのような、クラスしかメソッド所属できないモジュールシステムばかりの時代じゃありません。 クラス基本的不要だと思います

Javaは今でも「クラスしかメソッド所属できないモジュールシステム」でしょ。クラスに属していないように見えるのは糖衣構文に過ぎない。

関数参照

https://twitter.com/mizchi/status/1024103868613812225]

オブジェクト指向呪いほとんどの言語モジュールシステムでは関数参照がそのままexportできるのに、すべての関数を static メソッドまたはクラスメソッドとして表現する人が未だに多く、見るたびに指摘してる…

関数参照ってなんですか?「exportする」ってそんなに一般的ではない気がする。

もしfunctionオブジェクトをimportするのを指しているのならば、所詮オブジェクトなので状態が含まれない保証はない。

関数参照 2

https://twitter.com/mizchi/status/1024104303907065856]

RubyJavaPHP でみたので一般的なアレなんだと思う

そりゃJSみたいに柔軟なインポートができる言語ばかりじゃないし…

classの導入

https://twitter.com/mizchi/status/1024151165703938048]

JS似非OOP慣習と向き合うのに class の導入は必要だったと思うけど、それはそれとして class 使わないのは別

これはそう。結果論的にはclassそもそも導入されるべきではなかった気もするけど。

ijk

https://twitter.com/mizchi/status/1024155163399876609]

Dijkstraのijkが好き

めちゃくちゃわかる

記事とは関係ない思い

湧いてきたら追加する

anond:20180801134151

素人目線だと普通プログラムよりオブジェクト指向の方が理解やすいぞ

データも取り出しやすいし取り回しやすくてこれ考えた人スゲーなって思ってたけど

仕事で組むとそうでもなくなるの?

anond:20180801134151

面倒な処理を全部やらせクラス を1つ作っておくだけでも、

全体の見通しが良くなるので、オブジェクト指向価値があるし、初心者はそれで十分ちゃうかなぁとは思う。

オブジェクト指向プログラミング

ハテブのテクノロジーカテゴリーオブジェクト指向うんぬんというエントリ連続で見た。

議論が盛り上がってるんだろうけど読むのが面倒で見てない。

オブジェクト指向は、有用性のあるなし以前に、難しすぎるって時点で失敗だよな。

一般人にはカプセル化理解限界で、抽象型までいくと使えるプログラマーなんてほとんどいない。

カプセル化にしたって、似たような処理を全部一個のクラスメソッドとしてつっこんだだけとか、カプセル化理解してないんだろうなってコードよく見るし。

2018-06-28

時代とともに変わるソフトウェア開発の基礎

コンピュータソフトウェアを開発、運用するエンジニアが持つべ知識スキルの基本セットとは何か?

例えばインテルCPUアセンブラが書けます!と言った場合就活で有利になる場面がどれだけ想像できるか。

UMLクラス図書ます!とか、暗号化理論バッチリだぜ!とか、相対性理論なら任せとけ!とかの場合

おうおうおう、だったら弊社のホームページをカッコよくしてくれよみたいな案件無難にこなせるのかというと

甚だ疑問では無いだろうか。

一昔前はソフトウェアハードウェアのおまけだったわけで、ハードウェアこそがエンジニアが抑えるべき基礎だった。

時代は変わり、ソフトウェアでできることはものすごく多くなった。スマホアプリを作るのに組み込み知識がなくても困らない。

からこそ、現代ソフトウェアのみのエンジニアは旧来のコンピュータ関連エンジニアと道を分かたれている事を自覚しなければならない。

自分キャリア自分デザインする必要があるということ。

古いエンジニアの教えに沿えば、自分も古いエンジニアになる。

今の時代の最適解を見つけるのは困難かもしれない。

だけど組み込み系やマイコン制御をしないのであればアセンブラC言語よりも優先して学習することはいくらでもある。

C#C++よりもPHPが優先される場面もある。

html,css,javascript をある程度自在に扱えるようになるのも長期間の訓練による積み重ねが必要になる。

コンピュータサイエンスネタが無いな……これはプログラミングに役立つネタももちろんあって、構造プログラミングオブジェクト指向プログラミングなんかもそうだけど、表層的に関数分けました、クラス分けましたとかしてもうまくいかない。ネストが浅けりゃいいってわけじゃない。プログラミング以外のネタもある。サラリーマン巡回問題とか。

2018-06-24

関数型言語、本とか読んで勉強したりコード書いてると大変楽しいんだけど

ネット上で情報検索しようとするととたんに信者たちがオブジェクト指向のディスであったりHaskell信者Scalaユーザー内戦仕掛けてたりしてノイズまみれなのどうにかならないかなあ

関数型言語機能や利点を説明する時にいちいちオブジェクト指向比較してディスらなくていいよ

Haskellではこう書くよ」の後に「Scalaではこうなって面倒だよ」とかつけなくていいよ(たいていよく調べるとScalaでも簡潔に書くための糖衣構文があったりする)

 

オブジェクト指向10年ぐらい前の記事が引っかかるとそんな感じではあるんだけど

2018-05-30

anond:20180530111137

いたことないね。その時代なら新しいもの好きは Java に走ったんじゃないかな。

オブジェクト指向といえば C++ なんかの時代だったからね。

anond:20180530111137

COBOLが古いって話題になるとオブジェクト指向COBOLとかあるぞって反論がつくけど、絶対現場COBOL85だと思うわ。

2018-05-24

フレームワークチュートリアルどおりに進めれば、自然DBテーブル対応したクラスを作ることになるじゃん?

そこにデータに関連するメソッド生やしていけば、一応、オブジェクト指向になるじゃん?

2018-05-17

オブジェクト指向は大規模ソフトウェアモジュール化し再利用やすくすると言われていたが、センスに差のあるプログラマたちがそれぞれのオブジェクト指向を駆使してできたのはただの地獄だった

趣味プログラミングしてる

趣味と言ってもホント簡単ものしか作れないけど、オブジェクト指向が何なのか何も分かっていない。やれクラスメソッドカプセル化継承がだとか言ってるけどいーみがわからん

自分が書いたプログラム見るとクラスなんてねーしメソッドっぽいものなんてのもないしQlitaとかで見る他の人がかいたやつとぜんぜん違うのもこれが原因してるのか

大規模なやつとか作るようになったら使ったりするのか。二十~三十行の簡単すぎるやつしか作ってないからまだこれらが必要とする場面にいたってないのか

2018-05-02

C#の静的メソッドの使い所ってどんなとこ

あんま多用しすぎるとこれオブジェクト指向意味ねえだろってなるし

2018-04-11

つらい

SIerだけどもうつらい。今月もほとんど終電。入る会社間違えた

営業

  • 全部開発に丸投げ。提案依頼で協力を求めてもガン無視

開発

レベルがとにかく低い。見積して客に詰められたときに、行き着くところが開発のレベルの低さだったりするのでどうしようもない。無能なほうがお金もらえるのおかしいよね

マネジメント

2018-03-30

プログラム)一連の処理の流れをパッケージ化したい

言語に関わらず

リファクタすると細切れなメソッドになると思うんだが

メソッドAはメソッドBからしか呼ばれたくない」みたいなことってあると思うんだ

一人で開発してればそういうのは覚えてりゃ良いんだけど

複数人で開発してると、せっかくいい感じにリファクタしてA→B→C→D→Eってメソッドの流れ作ってるのに

途中だけ使われたり乱入されたり、グチャグチャにされることがある

から、A〜Eをセットにしたり、入り口と出口をコントロールしたいんだよね

 

名前をつけるとしたらModal methodsって言う感じ

今は大体Modelessすぎる

 

もちろんクラスにして〜とかオブジェクト指向的に〜とか関数型言語で〜っていう話になりそうなのは分かるんだが

もっとシンプルコントロールできて良いと思う

けどそういう思想未だ見たことがない、大体みな構造的な方法を取ってる

それじゃリファクタ意味無いし変更するのも大変じゃん?

 

あ、inputが◯◯であることを保証するとか制限するみたいなの、何かあった気が

でもどう足掻いてもめんどいんだよな

面倒臭すぎてうわー!って1メソッドに詰めることもたまにある

2018-03-26

タモリが「最近オブジェクト指向っていうのが流行ってて、COBOLJavaに置き換えられてて」とか話したら、はてなはどうなってしまうのか

2018-03-22

N予備校プログラミング入門コースを修了した

https://anond.hatelabo.jp/20170911110731

昨年、はてブでバズりまくったエントリにまんまと乗せられた実務経験なしのプログラミング初心者

N予備校プログラミングコースプログラミング入門 Webアプリコース(有料のプログラミングコースで一番最初にやるコース)を修了したので知見をまとめておきます

とりあえず結論

そんな感じです。以下、理由

経験者の独学はほぼ無理。

客観的データをあげると、

入門コース実践編となる3章からは各講義最後課題が出されて、

N予備校GitHubリポジトリにプルリクエストを出すことで課題の提出に変えて、

学習を進めていくのですが、

3章最初課題の提出数は現在424件あるのですが、

https://github.com/progedu/intro-curriculum-3001

入門コースラストの4章最後課題の提出数は現在24件です。

https://github.com/progedu/intro-curriculum-4023

ちょうど動画ベースの講座がこないだ終わったところなので、

単純に計算すると脱落率約95%となっています

課題は解答をコピペして提出することも可能なので、

ちゃんと内容を理解できている人の割合さらに低いと思われます

なんで?

なぜそんなに脱落していくかというと、まあ難易度だったり色々あるとは思うのですが

基本的には説明不足ということだと考えています

~をするにはこういうプログラムを書けばいい!ということは教えてくれるのですが、

なぜ、こういうプログラムを書けば~ができるのかということについての説明が少ないです。

感覚としては、途中の式と解答だけが書いてある数学参考書を読み進めているような感じで、学習者には途中の式の意味自力で読み解く能力が求められます

その過程ドキュメントをあたったり、自ら調べて解決する能力必要です。

またアロー関数式だったり、三項演算子論理演算子を用いた代入などの省略記法を多用する割にソースコード中にほとんどコメントを書かないことも初学者には難しいかなと感じました。

体系的な学習にも不向きです。

あとオブジェクト指向説明をせずに、JavaScriptオブジェクトを扱っていたり、

データベース学習をする前に、MVCパターンを扱っていたり、ちぐはぐさを感じるところも多かったです。

ということで(他にもいろいろあるのですが)、未経験者が独学で進めていくのは厳しいんじゃないかな~というのが入門コースを終えての結論です。

たとえば保護者の方が専門のエンジニアで分からないことがすぐに聞けるような環境にあればよい教材になるかもしれません。

初心者が中級者へステップアップするきっかけになる可能性はある。

ただ中級者へのステップアップを目指している初心者きっかけをつかむには良い教材になりえるとも感じました。

私自身、GitHubLinux(Ubuntu)、Node.jsExpressフレームワークなど、自主的にはなかなか食指が動かなかった分野の知識を得ることができたと思います

難易度は高いですが、中級者向けのまとまった教材というのはネット上にもあまりないと思いますので、ある程度経験のあるプログラマ知識を深めるために利用するのはありだと思います

それでも体系的な知識が得られるかというと微妙ですが…。

ちゃん勉強しようとするとかなり時間必要

ただ社会人学習を進めるにはまとまった時間の確保というのがネックになるとは思います

N予備校の入門コースの想定学習時間は180時間だったと思いますが、私はこのコースを修了するのに400時間前後かかったと思います

(今年の1月初頭からほぼ毎日午後を勉強時間に充てて、ようやく昨日入門コースを修了しました)

コースを終わらせることだけを目標にするならもっと短くできるとは思いますが、ある程度知識をつけて今後にいかすことを目標にするとなると、想定学習時間内でコースを終わらせるのは難しい気がします。

これから学習してみようと思っている方へ

色々書きましたが、それでも月1,000円というのは破格の価格設定だと思いますので、気になっている方は挑戦してみてもよいのではないでしょうか。

おすすめ学習方法としては

などがおすすめです。 「「分かりそう」で~」のサイトには本当にお世話になりました。m(_ _)m

ただ特にプログラミング経験の浅い方に伝えたいのですが、N予備校の入門コース理解できなかった、挫折たからといって、プログラミングができないということはまったくないです。

私自身、SEプログラマとしての実務経験はありませんが、趣味でも仕事でもガンガンプログラム活用しています

それでもN予備校の入門コースの内容は相当難しかったです。

ぜひ挫けずにプログラミング学習を続けていただきたいなと思っています

あとネット上にはN予備校プログラミングコースレビュー散見されますが、無料コースしかやってないんじゃないかなーというものが多いのでお気をつけください。

基本的無料コースと有料コースは別物と考えたほうがよいと思います

参考になれば幸いです。

ところで、N予備校ニコニコ動画再現コース2017年度中公開予定になってるんですけど、本当に公開されるんですよね・・・?(※)

3/31 追記 ※ギリギリでしたがちゃんと公開されたようです。退会してから気づいたので内容はわかりません。

2018-03-11

anond:20180311002703

手続き型、オブジェクト指向関数

どんどん回りくどくなってめんどくさくなってリソース無駄遣いしていく

勘弁してほしい

2018-02-25

pythonって一貫性なさすぎじゃない?

いや、実用的で素晴らしい言語だと思うよ。

でもさ、なんか一貫性が無いように感じるんだよね。

まず、言語の大半の部分がオブジェクト指向言語っぽいデザインになってるのに、listの要素数を測る手段len()って*関数*なのはどうなの?

(しか略語って...)

a = [1, 2, 3]
len(a)  # 3

他にもあるよ! pythonくんのアレな所

俺は、sortとsortedって言う命名からこの挙動をまったく予測できなかった。

  • 破壊的変更をする list.sort()
a = [1, 3, 2]
a.sort()  # None
a  # [1, 2, 3]
sorted([1, 3, 2])  # [1, 2, 3]

しかもsortedにdictを渡すとkeyがlistに変換されてソートされて返ってくる。

コードリーダビティに関する本を開けば、どの本にだって「良い名前選択する」ことの重要性が書かれていると思う。

「sort()が破壊的で、sorted()が非破壊的、sorted()にdictを渡すとkeyのlistがソートされて返ってくる」これって良い命名なのかな?

pythonくんってこう言う所あるよね

配列の要素を文字列連結

", ".join(['1', '2', '4', '8', '16'])  # "1, 2, 4, 8, 16"

えーっ、join()のレシーバー区切り文字って…引くわー

しかも、これに対する「文字列リテラル (文字列定数) のメソッドを使うのは*醜すぎる*」という意見に対しての公式の返答が、これってのも凄い。

かにそうかも知れませんが*文字列リテラルは単なる固定された値に過ぎないというのが答えです。文字列に束縛された名前メソッドが許されるなら、リテラルに使えないようにする論理的理由はないでしょう。

https://docs.python.jp/3/faq/design.html#why-is-join-a-string-method-instead-of-a-list-or-tuple-method

The Zen of Pythonで「醜いより美しい方がいい」って言ってましたやん。

そもそもリテラルかどうかに関係なくstrインスタンスにこのメソッドがある事がおかしいと思った。

なんでpythonくんって一貫性ないの? pythonくん「歴史です」

pythonmap関数として実装されている。(まただよ...)

list(map(lambda x: x*x, [1, 2, 3]))  # [1, 4, 9]

なんでメソッドにしなかったの? って質問に対して公式がこう答えてる。

主な理由歴史です。複数の型に対しての総称的な操作で、対象オブジェクトメソッドを全く持っていなかった (例えば、タプル) としても働くよう意図したもの関数は使われました。

(中略)

個々のケースについては粗探しのしようがありますが、Python の一部であるし、根本的な変更をするには遅すぎます

https://docs.python.jp/3/faq/design.html#why-does-python-use-methods-for-some-functionality-e-g-list-index-but-functions-for-other-e-g-len-list

うわー、信じられねぇ…

歴史的経緯があるから一貫性が無いのは仕方ないみたいなこの感じ。

これが設計思想に「醜いより美しい方がいい」を掲げるpython実装なんだねぇ…

pythonくんの良い所

散々pythonの事を悪く言ったけど、おれ実はpythonくんの良い所もいっぱい知ってるんだ。

pythonくんの良い所:

ライブラリが超充実してる!
インデントコードブロック表現する文法クール!
PEP8という規約であるべきコードフォーマットを明示したのが良いよね。
Cythonで高速化楽ちん!
namespaceが使いやすい! デコレーター便利!

美しくない、それゆえに強いプログラミング言語python

The Zen of PythonPython設計思想が色々書いてある。

「醜いより美しいほうがいい」という指針があることはさっき紹介した通りだ。

pythonがそれを体現してるとは、僕にはどうも思えない。

でもThe Zen of Pythonには「Although practicality beats purity.(実用性を求めると純粋さが失われることがある。)」とも書いてある。

pythonはこの設計思想を他の言語には無い高いレベル体現してるとは思う。

pythonは、

節操に色々取り入れた上で、「tupleからメソッドはやせないから、map関数にする」とか、メチャクチャ方法でそれらを統合した言語だ。

だが、そういう言語からこそ、pythonで書いたコードを育てていく中で様々なパラダイムへとシームレスに変化させていく事ができる。

そういう「不純であるがゆえに柔軟性を持ったプログラミング言語pythonだと思う。

ruby純粋性はすごいよ。イカれたくらい徹底されたオブジェクト指向

BaseObjectをrootとする継承のツリーの中に世界のすべてが収まっている。

haskell純粋性も凄い。「代入が無い」プログラミング言語に初めてであった時の衝撃。

でも、そういう純粋性をかなぐり捨てたpythonにはタブーが無い。

不純で醜い、それゆえに強い言語python.

から僕はrubyとの思い出を反芻し、haskellに焦がれながら、明日pythonを選び、書いていく。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん