Haruskah metode utama hanya terdiri dari kreasi objek dan pemanggilan metode?


12

Seorang teman saya mengatakan kepada saya bahwa, praktik terbaik adalah mainmetode yang mengandung kelas harus dinamai Maindan hanya berisi mainmetode. mainMetode juga seharusnya hanya mengurai input, membuat objek lain dan memanggil metode lain. The Mainkelas dan mainmetode tidak harus melakukan apa-apa lagi. Pada dasarnya apa yang dia katakan bahwa mainmetode yang mengandung kelas harus seperti:

public class Main
{
    public static void main(String[] args)
    {
        //parse inputs
        //create other objects
        //call methods
    }
}

Apakah ini praktik terbaik?


6
Apa lagi yang bisa dilakukan?
Pubby

Jawaban:


11

Maksud teman Anda adalah bahwa aplikasi seharusnya hanya di-bootstrap dengan metode utama, dan tidak lebih. Dengan memiliki metode utama di kelasnya sendiri, Anda hanya memperkuat fakta itu dengan menjaganya agar tetap independen dari logika aplikasi apa pun. Peran metode utama adalah mengurai input apa pun dan menginisialisasi aplikasi dengan input tersebut, dan mungkin input lainnya.

public static void main(String[] args){
    new Foo().start(args[0]);
}

Idenya adalah Anda tidak perlu metode utama untuk menginisialisasi Foo. Ini memungkinkan Anda untuk dengan mudah menginisialisasi dan memulai Foodalam konteks lain, berpotensi dengan semantik yang berbeda.

public Foo initSomewhereElse(String arg){
    Foo f = new Foo();
    f.start(arg);
    return f;
}

7

Metode main () adalah kemunduran yang buruk untuk pemrograman prosedural, menyediakan titik masuk ke dalam aplikasi. Upaya dilakukan dalam berbagai bahasa pemrograman untuk merangkumnya, tetapi sifatnya membuat ini sulit (harus bersifat publik dan statis, tetapi harus PERNAH dipanggil dari hal lain dalam program, yang sangat kontradiktif). WPF berhasil (dengan menyembunyikan main () dari Anda jauh di dalam usus proyek aplikasi WPF dan menyediakan "kait" yang dapat dikonfigurasi untuk pemrosesan kustom), seperti halnya Java (dengan cara yang serupa untuk aplikasi Android), tetapi WinForms dan sebagian besar jenis lain dari aplikasi masih membuat Anda berurusan dengan main ().

Jadi, sebagian besar ahli mengatakan bahwa LOC dari fungsi utama () harus serendah mungkin. Ada satu pendekatan (yang menurut saya sedikit berlebihan) di mana fungsi main () memiliki satu baris:

public class Program
{
   private Program(string[] args)
   {
      //parse args and perform basic program setup
   }

   //Reduce the ugliness to the absolute minimum
   public static void main(string[] args)
   {
      new Program(args).Run();  
   }

   private void Run()
   {
      //kick off the driving O-O code for the app; i.e. Application.Run()
   }    
}

Ini sedikit banyak, tetapi saya setuju dengan prinsip dasar; main () harus sesedikit mungkin untuk membuat aplikasi Anda yang berorientasi objek dan didorong ke keadaan "siap".


Saya tidak setuju. Mungkin berguna untuk menelepon maindari konteks lain - misalnya, rekursi.
DeadMG

4
Secara pribadi jika Anda menggunakan metode utama Anda, saya pikir Anda harus memanggil metode lain dan mengulanginya. Hanya dalam konteks yang paling sederhana (aplikasi konsol dengan tingkat kompleksitas / kesulitan pekerjaan rumah) yang dapat diterima untuk memanggil main () dari dalam program Anda, dan saya akan menyebutnya situasi sepele.
KeithS

1

Dalam bahasa yang mendukung fungsi mainhanyalah fungsi biasa sehingga tidak ada yang bisa Anda lakukan selain dari yang Anda katakan. Dan kemudian ada bahasa - bahasa idiot yang membuang fungsi untuk menjadikan semuanya sebagai objek, yang berarti setiap kali Anda menginginkan fungsi, Anda harus membungkusnya dalam kelas yang tidak perlu .

Yah, cukup bertele-tele. Poin yang saya coba buat adalah bahwa Mainitu bukan kelas, tetapi sebuah fungsi dan jadi Anda seharusnya tidak melakukan apa pun selain input parse, membuat objek lain, dan memanggil metode lain karena hanya itu yang dapat dilakukan fungsi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.