質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Python 3.x

Python 3はPythonプログラミング言語の最新バージョンであり、2008年12月3日にリリースされました。

オブジェクト指向

オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

Q&A

解決済

1回答

3883閲覧

Python クラスメソッドからインスタンスメソッドへのアクセス

_Victorique__

総合スコア1392

Python 3.x

Python 3はPythonプログラミング言語の最新バージョンであり、2008年12月3日にリリースされました。

オブジェクト指向

オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

Python

Pythonは、コードの読みやすさが特徴的なプログラミング言語の1つです。 強い型付け、動的型付けに対応しており、後方互換性がないバージョン2系とバージョン3系が使用されています。 商用製品の開発にも無料で使用でき、OSだけでなく仮想環境にも対応。Unicodeによる文字列操作をサポートしているため、日本語処理も標準で可能です。

0グッド

0クリップ

投稿2017/06/13 11:32

###前提・実現したいこと
クラスメソッドからインスタンス変数へのアクセスができないのはわかるのですが、クラスメソッドからインスタンスメソッドへのアクセスは可能でしょうか?

###該当のソースコード
以下のようなことは可能でしょうか?もしくは全てクラスメソッドにしてしまうべきでしょうか?

python

1class test: 2 def testA(self): 3 # 4 # 5 # 6 def testB(self): 7 # 8 # 9 # 10 def testC(self): 11 # 12 # 13 # 14 @classmethod 15 def testA(cls): 16 self.testA() 17 self.testB() 18 self.testC()

###補足情報(言語/FW/ツール等のバージョンなど)
Python3.6.1
MacOS Sierra

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

YouheiSakurai

2017/06/13 12:59 編集

提示の事はできないです。で、どうすべきかはなぜ関数の列挙ではなくクラスにしたかという理由によります。なぜですか?
guest

回答1

0

ベストアンサー

クラスメソッドからインスタンスメソッドへのアクセスはできません。

また、全てがクラスメソッドのクラスは、継承してオーバーライドするかメタクラスを使う場合を除いて、作る意味はありません。
なぜならばPythonは名前空間がモジュール単位になっており、C++で言うところのグローバルな名前空間がないからです。

全てがクラスメソッドで良い場合は、通常はモジュールにそのまま関数を書きます。

投稿2017/06/13 13:17

pashango2

総合スコア930

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

_Victorique__

2017/06/14 00:21

オブジェクト指向プログラミングで開発をしていると仮定して、そういった関数はファイルに散らばったままで良いのですか?同じまとまりならクラスにまとめたほうがスッキリするという考え方は間違っていますか?
pashango2

2017/06/14 01:43 編集

Pythonではモジュール(ファイル)自体が一つの大きなオブジェクト(カプセル)と考えられます。 1つのモジュール(ファイル)に対して、異なるまとまりのコードを複数書こうとしているのでしょうか? 粒度によりますが、1モジュールにつき1まとまりの機能の方がスッキリすると思います。 そして、そのモジュールをアクセスしやすい形にまとめあげるのがパッケージです。
pashango2

2017/06/14 01:43

あと何を持ってオブジェクト指向としているのかを書いてもらえると、他の方も回答しやすいかと思います。
_Victorique__

2017/06/14 01:49

ファイルに分けるのは分かります。 ですが、そのままモジュールに関数を書いていると肥大化してきませんか?ということです。それとも何かコードの意味で分けてそれぞれ別のモジュールに書くのですか? >なにをもってオブジェクト指向としているのか これはどういった意味でしょうか?
pashango2

2017/06/14 04:25 編集

> ですが、そのままモジュールに関数を書いていると肥大化してきませんか?ということです。 モジュールに関数を書くと「肥大化する」と思う要因を教えてください。 - 重複コードが増えるので肥大化する - クラスにしておけば継承して差分を別ファイルに書ける - その他 > それとも何かコードの意味で分けてそれぞれ別のモジュールに書くのですか? ここらへんは各々のセンスになるので正解というものはありませんが、私はモジュールの役割と責任範囲が具体的なワンセンテンスの文章で説明できない場合、モジュールを分割します。 > >なにをもってオブジェクト指向としているのか > これはどういった意味でしょうか? オブジェクト指向は非常に曖昧な概念で、個々に意識のズレがあります。 例えば、オブジェクト指向は1ファイルに全ての処理を書くべきという人もいますし、 全てのコードをクラス内に書くのがオブジェクト指向という人もいます。 お聞きしたいのは、オブジェクト指向の何を持って全てがクラスメソッドのクラスを作るのか? どのような意図でそのような設計にするのか? ということです。
_Victorique__

