SlideShare a Scribd company logo
オブジェクト指向できていますか?
 真のオブジェクト指向が身に付くコーディング規約




    日本工学院八王子専門学校
         大圖 衛玄
CEDEC 2012講演時のスライドです。
http://cedec.cesa.or.jp/2012/program/PG/C12_P0084.html
自己紹介
                         1992年~1997年
                           某ゲーム会社
                           プログラマ
                           SFC,GB,PS1,N64のゲーム開発経験

                         1998年~現在
                           日本工学院八王子専門学校
    @mozmoz1972            専任講師
                           プログラミング教育を中心に担当




twitterもfacebookも実名です。よかったらフォローしてください。
オブジェクト指向
できていますか?
なぜ
オブジェクト指向
できないのか?
手続き型の言語から学習した人がOOPするには大きな発想の転換が必要です。
そのクラスは巨大な1枚岩のコードで作成され・・・(次に続く)
全ての機能が実装されていた・・・(次に続く)
人々はそのクラスを「神クラス」と呼んだ。非OOPなコードの特徴です。
Stage1   Stage2   Stage3   Stage4    Stage5




実際にあった伝説のコード。シンプルな2Dゲームなのに1万行ありました。
調べてみると、ステージごとに、まるごとコピペで作成した神クラスが5つ。
1ゼウス2千行、5ゼウスで、合計1万行となっていました。
理想的な
オブジェクト指向の
  世界とは?
小さな大量のオブジェクトが・・・(次に続く)
お互いメッセージを送りながら協調し複雑なシステムを構築する。(次に続く)
各クラスは、1つの機能に集中し、最小限のインターフェースで構成されています。
コーディング規約で
        理想的な
      オブジェクト指向の
       世界を目指す

本セッションのゴールです。
命名規則やスペースの数、{}位置などのコーディング規約のお話ではありません。
オブジェクト指向
  エクササイズ
        Jeff Bay


ソフトウェア設計を改善する
      9つのステップ
第5章に書かれているJeff Bay氏によるエッセイになります。
読後の衝撃は忘れられません。理想的なオブジェクト指向の姿が理解できました。
Jeff Bayが冒頭で紹介している、7つのコード品質特性です。
Extreme
必然的にオブジェクト指向になってしまう、Extremeなコーディング規約です!
メソッドにつきインデントは1段階

 1つのメソッドごとに制御文を1つに制限
 if、for、whileごとにメソッド化する
 制御文の内側をメソッド化する
 早期リターンを活用しインデントを浅くする



制御文のネストをなくすルールです。小さく、単純なメソッドを作成するのが目的です。
void Class::method() {       void Class::method() {
   for (外側ループ) {                for (外側ループ) {
     for (内側ループ) {                for (内側ループ) {
       if (条件) {                    method1(…);
         処理;                      }
       }                        }
     }                        }
   }
 }                            void Class::method1(…) {
                                if (!条件)
                                  return;
                                処理;
                              }

                     Before                        After

制御分の内側から順番にメソッド化していきます。
void Class::method() {       void Class::method() {
  for (外側ループ) {                for (外側ループ)
    for (内側ループ) {                method2(…);
      method1();             }
    }
  }                          void Class::method2(…) {
}                              for (内側ループ)
                                 method1(…);
                             }




                    Before                        After
void Class::method() {       void Class::method() {
   for (外側ループ) {                for (外側ループ)
     for (内側ループ) {                method2(…);
       if (条件) {              }
         処理;                  void Class::method2(…) {
       }                        for (内側ループ)
     }                            method1(…);
   }                          }
 }                            void Class::method1(…) {
                                if (!条件)
                                  return;
                                処理;
                              }

                     Before                        After

制御文ごとにメソッド化され、ネストが1段階となりました。
for (int i = 0; i < 5; ++i) {
     if (a[i] == num) {
       return true;
     }
   }
   return false;
                                              Before


   return find(&a[0], &a[5], num) != &a[5];




                                               After

検索などのループは、標準の関数を利用しましょう。STLのfindに変更しました。
totalAge    = 0;
  totalSalary = 0;
  for (int i = 0; i < 5; ++i) {
    totalAge    += ages[i];
    totalSalary += salarys[i];
  }
                                     Before


  totalAge = 0;
  for (int i = 0; i < 5; ++i)
    totalAge += ages[i];
  totalSalary = 0
  for (int i = 0; i < 5; ++i)
    totalSalary += salarys[i];           After

ループの内側で2つのことを扱うと、メソッド化が困難です。ループを分割します。
totalAge = 0;
   for (int i = 0; i < 5; ++i)
     totalAge += ages[i];
   totalSalary = 0;
   for (int i = 0; i < 5; ++i)
     totalSalary += salarys[i];
                                                    Before


   totalAge    = accumulate(&ages[0], &ages[5], 0);
   totalSalary = accumulate(&salarys[0], &salarys[5], 0);




                                                     After

