タグ付けされた質問 「object-oriented」

システムを、モジュール方式で制御および操作できるオブジェクトのセットとしてモデル化できるようにする方法論

17
なぜプライベートフィールドがあるのか​​、十分に保護されていないのですか？
privateクラスのフィールド/プロパティ/属性の可視性は有用ですか？OOPでは、遅かれ早かれ、クラスのサブクラスを作成することになります。その場合は、実装を完全に修正し、理解できると便利です。 クラスをサブクラス化するときに最初に行うことの1つは、多数のprivateメソッドをに変更することprotectedです。ただし、外界から詳細を隠すことは重要です。そのため、必要なのprotectedは単なるではなく、ですpublic。 私の質問は：privateではなくprotected、優れたツールである重要なユースケースについて知っていますか、または2つのオプション " protected＆public"でOOP言語に十分でしょうか？
23
不変オブジェクトが良い場合、なぜ人々は可変オブジェクトを作成し続けるのですか？[閉まっている]
不変オブジェクト¹が優れたシンプルなものであり、並行プログラミングでメリットがある場合、プログラマーはなぜ可変オブジェクトを作成し続けるのですか？ 私はJavaプログラミングで4年の経験があり、それを見ると、クラスを作成した後に最初に行うことは、IDEでゲッターとセッターを生成することです（したがって、変更可能になります）。認識不足がありますか、ほとんどのシナリオで可変オブジェクトを使用しても問題ありませんか？ ¹ 不変オブジェクトとは、作成後に状態を変更できないオブジェクトです。 ² 可変オブジェクトは、作成後に変更できるオブジェクトです。
14
Javaでのオブジェクト作成を避けるべきですか？
同僚から、Javaオブジェクトの作成は実行できる最も高価な操作であると言われました。したがって、できる限り少ないオブジェクトを作成することしかできません。 これは、オブジェクト指向プログラミングの目的をやや損なうようです。オブジェクトを作成していない場合、最適化のために1つの長いクラスCスタイルを記述しているだけですか？
2
パッケージ名は単数形ですか複数形ですか？
多くの場合、特にライブラリでは、パッケージには単一の概念に基づいて編成されたクラスが含まれます。例： XML、SQL、ユーザー、設定、デシベル。私たちは皆、これらのパッケージが単数形で正しいとかなり自然に感じると思います。 com.myproject。xml .Element com.myproject。sql .Connection com.myproject。ユーザー .User com.myproject。ユーザー .UserFactory ただし、タスク、ルール、ハンドラー、モデルなど、単一のタイプの実装のコレクションを実際に含むパッケージがある場合、これは望ましいですか？ com.myproject。タスク .TakeOutGarbageTask com.myproject。タスク .DoTheDishesTask com.myproject。タスク .PaintTheHouseTask または com.myproject。task .TakeOutGarbageTask com.myproject。タスク .DoTheDishesTask com.myproject。task .PaintTheHouseTask
15
なぜプライベート変数が必要なのですか？
クラスにプライベート変数が必要なのはなぜですか？ 私が読んだプログラミングに関するすべての本は、これはプライベート変数であると述べています。 これらの説明の言葉遣いは、私たちが本当に自分の職業に信頼の危機を抱えているように思えました。他のプログラマがコードを台無しにしようとしているように、説明は常に聞こえました。しかし、プライベート変数を持たない多くのプログラミング言語があります。 プライベート変数は何を防ぎますか？ 特定のプロパティをプライベートにするかどうかをどのように決定しますか？デフォルトですべてのフィールドがプライベートである必要がある場合、クラスにパブリックデータメンバーがあるのはなぜですか？ どのような状況で変数を公開する必要がありますか？
9
集計と構成
OOPの構成は理解していますが、Aggregationが何であるかを明確に把握することはできません。誰か説明できますか？
16
ゲッターとセッターはいつ正当化されるのか
ゲッターとセッターは、適切なオブジェクト指向ではないとしばしば批判されます。一方、私が見たほとんどのオブジェクト指向コードには、広範なゲッターとセッターがあります。 ゲッターとセッターはいつ正当化されますか？それらの使用を避けようとしていますか？それらは一般的に使い古されていますか？ お気に入りの言語にプロパティがある場合（私の場合）、そのようなものもこの質問のゲッターおよびセッターと見なされます。オブジェクト指向の方法論の観点からは同じです。より良い構文を持っています。 Getter / Setter Criticismの情報源（コメントを見やすくするためにコメントから引用したものもあります）： http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html http://typicalprogrammer.com/?p=23 http://c2.com/cgi/wiki?AccessorsAreEvil http://www.darronschall.com/weblog/2005/03/no-brain-getter-and-setters.cfm http://www.adam-bien.com/roller/abien/entry/encapsulation_violation_with_getters_and http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html 批判を簡単に述べると、ゲッターとセッターを使用すると、オブジェクトの外部からオブジェクトの内部状態を操作できます。これはカプセル化に違反します。オブジェクト自体のみがその内部状態に注意する必要があります。 そして、コードの手続きバージョンの例。 struct Fridge { int cheese; } void go_shopping(Fridge fridge) { fridge.cheese += 5; } コードのミューテーターバージョン： class Fridge { int cheese; void set_cheese(int _cheese) { cheese = _cheese; } int get_cheese() { return cheese; } } …
14
この「継承よりも有利な構成」という概念はどこから来たのでしょうか？
過去数か月で、「継承よりも好意的な構成」というマントラがどこからともなく生まれ、プログラミングコミュニティ内でほぼ何らかのミームになったようです。そして、それを見るたびに、私は少し神秘的になります。誰かが「ハンマーよりもドリルを好む」と言ったようです。私の経験では、構成と継承は異なるユースケースを持つ2つの異なるツールであり、それらを互換性があり、一方が本質的に他方より優れているかのように扱うことは意味がありません。 また、なぜ継承が悪く、構成が良いのかについての本当の説明は見ていません。信仰によって受け入れられるだけなのでしょうか？リスコフ置換とポリモーフィズムには、明確で明確な利点があり、IMOはオブジェクト指向プログラミングを使用するすべてのポイントを構成します。構成を優先して破棄する理由を説明する人はいません。 この概念がどこから来たのか、そしてその背後にある理論的根拠は誰か知っていますか？
8
悪いプログラミングの慣行は、ソフトウェア業界では一般的ですか？[閉まっている]
私は1ヶ月以上前にソフトウェア開発者として最初の仕事を始めました。OOP、SOLID、DRY、YAGNI、デザインパターン、SRPなどについて私が学んだことはすべて窓から捨てられます。 C＃.NET Webformsを使用し、コードビハインド内のほとんどすべてを、オブジェクトとは呼ばない、ごく少数の外部クラスで実行します。カスタムコントロールを使用して再利用します。使用されるオブジェクトは、Entity Frameworkのみです。クライアントごとにコードビハインドを再利用します。それらには、すべての種類の処理を行う400行のメソッドがあります。新しいクライアントの場合、aspxとaspx.csを取得し、クライアントコードを削除して、新しいクライアント固有のコードの追加を開始します。 彼らの最初の言い訳は、それが追加のメンテナンスを追加し、より多くのコードがより多くのメンテナンスであることです。私を含む3人の開発者の小さなお店です。1人の開発者には30年以上の経験があり、もう1人の開発者には20年以上の経験があります。1つはゲーム開発者で、もう1つは常にCとC ++で働いていました。 これはソフトウェア業界内でどのくらい一般的ですか？OOPおよび関連する原則を確実に把握するにはどうすればよいですか？空き時間に練習していますが、OOPをより良くするためには、より経験豊富な開発者の下で働く必要があると感じています。
17
戻り値が存在しない関数/メソッドからNULLまたは空の値を返す方が良いですか？
ここで推奨事項を探しています。戻り値が存在しないか判断できない場合に、メソッドからNULLまたは空の値を返す方が良いかどうかに苦労しています。 例として、次の2つの方法を使用します。 string ReverseString(string stringToReverse) // takes a string and reverses it. Person FindPerson(int personID) // finds a Person with a matching personID. ではReverseString()、戻り値の型が文字列であるため、呼び出し側はそれを期待しているため、空の文字列を返します。また、この方法では、呼び出し元はNULLが返されたかどうかを確認する必要がありません。 でFindPerson()、NULLを返す方が適切なようです。NULLまたは空のPersonオブジェクト（new Person()）が返されるかどうかに関係なく、呼び出し側は、何かを行う前に（呼び出しなどUpdateName()）PersonオブジェクトがNULLまたは空であるかどうかを確認する必要があります。ここでNULLを返すだけで、呼び出し側はNULLをチェックするだけでよいのはなぜですか。 他の誰かがこれに苦労していますか？どんな助けや洞察も大歓迎です。
14
メソッドの理想的な長さは何ですか？[閉まっている]
オブジェクト指向プログラミングでは、メソッドの最大長に関する厳密なルールはもちろんありませんが、これらの2つの引用符は相反するものであることに気付いたので、ご意見をお聞かせください。 でクリーンコード：アジャイルソフトウェアクラフトマンシップのハンドブックは、ロバート・マーティン氏は述べています： 関数の最初のルールは、関数は小さくなければならないということです。関数の2番目の規則は、関数はそれよりも小さくなければならないということです。関数の長さは100行であってはなりません。関数の長さが20行になることはほとんどありません。 そして、彼はKent Beckから見たJavaコードから例を示します。 彼のプログラムのすべての機能は、わずか2、3、または4行でした。それぞれが透過的に明らかでした。それぞれが物語を語った。そして、それぞれがあなたを説得力のある順序で次へと導きました。それはあなたの関数がどれほど短いかです！ これは素晴らしいように聞こえますが、一方で、Code Completeでは、Steve McConnellが非常に異なることを言っています。 ルーチンは、100〜200行まで有機的に成長できるようにする必要があります。数十年の証拠によると、このような長さのルーチンは、より短いルーチンよりもエラーが発生しにくいと言われています。 そして彼は、65行以上のルーチンを開発する方が安価であるという研究への言及を提供します。 この問題について意見が分かれていますが、機能的なベストプラクティスはありますか？
6
本当に「ビジネスロジック」とは何ですか？
私はPHPを始めた2009年からWeb開発に取り組んでいます。ASP.NETに移行したとき、この「ビジネスロジック」と「ビジネスルール」に多くの焦点が当てられているDDDとOOADについてよく耳にしました。要点は、これまでに開発したアプリはすべてCRUD操作に関するものであり、実際にこれらのことを見たことがないということです。 それらが実際に実際にどのようなものになるのか、私には想像できません。それでは、このビジネスロジックとはどのようなもので、アプリにどのように適合するのでしょうか？私はこれらがドメインモデルのメソッドとして実装されていることを知っていますが、それらのメソッドは何である可能性があり、アプリケーションのどこで使用される可能性がありますか？
12
TDDを実行する場合、プライベートメソッドを避ける必要がありますか？
私はちょうどTDDを学んでいます。パブリックメソッドはオブジェクトの整合性を検証するのに十分な情報を提供するので、プライベートメソッドはテストできず、心配するべきではないというのが私の理解です。 私はしばらくの間OOPを理解しました。私の理解では、プライベートメソッドはオブジェクトをよりカプセル化するため、変更やエラーに対する耐性が高まります。したがって、デフォルトで使用する必要があり、クライアントにとって重要なメソッドのみを公開する必要があります。 さて、プライベートメソッドのみを持ち、イベントをリッスンすることで他のオブジェクトとやり取りするオブジェクトを作成することは可能です。これは非常にカプセル化されますが、完全にはテストできません。 また、テストのためにメソッドを追加するのは悪い習慣と考えられています。 これは、TDDがカプセル化と対立することを意味しますか？適切なバランスは何ですか？私は今、私のメソッドのほとんどまたはすべてを公開したいと思っています...
17
カプセル化はまだOOPの象の1つですか？
カプセル化により、すべてまたはほとんどすべてのフィールドをプライベートにして、ゲッター/セッターによってこれらを公開するように指示されます。しかし、Lombokなどのライブラリが登場し、1つの短い注釈ですべてのプライベートフィールドを公開できるようになりました@Data。すべてのプライベートフィールドのゲッター、セッター、および設定コンストラクターを作成します。 誰かが私にすべてのフィールドをプライベートとして非表示にし、その後いくつかの余分な技術でそれらのすべてを公開するという意味を説明できますか？なぜパブリックフィールドだけを使用しないのですか？私たちは出発点に戻るためだけに長く困難な道を歩んだと感じています。 はい、ゲッターとセッターを介して機能する他のテクノロジーがあります。そして、単純なパブリックフィールドを介してそれらを使用することはできません。しかし、これらの技術が登場したのは、私たちがそれらの多くの特性を持っているからです-公共のゲッター/セッターの背後にあるプライベートフィールド プロパティがなければ、これらの技術は別の方法で開発され、パブリックフィールドをサポートします。そして、すべてがシンプルになり、ロンボクは今は必要ありません。 このサイクル全体の意味は何ですか？そして、実際のプログラミングではカプセル化は本当に意味がありますか？
13
可能な場合、ローカル変数を削除する必要がありますか？
たとえば、AndroidでCPUをオンに保つには、次のようなコードを使用できます。 PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE); WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc"); wakeLock.acquire(); しかし、私はローカル変数powerManagerと考えるwakeLockことができます： ((PowerManager)getSystemService(POWER_SERVICE)) .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag") .acquire(); 同様のシーンがiOSアラートビューに表示されます。例：from UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"my title" message:@"my message" delegate:nil cancelButtonTitle:@"ok" otherButtonTitles:nil]; [alert show]; -(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{ [alertView release]; } に： [[[UIAlertView alloc] initWithTitle:@"my title" message:@"my message" delegate:nil cancelButtonTitle:@"ok" otherButtonTitles:nil] show]; -(void)alertView:(UIAlertView *)alertView …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.