2017/06/14 04:59

最後の一つだけ ユーティリティクラスのつもりで作っています。Pythonの場合はモジュールにそのまま書けばいいですが、C++などはそうはいかないですよね?ユーティリティクラスはオブジェクト指向的に言えば悪という意見が多いですが>pashango2さんも同様のかんがえなのでしょうか?
pashango2

2017/06/14 05:59 編集

> C++などはそうはいかないですよね? `namespace`と`static`変数を使えばPythonのように書けますけど、そこは好みによりますね。 > ユーティリティクラスはオブジェクト指向的に言えば悪という意見が多いですが > pashango2さんも同様のかんがえなのでしょうか? うーん、別に悪くはないと思います。 逆になんで悪いんですかね?ちょっとその意見も聞きたいです。 個人的には、オブジェクト指向的とかそれほどこだわりがなくて、オブジェクト指向的がマッチすれば それで組むし、手続きの方がシンプルならそっちを使います、混在しても良いと思います。 逆に一方にこだわってしまうと、ヘンテコな設計になります。 オブジェクト指向は「カプセル化」が重要だと思っていて、カプセル化とはデータと振る舞いを同じ場所に書くことではなくて、複雑な動作の隠蔽、ブラックボックス化、抽象化を指します。 複雑なものは小さく疎結合にして単純化していく設計こそ、オブジェクト指向の本質だと思っています。 だから、 - コードが全てオブジェクトであるべき - 現実的なモノを模倣すべき - オブジェクトの動作は一つのファイルにまとめるべき とか、そういうのは本質から外れていると思うんですよね。 ユーティリティクラスは複雑な動作をカプセル化で隠蔽しているんだから、オブジェクト指向で悪という事はないと思います。 話が長くなりましたが、Pythonでクラスメソッドだけのクラスは、モジュール自体がカプセル化の役割を担っているので不要だと思っています。 ただしC++への移植性の事を考えての設計であれば、それは「あり」だと思います。
pashango2

2017/06/14 06:00

すいません、ちょっとだけ追記しました
_Victorique__

2017/06/14 06:08

ユーティリティクラスに関する意見に関してはネットでたくさんあるのでそちらをみていただけませんか? https://www.kaitoy.xyz/2016/01/03/oop-alternative-to-utility-classes/ https://anopara.net/2014/06/03/%E3%83%A6%E3%83%BC%E3%83%86%E3%82%A3%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AF%E3%83%A9%E3%82%B9%E4%B8%8D%E8%A6%81%E8%AB%96/ 混在してはいいとおっしゃいますが、最低限譲れない部分があるのではないですか?それを教えていただきたいです。
pashango2

2017/06/14 17:30 編集

まず、はじめに断っておきたいですが、これは正解はありませんので、私個人の意見です。 >ユーティリティクラスに関する意見に関してはネットでたくさんあるのでそちらをみていただけませんか? 最初に提示された方とほぼ同じ意見です。 https://www.kaitoy.xyz/2016/01/03/oop-alternative-to-utility-classes/ ユーティリティクラス反対派の主張が、それがオブジェクト真理教の教義に照らして適切なオブジェクトではなく、オブジェクト指向の世界に適合しないという哲学的なものである時点で、ユーティリティクラスをやめる動機に全くつながらない。 transform()の実装は、Apache Commonsを使ったやつの方が自分でクラスを作らなくて済み、開発量が少なくてよい、というのが普通の感覚ではないだろうか。 さらに、Yegorのtransform()の実装だと、I/O処理を隠蔽しすぎて何をやっているのかコードからさっぱりわからない。 addAll()するとファイルへの書き込みが発生するなんて誰も想像だにしまい。 オブジェクト真理教の神のみぞ知るといった感じの挙動だ。 こんなコードで可読性、つまり保守性が「手続き型の例」のやつより高くなるとは到底思えない。 > 混在してはいいとおっしゃいますが、最低限譲れない部分があるのではないですか?それを教えていただきたいです。 私個人ではあまり譲れない部分はないのですが、オブジェクトが密結合になる事だけは気をつけています。 それ以外はあまりこだわりはないですね、シンプルでコード量が少なく、あとで見やすいコードであれば技法は何でもよいと思ってます。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問