配列の合計はSTLのaccumulate関数で求められます。
totalAge    = accumulate(&ages[0], &ages[5], 0);
  totalSalary = accumulate(&salarys[0], &salarys[5], 0);




                                                     Before


 int Class::totalAge() {
   return accumulate(&ages[0], &ages[5], 0);
 }
 int Class::totalSalary() {
   return accumulate(&salarys[0], &salarys[5], 0);
 }                                                    After

さらにメソッド化をしてみました。
totalAge    = 0;
    totalSalary = 0;
    for (int i = 0; i < 5; ++i) {
      totalAge    += ages[i];
      totalSalary += salarys[i];
    }
                                                      Before


  int Class::totalAge() {
    return accumulate(&ages[0], &ages[5], 0);
  }
  int Class::totalSalary() {
    return accumulate(&salarys[0], &salarys[5], 0);
  }                                                    After

Martin Fowlerの「Split Loop」というリファクタング例になります。
else句を使用しないこと

 早期リターンを活用する
 else if、switchの条件分岐を避ける
 Strategy、Stateなどのデザパタを活用
 三項演算子(?)を利用する



条件分岐を単純化するのが目的です。
int method() {                int method() {
   int result;                   if (!条件1)
   if (条件1) {                      return 10;
     if (条件2) {                  if (条件2)
       result = 20;                return 20;
     } else {                    return 30;
       result = 30;            }
     }
   } else {
     result = 10;
   }
   return result;
 }

                      Before                    After

左と右のコードは同等の処理を行います。早期リターンを使うと単純になります。
switch (actorType) {            class Actor {
 case PLAYER:                    public:
                                   virtual void update() = 0;
   updatePlayer();
                                 };
   break;
 case ENEMY:
   updateEnemy();                actor->update();
   break;
 case BULLET:
   updateBullet();
   break;
 }


                        Before                          After

「State/Strategyによるタイプコードの置き換え」というリファクタリングです。
int method() {              int method() {
   int result;                 return 条件 ? 20: 30;
   if (条件)                   }
     result = 20;
   else
     result = 30;
   return result;
 }




                    Before                      After

三項演算子(?)は使いすぎると、わかりにくくなりますが、単純なケースでは有用です。
if (x < 0) {
     x = 0;
   } else if (x > 640) {
     x = 640;
   }

                                            Before


   x = max(0, min(640, x));




                                             After

上記のようなif文は、よく見かけますが、STLのmin,max関数で書き直せます。
if (x < 0) {
     x = 0;
   } else if (x > 640) {
     x = 640;
   }

                                                   Before


   x = clamp(x, 0, 640);

 float clamp(float x, float bottom, float top) {
   return max(bottom, min(top, x));
 }
                                                    After

さらにclampという関数を作ってみます。C++であれば、関数テンプレート化しましょう。
すべてのプリミティブ型をラップ

  int、floatなどの基本型をラップする
  stringなども基本型の扱いとする
  得点、時間などの変数をクラス化する
  すべての状態変数をカプセル化する



すべてをオブジェクト化するのが目的です。intやfloatはオブジェクトではありません。
class Game {                class Game {
 private:                    private:
   int score;                  Score      score;
   int limitTime;              LimitTime time;
 };                          };

                             class Score {
                             private:
                                int score;
                             };
                             class LimitTime {
                             private:
                                int time;
                             };
                    Before                         After

得点や制限時間をクラス化します。「すべてがオブジェクト」になっていきます。
1行につきドットは1つまで

 直接の友人にだけ話かける
 友達の友達とは関連を持たない
 デメテルの法則に従う




余計なクラスとの結合を避けるのが目的となります。
myFriend.getYourFriend().method();




                                        Before




   myFriend.method();




                                         After

「保持しているもの、引数で渡されたもの、自ら作成したもの」だけを扱います。
寿限無、寿限無
 五劫の擦り切れ
 海砂利水魚の
 水行末 雲来末 風来末
 食う寝る処に住む処
 やぶら小路の藪柑子
 パイポパイポ
 パイポのシューリンガン
 シューリンガンのグーリンダイ
 グーリンダイの
 ポンポコピーのポンポコナーの
 長久命の長助

長ったらしい名前を付けなさいという意味ではありません。その逆です!
名前を省略しない

 省略したいほど長い名前がつく原因を考える
 命名困難なクラスやメソッドは要注意
 複数の責務を持っていると命名困難になる
 名前は1つか2つの単語だけ使う



名前が長くなるのは、設計に問題があるのではないか? という意図です。
void Game::updateAndDrawPlayer(Graphics& g) {
   playerPosition += Vector2(5.0f, 0.0f);
   g.drawImage(playerImage, playerPosition);
 }


                                                 Before


 void Game::updatePlayer() {
   playerPosition += Vector2(5.0f, 0.0f);
 }
 void Game::drawPlayer(Graphics& g) {
   g.drawImage(playerImage, playerPosition);
 }                                                After

