ソフトウェア工学

私はプログラミングを始めたばかりで、さまざまなソースのさまざまな慣習を読んだり聞いたりすることから少し混乱しています。 オブジェクト指向プログラミングには4つまたは5つの概念がありますか？ 新参者として、私はこれらが5つの概念であることを理解しています： 抽象化 継承 カプセル化 多型 モジュール性 では、どうして「厳密な」定義が見つからず、これらの概念のいくつかのアレンジがそこにあるように思えますか？

12 object-oriented 

似たような質問がたくさんあります 1、2、3、4、ただし、この質問ではnonは当てはまらないようであり、解は最適とは思われません。 これは一般的なOOPの質問であり、多態性、ジェネリック、およびミックスインが利用可能であると仮定しています。実際に使用される言語はOOP Javascript（Typescript）ですが、JavaまたはC ++でも同じ問題です。 並列クラス階層があり、同じ動作（インターフェイスと実装）を共有することもありますが、それぞれに独自の「保護された」動作があります。次のように説明します。 これは、説明のみを目的としています。実際のクラス図ではありません。それを読むには： 共通階層（中心）のすべては、Canvas（左）階層とSVG（右）階層の両方で共有されます。シェアとは、インターフェースと実装の両方を意味します。 左または右の列にのみあるものは、その階層に固有の動作（メソッドとメンバー）を意味します。例えば： 左右の階層は、まったく同じ検証メカニズムを使用しViewee.validate()ます。これは、共通の階層で単一のメソッド（）として示されています。 キャンバス階層のみにメソッドがありpaint()ます。このメソッドは、すべての子に対してpaintメソッドを呼び出します。 SVG階層はのaddChild()メソッドをオーバーライドする必要がありますCompositeが、キャンバス階層の場合はそうではありません。 両側の階層の構造を混在させることはできません。工場はそれを保証します。 解決策I-継承を離れる Fowler's Tease Apart Inheritanceは、2つの類似点の間に矛盾があるため、ここでは役に立たないようです。 解決策II-ミックスイン これは私が現在考えることができる唯一のものです。2つの階層は別々に開発されますが、各レベルでクラスはクラス階層の一部ではない共通クラスに混在します。structuralフォークを省略すると、次のようになります。 各列は独自の名前空間にあるため、クラス名は競合しません。 質問 誰でもこのアプローチで障害を見ることができますか？誰もがより良い解決策を考えることができますか？ 補遺 これがどのように使用されるかを示すサンプルコードを次に示します。名前空間svgは次のように置き換えられますcanvas： var iView = document.getElementById( 'view' ), iKandinsky = new svg.Kandinsky(), iEpigone = new svg.Epigone(), iTonyBlair = new svg.TonyBlair( iView, iKandinsky ), iLayer = new svg.Layer(), …

12 design-patterns  object-oriented  inheritance  multiple-inheritance  mixins 

私はGitHubをかなり長い間使用しており、通常は機能ブランチをプッシュしてから、自分でマージしたプルリクエストを開始していました。ブランチをマージした場所を追跡するのに役立つことがわかりました。 しかし最近、Gitの仕組みについてますます読んでおり、マージコミットを使用してブランチをマージするときに参照できることに気付きました。 マスターに機能ブランチをマージするときだから、私は何をすべき： 実行し、マージコミットマスターにして、それが上流押しORローカルブランチを押して、プルリクエストを開始しますか？ 2人のチームのプルリクエストの紹介を読みました-自分のリクエストをマージしますか？そしていただきましたプロジェクトの2人との作業の流れと公式レポや私のフォーク上の枝から万一Iオープンプル要求？しかし、彼らは誰も私が探しているものに答えていないようです。

12 git  github  merging  pull-requests 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Resolve依存関係の挿入（インターフェイスへの実装の解決）、パッケージマネージャー（例：パッケージの依存関係の解決）、Web（例：ホスト名の解決）で、単語が使用される多くの場所で見ます。 では、コードのロジックを特別なものにして、誰かResolveが単純なConvert、Transformまたはさらには単語を選択するようにするのはGetなぜですか？

12 programming-practices  naming  dependency-injection  packages 