2つのことを同時にやってしまうと、名前を付けるのが難しくなります。
void Game::updatePlayer() {
   playerPosition += Vector2(5.0f, 0.0f);
 }
 void Game::drawPlayer(Graphics& g) {
   g.drawImage(playerImage, playerPosition);
 }
                                               Before


 void Game::update() {
   player.update();
 }
 void Game::draw(Graphics& graphics) {
   player.draw(graphics);
 }                                              After

メソッドを分割し、さらにクラスの抽出を行いました。名前が単純になりました。
すべてのエンティティを小さくする

 50行を超えるクラスは作らない
 10ファイルを超えるパッケージは作らない
 単一の責務を持つ凝集度の高い設計とする




凝集度を高めれば、クラスやパッケージは小さくできる。という意図になります。
インスタンス変数は2つまで

 クラスは1つの状態変数に責任を持つ
 2つの変数を扱う調整役のクラスもある
 状態変数が増えるたびに凝集度が低下




1つの状態を管理するクラスと、2つの状態を調整する2種類のクラスが存在します。
class Player {            class Player {
 private:                  private:
   float x;                   Vector2 position;
   float y;                   Angle   angle;
   float angle;               Life    life;
   int    life;            };
 };                        class Angle {
                           private:
                              float angle;
                           };
                           class Life {
                           private:
                              int life;
                           };
                  Before                          After

状態変数が2つになるまで、段階的に変更していきます。
class Player {                 class Player {
 private:                       private:
   Vector2 position;              Transform pose;
   Angle   angle;                 Life      life;
   Life    life;                };
 };
                                class Transform {
                                private:
                                   Vector2 position;
                                   Angle   angle;
                                };




                       Before                          After

positionとangleは座標変換を扱うクラスとして、まとめられそうです。
class Player {            class Player {
 private:                  private:
   float x;                  Transform pose;
   float y;                  Life      life;
   float angle;            };
   int    life;
 };




                  Before                       After

状態変数が2つになりました。
class Player {                class Player {
 public:                       public:
   Player(float x,                Player(Transform& pose,
           float y,                      Life& life);
           float angle,         void update(Time& time);
           int   life);        private:
   void update(                   Transform pose;
     float time);                 Life      life;
 private:                      };
   float x;
   float y;
   float angle;
   int    life;
 };
                      Before                         After

右側のクラスは、すべてがオブジェクトと関連しています。抽象度が高くなるわけです。
ファーストクラスコレクション

 vector、listなども基本型としてラップする
 クラスにはコレクションを1つだけ持たせる
 もちろん配列も対象になる




汎用のコレクションクラスもプリミティブ型と同様に扱うという意図です。
class Game {
 private:
    std::list<Actor*>     actors;
    std::list<Particles*> particles;
 };

                                       Before


 class ActorManager {
    std::list<Actor*> actors;
 };
 class ParticleManager {
    std::list<Particle*> particles;
 };                                       After

2つのコレクションを1つのクラスで扱えば、おそらく複雑なクラスになるでしょう。
class Game {
 private:
    std::list<Actor*>     actors;
    std::list<Particles*> particles;
 };

                                       Before


 class Game {
 private:
    ActorManager     actors;
    ParticleMananger particles;
 };
                                        After

専用のクラスを作って、そちらに委譲してしまいます。
Getter Setterを使用しない

  Getter Setterなどのアクセッサを禁止
  極度のカプセル化を行う
  クラス外に振る舞いが漏れ出すのを防止
  「求めるな、命じよ」に従う



Getter/Setterを付けてしまうと、カプセル化が崩壊してしまうという意図です。
構造体
すべてのメンバ変数にGetter/Setterを持たせると、単なる構造体になってしまいます。
void Game::draw(Graphics& g) {
   Vector2 position = player.getPosition();
   Image& image     = player.getImage();
   g.drawImage(image, position);
 }

                                              Before


 void Game::draw(Graphics& g) {
   player.draw(g);
 }
 void Player::draw(Graphics& g) {
   g.drawImage(image, position);
 }                                             After

Getterで「求める」のではなく、オブジェクトに「命じよ」。自分のことは自分でやらせる。
void Game::update() {
   Vector2 position = player.getPosition();
   position += Vetcor2(5.0f, 2.0f);
   player.setPosition(position);
 }

                                              Before


 void Game::update() {
   player.move(Vetcor2(5.0f, 2.0f));
 }



                                               After

振る舞いが外に出てしまっています。オブジェクト自身に行動させます。
振る舞いが外に出てしまうと、コードの重複を生み出す原因になります。
状態は、すべてカプセル化され、メッセージのやりとりだけで、協調して動作する。
#1 1つのメソッドにつきインデントは1段階まで
#2 else句を使用しないこと
#3 すべてのプリミティブ型をラップする
#4 1行につきドットは1つまで
#5 名前を省略しない
#6 すべてのエンティティを小さくする
#7 1つのクラスにつきインスタンス変数は2つまで
#8 ファーストクラスコレクションを使用する
#9 Getter Setterを使用しない
実際にやってみた



エクササイズに挑戦した、ソースコードの解説をしました。(1000行程度のものです)
Jeff Bay




挑戦した人だけが、たどり着ける高みがあるのです。
オブジェクト指向が、いったい何であるかを理解した瞬間をカメラに収めました。
エクササイズまとめ

 騙されたと思って小さなプログラムで試す
 今までとは異なるアプローチが必要になる
 すべてのルールが普遍的に適用できない
 ルールを緩めてガイドラインとして利用する



ルールには、例外も出てきます。ルールの「目的や意図」を理解することが重要です。
Jeff Bay




Jeff Bayのエッセイの結びに書いてあった内容です。(抜粋してあります)
9つのルールに関連する、オブジェクト指向設計の原則を紹介しました。
オブジェクト指向
 設計の原則
 単一責任の原則
 オープン・クローズドの原則
 リスコフの置換原則
 依存関係逆転の原則
 インターフェース分離の原則




「単一責務の原則」と「依存関係逆転の原則」の2つだけ解説します。
単一責任の原則
                      Single Responsibility Principles


                     クラスを変更する理由は
                             1つ以上
                        存在してはならない




ひとつのクラスには1つの責任だけを持たせるという意味です。
凝集度
凝集度とは、1つのクラスがどれだけ、1つのことに集中しているか?ということです。
f1

          f1

          f1               f3     f4

          f1               f3     f4

                           f3     f4

     f2                    f3     f4

          f2

          f2



状態が1つの場合、凝集度は最高に。2つでも全メソッドで使用されれば問題なし。
f1         f2

                      f1

                      f1

                      f1

                 f1        f2

                      f2

                      f2

                      f2



凝集度が低い状態です。明らかに、2つの責務を扱っています。
f1         f2


                      f1

                      f2

                 f1        f2

                      f1

                      f2

                      f2

                      f1




メソッドが大きいと、凝集度が低いのか、高いのか判断できません。(大抵は低いはず)
f1         f2         f1         f2

                                 f1
           f1
                                 f1
           f2
                                 f1
      f1        f2

           f1               f1        f2

           f2                    f2
           f2
                                 f2
           f1
                                 f2



状態変数の振る舞いを観察しながら、細かくメソッド化をしていきます。
f1

     f1         f2             f1
           f1
                               f1
           f1
                               f1
           f1

      f1        f2
                          f2
           f2
                               f2
           f2
                               f2
           f2
                               f2


メソッドをグループ化して、クラスを抽出します。
f1

                                  f1

                                  f1

                                  f1
    o1     o2

     o1    o2
                             f2

                                  f2

                                  f2

                                  f2


抽出後の状態です。凝集度は最高の状態になっています。
大きな関数を多くの小さな関数へ分割する
    ことが、クラスを、より小さなクラスへと
    分割することにつながるのです。

「Clean Code 」からの引用です。メソッド化がクラス化への第1歩になります。
平均的なクラス           理想的なクラス

私見ですが、世の中の平均的なクラスは、大きすぎると思います。
小さな部品を組み合わせながら、複雑なシステムを構築していきます。
再利用可能なクラスとは、ネジのように単純なことを行う小さなクラスなのです。
依存関係逆転の原則
  The Dependency Inversion Principles


 上位のクラスは下位のクラスに
       依存してはならない
   どちらも「抽象」に依存する
疎結合
オブジェクトは、協調しつつも疎結合であることが望まれます。
class Sphere {               class Sphere {
 public:                      public:
   void draw(                   void draw(
     ID3D11Device& g);            ISphereRenderer& g);
 private:                     };
   Vector3 center;
   float radius;              class ISphereRenderer {
 };                           public:
                                virtual void draw(
                                  Vector3 center,
                                  float radius ) = 0;
                              };


                     Before                        After