Effective JavaのItem 18にあるように、スケルトン実装を持っています（詳細な議論はこちら）。これは抽象クラスであり、2つのパブリックメソッドmethodA（）およびmethodB（）を提供し、サブクラスメソッドを呼び出して、抽象化された方法では定義できない「ギャップを埋める」。 最初に具体的なクラスを作成し、そのための単体テストを作成して開発しました。2番目のクラスが来たとき、共通の動作を抽出し、2番目のクラスに「欠落したギャップ」を実装することができました（もちろん、2番目のサブクラスに対して単体テストが作成されました）。 時間が経ち、今では4つのサブクラスがあり、それぞれが具体的な実装に非常に固有の3つの短いプロテクトメソッドを実装していますが、骨格実装はすべての一般的な作業を行います。 私の問題は、新しい実装を作成するときに、もう一度テストを書くことです。 サブクラスは特定の必須メソッドを呼び出しますか？ 特定のメソッドに特定の注釈がありますか？ メソッドAから期待される結果が得られますか？ メソッドBから期待される結果が得られますか？ このアプローチの利点を見ながら： テストを通じてサブクラスの要件を文書化します 問題のあるリファクタリングの場合、高速で失敗する可能性があります サブクラス全体とパブリックAPIを使用してテストします（「methodA（）は機能しますか？」ではなく、「このprotectedメソッドは機能しますか？」） 私が持っている問題は、新しいサブクラスのテストは基本的に簡単です：-テストはすべてのサブクラスですべて同じであり、メソッドの戻り値の型を変更するだけです（スケルトン実装はジェネリックです）。テストのアサート部分を確認してください。-通常、サブクラスにはそれらに固有のテストはありません テストがサブクラス自体の結果に焦点を当て、リファクタリングから保護する方法が好きですが、テストの実装が単なる「手動作業」になったという事実は、私が何か間違ったことをしていると思うようにします。 クラス階層をテストするときにこの問題は一般的ですか？どうすればそれを回避できますか？ ps：スケルトンクラスのテストについて考えましたが、抽象クラスのモックを作成してテストできるようにするのも奇妙に思えます。そして、サブクラスが予期していない動作を変更する抽象クラスのリファクタリングは、それほど速くは気付かれないと思います。私の勇気は、サブクラスを「全体として」テストすることがここで好ましいアプローチであることを教えてくれますが、間違っていると教えてください:) ps2：私はグーグルで調べて、このテーマに関する多くの質問を見つけました。そのうちの一つがこれ一つであり偉大な答えナイジェルソーンからの、私の場合は彼の「ナンバー1」になります それは素晴らしいことですが、この時点ではリファクタリングできないので、この問題に耐えなければなりません。リファクタリングできれば、各サブクラスを戦略として使用できます。それは問題ありませんが、「メインクラス」と戦略をテストしますが、メインクラスと戦略の統合を壊すリファクタリングは見当たりません。 ps3：抽象クラスをテストすることは「受け入れられる」という回答をいくつか見つけました。これは受け入れられることに同意しますが、この場合にどちらが好ましいアプローチであるかを知りたいと思います（私はまだ単体テストから始めています）

12 java  unit-testing  testing 

私はかなり大規模なアジャイルチームのソフトウェア開発者です（8人の開発者が1つのコードリポジトリに積極的に変更を加えています）。2週間ごとに、ソフトウェアの新しいバージョンを運用環境にプッシュします。現在のワークフローは次のとおりです。 新しいタスクを開始するとき、開発者はメインの開発ブランチ（gitを使用）から「機能ブランチ」を作成し、この新しいブランチで作業します 開発者がタスクの作業を完了すると、機能ブランチを開発ブランチにマージして戻します 開発者は、開発ブランチをQAブランチにマージします。 QAブランチからビルドがトリガーされます。このビルドの出力はQA環境に展開され、テスターがテストを開始できるようにします。 テスターがQAブランチにマージされたこれらの新機能の問題を見つけることは非常に一般的です。これは、常に、QA環境にいくつかの新しい機能が含まれていることを意味します-テスト済みでバグのないもの、壊れたものなど。QAビルドが実稼働対応状態になることはまれなので、これによりリリースが困難になります。 これを軽減するために、開発者がリリースの数日前に開発ブランチをQAブランチにマージしないことを意味する「QAフリーズ」を開始しようとしました。QA環境のバグ修正はQAブランチで直接行われ、開発ブランチにマージされます。理論的には、これによりQAの新しい壊れた機能が排除され、QAで既に発生している問題を修正できます。 この「QAフリーズ」の概念は部分的には成功していますが、調整が難しく、QAへのマージが許可されているかどうかについて人々はしばしば混乱します。また、「QAフリーズ」の期限を設定することは困難でした。誰もがフリーズとリリースの間に息を吹き込む部屋のアイデアを好みますが、実際には、デッドラインを尊重するよりも次のリリースで機能を持ちます。 1週間おきにリリースのクリーンビルドを確保するより良い方法はありますか？

12 agile  version-control  development-process  branching  release-management 