直接、実装のクラスではなく、抽象インターフェースに依存させます。
void Sphere::draw(       void Sphere::draw(
   ID3D11Device& g) {       ISphereRenderer& g) {
   // 頂点バッファ作成              g.draw(center, radius);
   // インデックスバッファ作成        }
   // 球体の頂点データを計算
   // シェーダー作成
   // 頂点レイアウト作成
   // 描画コンテスト作成
            ・
            ・
            ・
   // なんとか描画する
 }

                 Before                        After

抽象インターフェースに依存させれば、実装の詳細に依存しなくなるわけです。
Sphere.cpp
       Sphere.cpp
                             ISphereRenderer.h




                             SphereRenderer.cpp




        DirectX                   DirectX


                    Before                        After

右図の青い「上向き」の矢印に注目してください。依存関係が逆転しています。
問題領域

                問題領域のクラス



              抽象インターフェース



   実装領域

                    実装クラス



   API
            Windows API, DirectX, OpenGL

問題領域と実装を分離すれば、それぞれのクラスの凝集度を高めることができます。
class ISphereRenderer {      class Sphere {
 public:                      public:
   virtual void draw(            class Renderer {
     Vector3 center,             public:
     float radius) = 0;             virtual void draw(
 };                                   Vector3 center,
                                      float radius) = 0;
 class Sphere {                  };
 public:                         void draw(
   void draw(                       Renderer& g);
     ISphereRenderer& g);     };
 };


                     Before                          After

抽象インターフェースをインナークラス化し完全に自己完結させた例です。(極端か?)
あなたの                          あなたの
    コード                           コード




                                  抽象



                                  実装




  レガシーコード                       レガシーコード

レガシーコードの分離にも役立ちます。不要な複雑さを持ち込まないようしましょう。
インターフェースと実装を分離する
             実装そのものではなく
             インターフェースに対してプログラミングせよ




抽象インターフェースは、多態性だけではなく、依存関係の分離の役割も果たします。
Jeff Bayの9つのルールを参考に作成した、コーディング規約の事例紹介です。
7つのコーディング規約
             お尻は掻いても
             クソース書くな

                          2012年改訂版
学生対象のゲーム制作プロジェクトで実際に採用した規約です。
複雑度
               10
               まで
複雑度とは、McCabeの循環的複雑度を意味します。(ほぼ制御文+1になります)
1メソッド
       20
   ステートメントまで
ステートメントとは実質的なプログラムの行数です。(コメントなどを除きます)
1クラス
   80
ステートメントまで
ネスト
  2
段階まで
setter
             使用禁止

Getterは最小限に、Setterのみ禁止にしました。
フィールド
            4つ
            まで
特に根拠がある数ではありません。フィールド数は、できるかぎり少なくしましょう。
tweet!




        ソースコードを
           愛
          せよ
ネタです。
≒
Jeff Bayのルールに比べれば、「ゆとり」仕様になっていませんか?
コーディング規約の調整

               理想       標準      妥協
  複雑度           5       10       15
  ネスト           1        2        4
  メソッド長         10      20       40
  クラス長          50      80       160



厳しすぎてもユルすぎてもダメです。まずは、無理なく守れる程度がよいと思います。
http://www.slideshare.net/MoriharuOhzu/ss-9224836



昨年のスライドで、コーディング規約の確認の方法や順守させる工夫を紹介しました。
抽象度
クラスやメソッドの行数を制限することにより、全体の抽象度を高める効果があります。
3つの極度
  極度の抽象化
  極度の分離
  極度の読みやすさ




極度の抽象化の考え方は、上記の本でも紹介されています。
まとめ

 コーディング規約の本質を知ることが重要
 例外もあるので、無理やり適用はしない
 ガイドラインとして活用するところから始める
 トレーニングとして研修に取り入れてみる



繰り返しになりますが、ルールの「目的や意図」を理解することが重要です。
クラス設計のポイントです。
小さい
   単純
   重複なし
クラス、メソッドのすべてに、このルールがあてはまります。
http://www.bennadel.com/resources/uploads/2012/ObjectCalisthenics.pdf

英文になりますが、Jeff Bayのオブジェクト指向エクササイズの全文が入手可能です。
http://www.slideshare.net/yojik/ss-1033616



SlideShareで紹介されている、オージス総研の方のスライドです。
http://www.slideshare.net/rdohms/your-code-sucks-lets-fix-it



こちらもSlideShareのスライドです。言語はPHPですが、参考になると思います。
最近では、オブジェクト指向と関数型のハイブリッド言語が注目を浴びています。
タイプの異なる3つの言語を3人の女性に例えました。ちょっと考えてみてください。
オブジェクト指向がすべてではありません。さまざまな言語から異なる発想を学びましょう。
普通のやつらの上を行け
                                 Paul Graham




Paul Grahamのエッセイのタイトルから引用しました。
コードと共に生き続ける
    Moriharu Ohzu

More Related Content

What's hot

テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなテスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
 
プログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコードプログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコード
Shigenori Sagawa
 
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
Koichi Tanaka
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
Akihiro Suda
 
関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり
Kazuyuki TAKASE
 
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するCEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
Yoshifumi Kawai
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
Hajime Yanagawa
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
増田 亨
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMP
Yusuke Kagata
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
Hiroshi Tokumaru
 
Pythonによる黒魔術入門
Pythonによる黒魔術入門Pythonによる黒魔術入門
Pythonによる黒魔術入門
大樹 小倉
 
C# 8.0 非同期ストリーム
C# 8.0 非同期ストリームC# 8.0 非同期ストリーム
C# 8.0 非同期ストリーム
信之 岩永
 
できる!並列・並行プログラミング
できる!並列・並行プログラミングできる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
Yoshitaka Kawashima
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
mosa siru
 
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
Masahito Zembutsu
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説
murachue
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
pospome
 
Rustに触れて私のPythonはどう変わったか
Rustに触れて私のPythonはどう変わったかRustに触れて私のPythonはどう変わったか
Rustに触れて私のPythonはどう変わったか
ShunsukeNakamura17
 

What's hot (20)

テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなテスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
 
プログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコードプログラムの処方箋~健康なコードと病んだコード
プログラムの処方箋~健康なコードと病んだコード
 
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
 
BuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルドBuildKitによる高速でセキュアなイメージビルド
BuildKitによる高速でセキュアなイメージビルド
 
関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり関数型プログラミングのデザインパターンひとめぐり
関数型プログラミングのデザインパターンひとめぐり
 
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭するCEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
CEDEC 2018 最速のC#の書き方 - C#大統一理論へ向けて性能的課題を払拭する
 
モジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェースモジュールの凝集度・結合度・インタフェース
モジュールの凝集度・結合度・インタフェース
 
ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門ドメイン駆動設計のためのオブジェクト指向入門
ドメイン駆動設計のためのオブジェクト指向入門
 
テストコードの DRY と DAMP
テストコードの DRY と DAMPテストコードの DRY と DAMP
テストコードの DRY と DAMP
 
SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021SPAセキュリティ入門~PHP Conference Japan 2021
SPAセキュリティ入門~PHP Conference Japan 2021
 
Pythonによる黒魔術入門
Pythonによる黒魔術入門Pythonによる黒魔術入門
Pythonによる黒魔術入門
 
C# 8.0 非同期ストリーム
C# 8.0 非同期ストリームC# 8.0 非同期ストリーム
C# 8.0 非同期ストリーム
 
できる!並列・並行プログラミング
できる!並列・並行プログラミングできる!並列・並行プログラミング
できる!並列・並行プログラミング
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
 
開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)開発速度が速い #とは(LayerX社内資料)
開発速度が速い #とは(LayerX社内資料)
 
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
 
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
 
目grep入門 +解説
目grep入門 +解説目grep入門 +解説
目grep入門 +解説
 
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考えるGoのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
Goのサーバサイド実装におけるレイヤ設計とレイヤ内実装について考える
 
Rustに触れて私のPythonはどう変わったか
Rustに触れて私のPythonはどう変わったかRustに触れて私のPythonはどう変わったか
Rustに触れて私のPythonはどう変わったか
 

Viewers also liked

良質なコードを高速に書くコツ
良質なコードを高速に書くコツ良質なコードを高速に書くコツ
良質なコードを高速に書くコツ
Shunji Konishi
 
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
Masahiro Nishimi
 
オブジェクト指向やめましょう
オブジェクト指向やめましょうオブジェクト指向やめましょう
オブジェクト指向やめましょうなおき きしだ
 
Your code sucks, let's fix it - DPC UnCon
Your code sucks, let's fix it - DPC UnConYour code sucks, let's fix it - DPC UnCon
Your code sucks, let's fix it - DPC UnCon
Rafael Dohms
 
JavaOne報告2017
JavaOne報告2017JavaOne報告2017
JavaOne報告2017
なおき きしだ
 
Play_using_Proxy
Play_using_ProxyPlay_using_Proxy
Play_using_Proxy
Kunio Miyamoto, Ph.D.
 
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビューソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビューMoriharu Ohzu
 
通常の3倍の速度で プログラミング!? 「 Emacsキーバインドのすすめ」
通常の3倍の速度でプログラミング!?「 Emacsキーバインドのすすめ」通常の3倍の速度でプログラミング!?「 Emacsキーバインドのすすめ」
通常の3倍の速度で プログラミング!? 「 Emacsキーバインドのすすめ」
KinkumaDesign
 
うわ…私のEmacs力、低すぎ...?
うわ…私のEmacs力、低すぎ...?うわ…私のEmacs力、低すぎ...?
うわ…私のEmacs力、低すぎ...?Masahiro Sano
 
エディタじゃない"Emacsの使い方
エディタじゃない"Emacsの使い方エディタじゃない"Emacsの使い方
エディタじゃない"Emacsの使い方
Akihiko Horiuchi
 
クロージャデザインパターン
クロージャデザインパターンクロージャデザインパターン
クロージャデザインパターン
Moriharu Ohzu
 
Vimから見たemacs
Vimから見たemacsVimから見たemacs
Vimから見たemacsShougo
 
チームとプロダクトをぶっ壊した話
チームとプロダクトをぶっ壊した話チームとプロダクトをぶっ壊した話
チームとプロダクトをぶっ壊した話
Taichi Watanabe
 
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
Takafumi ONAKA
 
短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術
Takafumi ONAKA
 
関数型もモナドも分からなくてもScalaと言う言語は便利らしい
関数型もモナドも分からなくてもScalaと言う言語は便利らしい関数型もモナドも分からなくてもScalaと言う言語は便利らしい
関数型もモナドも分からなくてもScalaと言う言語は便利らしいke-m kamekoopa
 
C#アプリの作り方入門
C#アプリの作り方入門C#アプリの作り方入門
C#アプリの作り方入門
森理 麟
 
Cしゃーぷができるまで
CしゃーぷができるまでCしゃーぷができるまで
Cしゃーぷができるまで信之 岩永
 