Rustでの非同期IOの実装に関するこの講演を見ていましたが、Carlは2つの潜在的なモデルに言及しています。準備と完了。 準備モデル： ソケットから読み取ることをカーネルに指示します しばらく他のことをする… カーネルは、ソケットの準備ができたときに通知します あなたが読む（バッファを埋める） 必要なことは何でもしてください バッファーを解放します（Rustで自動的に発生します） 完了モデル： カーネルが満たすようにバッファを割り当てます しばらく他のことをする… カーネルは、バッファがいっぱいになると通知します データで必要なことを何でもする バッファを解放する レディネスモデルを使用するCarlの例では、使用可能なメモリを反復処理して、グローバルバッファを埋め、解放することで、メモリの使用量を大幅に減らすことができます。 今私の仮定： ソケットが「準備完了」であると言われる内部（カーネル空間内）では、データは既に存在します。ネットワーク経由で（またはどこからでも）ソケットに入り、OSはデータを保持しています。 そのメモリ割り当てがレディネスモデルで魔法のように行われないというわけではありません。OSがそれをあなたから抽象化しているだけです。完了モデルでは、OSは、データが実際に流入する前にメモリを割り当てるように求めており、何が起きているかが明らかです。 準備モデルの修正版は次のとおりです。 ソケットから読み取ることをカーネルに指示します しばらく他のことをする… 修正：データはOSに送られます（カーネルメモリの一部） カーネルは、ソケットの準備ができたことを通知します 読み取ります（上記のカーネルバッファーとは別のバッファーを埋めます（または、ポインターを取得しますか？）） 必要なことは何でもしてください バッファーを解放します（Rustで自動的に発生します） /私の仮定 私はたまたまユーザースペースプログラムを小さく保つのが好きですが、実際にここで何が起こっているのかを明確にしたかったのです。1つのモデルが本質的に少ないメモリを使用したり、より高いレベルの同時IOをサポートしたりすることはありません。私はこれについての考えとより深い説明を聞きたいです。

12 async  io 

GuavaなどのJava 8より前のラムダヘビーライブラリでは、出力は共通のJava Collection Frameworkインターフェイスを使用するため、外部/内部APIに簡単に渡すことができ、ライブラリメソッドがそれを実行する場合（レイジーfilter()およびtransform()）でも遅延計算を利用できます。 ただし、Java 8 Streamsでは、Collection/ を取得する呼び出しMapはターミナル（つまり、熱心）であり、結果を保持するために新しいデータ構造も割り当てます。 中間に複数のステージと戦略パターンがある複雑な計算では、中間結果のために多くの不必要な割り当てが発生します。 だから、人々は内部API（すなわち戦略パターン戦略）がStreams を取得して返すのが良い習慣だと思うのですか、それとも単に怠け者にフォールバックする必要がありますか？ 編集： 私の主な関心事Streamは、それが一度だけ消費され、Supplier<Stream<X>>非常に面倒に見えるようなものを渡すことができるということです。それはほとんどあなただけ渡すためにプッシュしCollection、その後、再stream()それを（その時点での先行評価のコストを支払います）。

12 java  lambda 

強化学習について読むとき、この文に出くわします。たとえば、次の文です。 問題を慎重にモデル化すると、一部の強化学習アルゴリズムがグローバル最適に収束する可能性があります http://reinforcementlearning.ai-depot.com/ またはここ： 固定ポリシーPiの場合、上記のTDアルゴリズムはVPiに収束することが証明されています http://webdocs.cs.ualberta.ca/~sutton/book/ebook/node62.html 収束という言葉の私の理解は、同じポイントにいくつかの事が一緒に来ることを意味するということですが、単一の事（アルゴリズム）がそれをどのようにできるのでしょうか？

12 algorithms  machine-learning 

マイクロサービスが独自の承認を処理する必要がありますか、それともマイクロサービスのすべてまたはサブセット（同じビジネスドメイン内）で共有される個別の承認サービスを使用する方が良いと思いますか？ 私にとって後者は、変更の適用、ポリシーの実施を容易にするため、より理にかなっています。DRYなどです。ただし、あらゆる種類のサービスがルールを1か所にダンプすることで簡単に手に負えなくなる可能性があり、ネットワークのオーバーヘッドも心配します。 何かご意見は？

12 architecture  authorization  microservices 

Golangがここにあるスタイルガイドに最も近いのは、Receiver Namesの下です。 メソッドのレシーバーの名前は、そのアイデンティティを反映したものでなければなりません。多くの場合、そのタイプの1文字または2文字の略語で十分です（「クライアント」の「c」または「cl」など）。「me」、「this」、「self」などの汎用名は使用しないでください。これらは、関数ではなくメソッドに重点を置くオブジェクト指向言語の典型的な識別子です。名前はメソッドの引数のように説明的なものである必要はありません。その役割は明白であり、文書の目的には役立たないからです。 個人的には、「this」が関数の記述および編集時に取り組んでいるものの焦点であるため、常に「this」を識別子として使用しています。それは正しいように聞こえ、（少なくとも私には）理にかなっています。 名前が記述的である必要がない場合、その役割は明白であり、ドキュメンタリーの目的を果たしません。なぜ「これ」の使用が眉をひそめるのでしょうか？

12 coding-style  naming  golang 