コードレビューのススメ
コードレビューのススメコードレビューのススメ
コードレビューのススメ
kawahira kazuto
 
設計してますか?
設計してますか?設計してますか?
設計してますか?
ke-m kamekoopa
 

Viewers also liked (20)

良質なコードを高速に書くコツ
良質なコードを高速に書くコツ良質なコードを高速に書くコツ
良質なコードを高速に書くコツ
 
デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣デキるプログラマだけが知っているコードレビュー7つの秘訣
デキるプログラマだけが知っているコードレビュー7つの秘訣
 
オブジェクト指向やめましょう
オブジェクト指向やめましょうオブジェクト指向やめましょう
オブジェクト指向やめましょう
 
Your code sucks, let's fix it - DPC UnCon
Your code sucks, let's fix it - DPC UnConYour code sucks, let's fix it - DPC UnCon
Your code sucks, let's fix it - DPC UnCon
 
JavaOne報告2017
JavaOne報告2017JavaOne報告2017
JavaOne報告2017
 
Play_using_Proxy
Play_using_ProxyPlay_using_Proxy
Play_using_Proxy
 
ソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビューソースコードの品質向上のための効果的で効率的なコードレビュー
ソースコードの品質向上のための効果的で効率的なコードレビュー
 
通常の3倍の速度で プログラミング!? 「 Emacsキーバインドのすすめ」
通常の3倍の速度でプログラミング!?「 Emacsキーバインドのすすめ」通常の3倍の速度でプログラミング!?「 Emacsキーバインドのすすめ」
通常の3倍の速度で プログラミング!? 「 Emacsキーバインドのすすめ」
 
うわ…私のEmacs力、低すぎ...?
うわ…私のEmacs力、低すぎ...?うわ…私のEmacs力、低すぎ...?
うわ…私のEmacs力、低すぎ...?
 
エディタじゃない"Emacsの使い方
エディタじゃない"Emacsの使い方エディタじゃない"Emacsの使い方
エディタじゃない"Emacsの使い方
 
クロージャデザインパターン
クロージャデザインパターンクロージャデザインパターン
クロージャデザインパターン
 
Vimから見たemacs
Vimから見たemacsVimから見たemacs
Vimから見たemacs
 
チームとプロダクトをぶっ壊した話
チームとプロダクトをぶっ壊した話チームとプロダクトをぶっ壊した話
チームとプロダクトをぶっ壊した話
 
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
 
短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術短期間で新技術を学ぶ技術
短期間で新技術を学ぶ技術
 
関数型もモナドも分からなくてもScalaと言う言語は便利らしい
関数型もモナドも分からなくてもScalaと言う言語は便利らしい関数型もモナドも分からなくてもScalaと言う言語は便利らしい
関数型もモナドも分からなくてもScalaと言う言語は便利らしい
 
C#アプリの作り方入門
C#アプリの作り方入門C#アプリの作り方入門
C#アプリの作り方入門
 
Cしゃーぷができるまで
CしゃーぷができるまでCしゃーぷができるまで
Cしゃーぷができるまで
 
コードレビューのススメ
コードレビューのススメコードレビューのススメ
コードレビューのススメ
 
設計してますか?
設計してますか?設計してますか?
設計してますか?
 

Similar to オブジェクト指向できていますか?

Java Puzzlers JJUG CCC 2016
Java Puzzlers JJUG CCC 2016Java Puzzlers JJUG CCC 2016
Java Puzzlers JJUG CCC 2016
Yoshio Terada
 
Replace Output Iterator and Extend Range JP
Replace Output Iterator and Extend Range JPReplace Output Iterator and Extend Range JP
Replace Output Iterator and Extend Range JPAkira Takahashi
 
Clojure programming-chapter-2
Clojure programming-chapter-2Clojure programming-chapter-2
Clojure programming-chapter-2
Masao Kato
 
Xtend30分クッキング やきに駆動
Xtend30分クッキング   やきに駆動Xtend30分クッキング   やきに駆動
Xtend30分クッキング やきに駆動
Shinichi Kozake
 
Javaセキュアコーディングセミナー東京第4回講義
Javaセキュアコーディングセミナー東京第4回講義Javaセキュアコーディングセミナー東京第4回講義
Javaセキュアコーディングセミナー東京第4回講義JPCERT Coordination Center
 
Introduction of Python
Introduction of PythonIntroduction of Python
Introduction of Python
Tomoya Nakayama
 
Xtend30分クッキング
Xtend30分クッキングXtend30分クッキング
Xtend30分クッキング
Shinichi Kozake
 
C#6.0の新機能紹介
C#6.0の新機能紹介C#6.0の新機能紹介
C#6.0の新機能紹介
Kazunori Hamamoto
 
Project lambda
Project lambdaProject lambda
Visual C++で使えるC++11
Visual C++で使えるC++11Visual C++で使えるC++11
Visual C++で使えるC++11
nekko1119
 
D言語会議#1
D言語会議#1D言語会議#1
D言語会議#19rnsr
 