私はASP.NET MVCの非同期コントローラーメソッドに関する記事（http://visualstudiomagazine.com/articles/2013/07/23/async-actions-in-aspnet-mvc-4.aspx）を通して取り組んできました。ポイントが足りないかもしれません。 私が書いたこの方法を考えてみましょう。これは、記事の例に非常によく似ています。 [HttpGet] [AsyncTimeout(8000)] [HandleError(ExceptionType = typeof(TimeoutException), View = "TimedOut")] public async Task<ActionResult> Index(CancellationToken cancellationToken) { WidgetPageViewModel model = new WidgetPageViewModel() { toAdd = new Widget() }; model.all = await _repo.GetAllAsync(cancellationToken); return View(model); } 私は物事を理解しているので、これは物事が実行時に展開する方法です： 着信HTTP要求に対してASP.NETスレッドが作成されます。 このスレッドは（おそらく何らかの必要な準備作業を行った上で）上記のIndex（）メソッドに入ります。 実行は「await」キーワードに到達し、別のスレッドでデータ取得プロセスを開始します。 元の「ASP.NET」スレッドは、戻り値としてTaskクラスのインスタンスを使用して、ハンドラーメソッドを呼び出したコードに戻ります。 ハンドラーメソッドを呼び出したインフラストラクチャコードは、実際のActionResultオブジェクトを使用する必要があるポイントに到達するまで（ページのレンダリングなど）、元の "ASP.NET"スレッドで動作し続けます。 次に、呼び出し元はTask.Resultメンバーを使用してこのオブジェクトにアクセスします。これにより、上記の手順3で暗黙的に作成されたスレッドを待機します（つまり、「ASP.NET」スレッド）。 私が些細なことだと思う2つのことを除いて、await / asyncなしで同じことと比較してこれが何を達成するのか見ていません： 呼び出し側スレッドとawaitによって作成されたワーカースレッドは、一定の期間（上記の＃5の「まで」）並行して動作できます。私の考えでは、その期間はかなり短いです。インフラストラクチャがコントローラーメソッドを呼び出す場合、それが（もしあれば）さらに多くのことができるようになる前に、通常はコントローラー呼び出しの実際のActionResultが必要だと考えています。 長時間実行される非同期コントローラー操作のタイムアウトとキャンセルに関連するいくつかの有用な新しいインフラストラクチャがあります。 非同期コントローラーメソッドを追加する目的は、ASP.NETワーカースレッドを解放して、実際にHTTP要求に応答することです。これらのスレッドは有限のリソースです。残念ながら、記事で提案されているパターンが実際にこれらのスレッドを節約するのにどのように役立つかはわかりません。そして、それが何らかの形でリクエストを処理する負担を何らかの非ASP.NETスレッドにオフロードしても、それは何を達成しますか？たまたまHTTP要求を処理できるスレッドは、一般のスレッドとは大きく異なりますか？

12 asp.net-mvc  async 

多くのリソースで、「スコープ」と「名前空間」が同じ意味で使用されていることがわかりました。 スコープは、名前が利用可能なコードの領域を定義します。 LEGBルールは、名前の検索方法を定義します。 名前空間は、名前を検索する場所です。 次に読みました： 「名前は、割り当てられた場所に応じて名前空間にバインドされます...」（レキシカルスコープのスコープを扱うと思います）。 「関数はプログラムに余分な名前空間層を追加します」 [ ref。]（ローカルスコープを追加しませんか？） 「関数定義内で割り当てられたすべての名前は、ローカルスコープ（関数呼び出しに関連付けられた名前空間）に入れられます。」 「グローバルスコープ-つまり、モジュールファイルのトップレベルで作成された（割り当てられた）変数が存在するネームスペース」 *すべての引用は、Python 5th edition ch17の学習からのものです Pythonの名前空間はスコープの実装方法ですか？それらは同じものですか？誰でも私を啓発できますか？

12 python 

インフィックス表記法を使用してメソッドを呼び出すことは可能ですか？ たとえば、Haskellでは、次の関数を作成できます。 x `isAFactorOf` y = x % y == 0 そして次のように使用します： if 2 `isAFactorOf` 10 ... 場合によっては非常に読みやすいコードが可能になります。Scalaでこれに似たものはありますか？「Scala infix notation」を検索しましたが、その用語はScalaでは異なるものを意味するようです。

12 scala 

次の2つのオブジェクト変数があります Date a; Date b=null; 確かに、「a」と「b」の両方がオブジェクトを参照していません。 次のステートメントを呼び出すと System.out.println(a.toString()); コンパイル時エラーが発生しますが、次のステートメントを呼び出すと System.out.println(b.toString()); コンパイル時エラーは発生しませんが、実行時エラーは発生します。この理由と、null値を表すために「b」に実際に格納される値は何ですか？

12 java