競技プログラミングのためのC++入門
競技プログラミングのためのC++入門競技プログラミングのためのC++入門
競技プログラミングのためのC++入門
natrium11321
 
Kink: invokedynamic on a prototype-based language
Kink: invokedynamic on a prototype-based languageKink: invokedynamic on a prototype-based language
Kink: invokedynamic on a prototype-based languageTaku Miyakawa
 
T69 c++cli ネイティブライブラリラッピング入門
T69 c++cli ネイティブライブラリラッピング入門T69 c++cli ネイティブライブラリラッピング入門
T69 c++cli ネイティブライブラリラッピング入門伸男 伊藤
 
10のJava9で変わるJava8の嫌なとこ!
10のJava9で変わるJava8の嫌なとこ!10のJava9で変わるJava8の嫌なとこ!
10のJava9で変わるJava8の嫌なとこ!
bitter_fox
 
Shibuya JVM Groovy 20150418
Shibuya JVM Groovy 20150418Shibuya JVM Groovy 20150418
Shibuya JVM Groovy 20150418
Uehara Junji
 
【Unity道場スペシャル 2017札幌】乱数完全マスター
【Unity道場スペシャル 2017札幌】乱数完全マスター 【Unity道場スペシャル 2017札幌】乱数完全マスター
【Unity道場スペシャル 2017札幌】乱数完全マスター
Unity Technologies Japan K.K.
 

Similar to オブジェクト指向できていますか? (20)

Processing
ProcessingProcessing
Processing
 
Java Puzzlers JJUG CCC 2016
Java Puzzlers JJUG CCC 2016Java Puzzlers JJUG CCC 2016
Java Puzzlers JJUG CCC 2016
 
Replace Output Iterator and Extend Range JP
Replace Output Iterator and Extend Range JPReplace Output Iterator and Extend Range JP
Replace Output Iterator and Extend Range JP
 
Clojure programming-chapter-2
Clojure programming-chapter-2Clojure programming-chapter-2
Clojure programming-chapter-2
 
Xtend30分クッキング やきに駆動
Xtend30分クッキング   やきに駆動Xtend30分クッキング   やきに駆動
Xtend30分クッキング やきに駆動
 
Javaセキュアコーディングセミナー東京第4回講義
Javaセキュアコーディングセミナー東京第4回講義Javaセキュアコーディングセミナー東京第4回講義
Javaセキュアコーディングセミナー東京第4回講義
 
Introduction of Python
Introduction of PythonIntroduction of Python
Introduction of Python
 
Xtend30分クッキング
Xtend30分クッキングXtend30分クッキング
Xtend30分クッキング
 
C#6.0の新機能紹介
C#6.0の新機能紹介C#6.0の新機能紹介
C#6.0の新機能紹介
 
Gurobi python
Gurobi pythonGurobi python
Gurobi python
 
Project lambda
Project lambdaProject lambda
Project lambda
 
Visual C++で使えるC++11
Visual C++で使えるC++11Visual C++で使えるC++11
Visual C++で使えるC++11
 
D言語会議#1
D言語会議#1D言語会議#1
D言語会議#1
 
競技プログラミングのためのC++入門
競技プログラミングのためのC++入門競技プログラミングのためのC++入門
競技プログラミングのためのC++入門
 
Kink: invokedynamic on a prototype-based language
Kink: invokedynamic on a prototype-based languageKink: invokedynamic on a prototype-based language
Kink: invokedynamic on a prototype-based language
 
T69 c++cli ネイティブライブラリラッピング入門
T69 c++cli ネイティブライブラリラッピング入門T69 c++cli ネイティブライブラリラッピング入門
T69 c++cli ネイティブライブラリラッピング入門
 
10のJava9で変わるJava8の嫌なとこ!
10のJava9で変わるJava8の嫌なとこ!10のJava9で変わるJava8の嫌なとこ!
10のJava9で変わるJava8の嫌なとこ!
 
Bluespec @waseda(PDF)
Bluespec @waseda(PDF)Bluespec @waseda(PDF)
Bluespec @waseda(PDF)
 
Shibuya JVM Groovy 20150418
Shibuya JVM Groovy 20150418Shibuya JVM Groovy 20150418
Shibuya JVM Groovy 20150418
 
【Unity道場スペシャル 2017札幌】乱数完全マスター
【Unity道場スペシャル 2017札幌】乱数完全マスター 【Unity道場スペシャル 2017札幌】乱数完全マスター
【Unity道場スペシャル 2017札幌】乱数完全マスター
 

Recently uploaded

「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
嶋 是一 (Yoshikazu SHIMA)
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
Takayuki Nakayama
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
CRI Japan, Inc.
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
chiefujita1
 
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
Osaka University
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
t m
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
tazaki1
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
harmonylab
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
Matsushita Laboratory
 
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
Toru Tamaki
 

Recently uploaded (10)

「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
 
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
 
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
 

オブジェクト指向できていますか?