جاوا @ تشريحون. اهو ڇا آهي ۽ ڪيئن استعمال ڪجي؟

هي آرٽيڪل انهن ماڻهن لاءِ آهي جن ڪڏهن به تشريح سان ڪم نه ڪيو آهي، پر اهو سمجهڻ چاهيندا ته اهو ڇا آهي ۽ ان سان ڇا استعمال ٿئي ٿو. جيڪڏهن توهان وٽ هن علائقي ۾ تجربو آهي، مان نه ٿو سمجهان ته هي مضمون ڪنهن به طرح توهان جي ڄاڻ کي وڌائيندو (۽، حقيقت ۾، مان اهڙي مقصد جو تعاقب نٿو ڪريان). انهي سان گڏ، مضمون انهن لاء مناسب ناهي جيڪي صرف جاوا ٻولي سکڻ شروع ڪري رهيا آهن. جيڪڏهن توهان نٿا سمجهو ته Map<> or HashMap<> ڇا آهي يا توهان کي خبر ناهي ته ڪلاس جي تعريف ۾ جامد{ } داخل ٿيڻ جو مطلب ڇا آهي، يا توهان ڪڏهن به غور فڪر سان ڪم نه ڪيو آهي، توهان لاءِ هي مضمون پڙهڻ لاءِ تمام جلدي آهي ۽ سمجھڻ جي ڪوشش ڪريو ته تشريحون ڇا آھن. هي اوزار پاڻ شروعات ڪندڙن جي استعمال لاءِ پيدا نه ڪيو ويو آهي، ڇاڪاڻ ته ان کي ضرورت نه آهي مڪمل طور تي بنيادي سمجھه جي ڪلاسن ۽ شين جي رابطي جي (منهنجي راءِ) (هن پوسٽ اسڪرپٽ جي ضرورت ڏيکارڻ لاءِ تبصرن جي مهرباني). سو اچو ته شروع ڪريون. جاوا ۾ تشريحون ھڪڙي قسم جي ليبل آھن ڪوڊ ۾ جيڪي ھڪڙي فنڪشن/ڪلاس / پيڪيج لاء ميٽا ڊيٽا بيان ڪن ٿيون. مثال طور، سڃاتل @Override تشريح، جنهن مان ظاهر ٿئي ٿو ته اسين والدين طبقي جي هڪ طريقي کي ختم ڪرڻ وارا آهيون. ها، هڪ پاسي، اهو ان کان سواء ممڪن آهي، پر جيڪڏهن والدين وٽ اهو طريقو نه آهي، اتي هڪ امڪان آهي ته اسان ڪوڊ بيڪار لکيو، ڇاڪاڻ ته اهو خاص طريقو ڪڏهن به نه سڏيو ويندو، پر @Override Annotation سان گڏ مرتب ڪندڙ اسان کي ٻڌائيندو ته: "مون کي والدين ۾ اهڙو طريقو نه مليو ... هتي ڪجهه گندي آهي." بهرحال، تشريحون صرف ”معتبريت لاءِ“ جي معنيٰ کان وڌيڪ کڻي سگهن ٿيون: اهي ڪجهه ڊيٽا محفوظ ڪري سگهن ٿيون جيڪي بعد ۾ استعمال ڪيون وينديون.

پهرين، اچو ته معياري لائبريري پاران مهيا ڪيل آسان ترين تشريحون ڏسو.

(تبصرن جي ٻيهر مهرباني، پهرين ۾ مون اهو نه سوچيو ته هن بلاڪ جي ضرورت هئي) پهرين، اچو ته بحث ڪريون ته تشريحون ڇا آهن. انهن مان هر هڪ 2 مکيه گهربل پيٽرولر آهن:

• اسٽوريج جو قسم (رکڻ)؛
• اعتراض جو قسم جنهن تي اهو اشارو ڪيو ويو آهي (ٽارگٽ).

اسٽوريج جو قسم

"اسٽوريج جي قسم" مان اسان جو مطلب آهي اسٽيج جنهن تي اسان جي تشريح ڪلاس جي اندر "بدار" رهي ٿي. هر تشريح ۾ صرف هڪ ئي ممڪن آهي ”ريٽرنشن جا قسم“ بيان ڪيل RetentionPolicy class ۾ :

• SOURCE - تشريح صرف استعمال ڪئي ويندي آهي جڏهن ڪوڊ لکڻ ۽ مرتب ڪندڙ طرفان نظر انداز ڪيو ويندو آهي (يعني، ان کي گڏ ڪرڻ کان پوء محفوظ نه ڪيو ويو آهي). عام طور تي ڪنهن به اڳوڻن پروسيسرز لاءِ استعمال ڪيو ويندو آهي (مشروط طور تي)، يا ڪمپلر ڏانهن هدايتون
• CLASS - تشريح تاليف ڪرڻ کان پوءِ محفوظ ڪئي وئي آھي، پر JVM پاران نظر انداز ڪيو ويو آھي (يعني رن ٽائم تي استعمال نٿو ڪري سگھجي). عام طور تي ڪنهن به ٽئين پارٽي جي خدمتن لاءِ استعمال ڪيو ويندو آهي جيڪي توهان جي ڪوڊ کي پلگ ان ايپليڪيشن طور لوڊ ڪن ٿيون
• RUNTIME هڪ تشريح آهي جيڪا گڏ ٿيڻ کان پوءِ محفوظ ڪئي وئي آهي ۽ JVM طرفان لوڊ ڪئي وئي آهي (يعني پروگرام جي عمل جي دوران استعمال ٿي سگهي ٿو). ڪوڊ ۾ نشانن جي طور تي استعمال ڪيو ويو جيڪو سڌو سنئون پروگرام جي عمل کي متاثر ڪري ٿو (هڪ مثال هن مضمون ۾ بحث ڪيو ويندو)

اعتراض جو قسم جيڪو مٿي ڄاڻايل آهي

هي وضاحت تقريبا لفظي طور تي ورتو وڃي، ڇاڪاڻ ته ... جاوا ۾، تشريح ڪنهن به شيءِ تي بيان ڪري سگهجي ٿي (فيلڊز، ڪلاسز، افعال، وغيره) ۽ هر تشريح لاءِ اهو اشارو ڪيو ويو آهي ته ان کي ڪهڙي نموني بيان ڪري سگهجي ٿو. ھتي ھتي ڪو ”ھڪڙو شيءِ“ قاعدو ڪونھي؛ ھڪڙو تشريح ھيٺ ڏنل ھر شيءِ جي مٿان بيان ڪري سگھجي ٿي، يا توھان چونڊي سگھوٿا صرف ElementType طبقي جا ضروري عنصر :

• ANNOTATION_TYPE - ٻي تشريح
• CONSTRUCTOR- ڪلاس تعمير ڪندڙ
• FIELD - ڪلاس جو ميدان
• LOCAL_VARIABLE - مقامي متغير
• طريقو - ڪلاس جو طريقو
• PACKAGE - پيڪيج جي تفصيل
• PARAMETER - طريقو پيراميٽر عوامي باطل هيلو (@Annontation String param){}
• TYPE - ڪلاس جي مٿان اشارو ڪيو ويو آهي

مجموعي طور تي، جاوا SE 1.8 جي مطابق، معياري ٻولي لائبريري اسان کي 10 تشريحون مهيا ڪري ٿي. هن آرٽيڪل ۾ اسان انهن مان سڀ کان وڌيڪ عام نظر ڪنداسين (جيڪو انهن سڀني ۾ دلچسپي رکي ٿو؟ Javadoc ۾ ڀليڪار ):

@override

برقرار رکڻ: SOURCE; ھدف: طريقو. هي تشريح ڏيکاري ٿو ته اهو طريقو جنهن تي اهو لکيو ويو آهي، والدين طبقي کان وراثت ۾ آهي. پهرين تشريح جيڪا هر نئين جاوا پروگرامر جي سامهون اچي ٿي جڏهن هڪ IDE استعمال ڪندي جيڪو مسلسل انهن @Override کي دٻائي ٿو. گهڻو ڪري، يوٽيوب جا استاد يا ته سفارش ڪن ٿا: ”ان کي ختم ڪريو ته جيئن اهو مداخلت نه ڪري،“ يا: ”ان کي ڇڏي ڏيو بغير سوچڻ جي اهو اتي ڇو آهي. حقيقت ۾، تشريح مفيد کان وڌيڪ آهي: اهو نه صرف توهان کي سمجهڻ جي اجازت ڏئي ٿو ته هن ڪلاس ۾ پهريون ڀيرو ڪهڙا طريقا بيان ڪيا ويا آهن، ۽ جيڪي والدين اڳ ۾ ئي آهن (جيڪو بلاشبہ توهان جي ڪوڊ جي پڙهڻ جي صلاحيت وڌائي ٿو)، پر هي تشريح پڻ. "خود-چڪ" جي طور تي ڪم ڪري ٿو جيڪو توهان کي غلطي نه ڪيو ويو جڏهن اوورلوڊ ٿيل فنڪشن جي وضاحت ڪئي وئي.

@منسوخ

برقرار رکڻ: رن ٽائم؛ ھدف: CONSTRUCTOR، FIELD، LOCAL_VARIABLE، METHOD، PACKAGE، PARAMETER، TYPE. هي تشريح طريقن، طبقن يا متغيرن جي نشاندهي ڪري ٿي جيڪي "مروچ" آهن ۽ مصنوعات جي مستقبل جي نسخن ۾ هٽائي سگهجن ٿيون. هي تشريح عام طور تي انهن سان ملي ٿي جيڪي ڪنهن به APIs جي دستاويزن کي پڙهندا آهن، يا ساڳي معياري جاوا لائبريري. ڪڏهن ڪڏهن هن تشريح کي نظرانداز ڪيو ويندو آهي ڇاڪاڻ ته ... اهو ڪنهن به غلطي جو سبب ناهي ۽، اصول ۾، پاڻ ۾ زندگي سان گهڻو مداخلت نٿو ڪري. بهرحال، بنيادي پيغام جيڪو هي تشريح کڻي ٿو اهو آهي ”اسان هن فنڪشنلٽي کي لاڳو ڪرڻ لاءِ هڪ وڌيڪ آسان طريقو کڻي آيا آهيون، ان کي استعمال ڪريو، پراڻو استعمال نه ڪريو“ - چڱو، يا ٻيو - ”اسان فنڪشن جو نالو تبديل ڪيو، پر هي ائين آهي، اسان ان کي ورثي لاءِ ڇڏي ڏنو...“ (جيڪو عام طور تي خراب ناهي). مختصر ۾، جيڪڏهن توهان ڏسو @ Deprecated، اهو بهتر آهي ته اهو استعمال نه ڪرڻ جي ڪوشش ڪئي وڃي ته اهو استعمال نه ڪيو وڃي جيستائين اهو بلڪل ضروري نه هجي، ۽ اهو سمجهڻ لاءِ دستاويز کي ٻيهر پڙهڻ جي قابل ٿي سگهي ٿو ته فرسوده عنصر پاران ڪيل ڪم کي هاڻي لاڳو ڪيو ويو آهي. مثال طور، نئين Date().getYear() استعمال ڪرڻ بدران Calendar.getInstance().get(Calendar.YEAR) استعمال ڪرڻ جي صلاح ڏني وئي آهي .

@SuppressWarnings

برقرار رکڻ: SOURCE; ھدف: TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE ھي تشريح ڪمپيلر وارننگن جي ٻاھرين کي غير فعال ڪري ٿي جيڪا ان عنصر جي متعلق آھي جنھن تي اھو بيان ڪيو ويو آھي. ڇا SOURCE تشريح مٿي ڏنل فيلڊ، طريقا، ڪلاس.

@ برقرار رکڻ

برقرار رکڻ: RUNTIME؛ ھدف: ANNOTATION_TYPE؛ هي تشريح بيان ڪري ٿي "اسٽوريج جو قسم" جي تشريح جو مٿي بيان ڪيو ويو آهي. ها، هي تشريح پڻ استعمال ڪئي وئي آهي پاڻ لاءِ... جادو ۽ بس.

@ ٽارگيٽ

برقرار رکڻ: RUNTIME؛ ھدف: ANNOTATION_TYPE؛ هي تشريح بيان ڪري ٿي اعتراض جو قسم جنهن تي اسان ٺاهيل تشريح کي اشارو ڪري سگهجي ٿو. ها، ۽ اهو پنهنجي لاءِ پڻ استعمال ڪيو ويندو آهي، ان کي استعمال ڪريو... منهنجو خيال آهي ته هي اهو آهي جتي اسان جاوا لائبريري جي معياري تشريح جو پنهنجو تعارف مڪمل ڪري سگهون ٿا، ڇاڪاڻ ته باقي تمام گهٽ استعمال ڪيا ويا آهن ۽، جيتوڻيڪ انهن جا پنهنجا فائدا آهن، هر ڪنهن کي انهن سان معاملو ڪرڻو پوندو آهي ۽ مڪمل طور تي غير ضروري آهي. جيڪڏهن توهان چاهيو ٿا ته مان معياري لائبريري مان ڪنهن مخصوص تشريح بابت ڳالهائيان (يا شايد، @NotNull ۽ @Nullable وانگر تشريحون، جيڪي STL ۾ شامل نه آهن)، تبصرن ۾ لکو- يا ته مهربان صارف توهان کي اتي جواب ڏيندا، يا مان جڏهن ڏسندس ته ڪندس. جيڪڏھن گھڻا ماڻھو ڪنھن قسم جي تشريح لاءِ پڇندا، مان ان کي به مضمون ۾ شامل ڪندس.

RUNTIME تشريح جي عملي درخواست

دراصل، مان سمجهان ٿو ته اهو ڪافي نظرياتي چٽو آهي: اچو ته هڪ بوٽ جي مثال کي استعمال ڪندي مشق ڪرڻ لاء اڳتي وڌون. اچو ته چئو ته توهان ڪجهه سماجي نيٽ ورڪ لاء هڪ بوٽ لکڻ چاهيو ٿا. سڀ وڏا نيٽ ورڪ، جهڙوڪ VK، Facebook، Discord، انهن جا پنهنجا API آهن جيڪي توهان کي بوٽ لکڻ جي اجازت ڏين ٿا. انهن ساڳين نيٽ ورڪن لاءِ، اڳ ۾ ئي لکيل لائبريريون آهن APIs سان ڪم ڪرڻ لاءِ، بشمول جاوا ۾. تنهن ڪري، اسان ڪنهن به API يا لائبريري جي ڪم ۾ ڌيان نه ڏينداسين. اسان کي صرف هن مثال ۾ ڄاڻڻ جي ضرورت آهي ته اسان جو بوٽ چيٽ ڏانهن موڪليل پيغامن جو جواب ڏئي سگهي ٿو جنهن ۾ اسان جو بوٽ اصل ۾ واقع آهي. اهو آهي، اچو ته چئو ته اسان وٽ هڪ فنڪشن سان MessageListener ڪلاس آهي:

public class MessageListener
{
    public void onMessageReceived(MessageReceivedEvent event)
    {
    }
}

اهو وصول ٿيل پيغام جي پروسيسنگ لاء ذميوار آهي. اسان سڀني کي MessageReceivedEvent ڪلاس کان گهربل پيغام جي تار آهي (مثال طور، "هيلو" يا "بوٽ، هيلو"). اهو غور ڪرڻ جي قابل آهي: مختلف لائبريرين ۾ انهن طبقن کي مختلف سڏيو ويندو آهي. مون لائبريري استعمال ڪئي Discord لاءِ. ۽ ان ڪري اسان چاهيون ٿا ته بوٽ جو ردعمل ”بوٽ“ سان شروع ٿيندڙ ڪجهه حڪمن تي (ڪاما سان يا بغير - پاڻ لاءِ فيصلو ڪريو: هن سبق جي خاطر، اسان فرض ڪنداسين ته اتي ڪاما نه هجڻ گهرجي). اهو آهي، اسان جي فنڪشن ڪجهه سان شروع ٿيندي جيئن:

public void onMessageReceived(MessageReceivedEvent event)
{
    //Убираем чувствительность к регистру (БоТ, бОт и т.д.)
    String message = event.getMessage().toLowerCase();
    if (message.startsWith("бот"))
    {

    }
}

۽ ھاڻي اسان وٽ ڪيترائي اختيار آھن ھن يا اھو حڪم لاڳو ڪرڻ لاءِ. بلاشڪ، پهرين توهان کي حڪم کي ان جي دليلن کان الڳ ڪرڻ جي ضرورت آهي، اهو آهي، ان کي هڪ صف ۾ ورهايو.

public void onMessageReceived(MessageReceivedEvent event)
{
    //Убираем чувствительность к регистру (БоТ, бОт и т.д.)
    String message = event.getMessage().toLowerCase();
    if (message.startsWith("бот"))
    {
        try
        {
            //получим массив {"Бот", "(команду)", "аргумент1", "аргумент2",... "аргументN"};
            String[] args = message.split(" ");
            //Для удобства уберем "бот" и отделим команду от аргументов
            String command = args[1];
            String[] nArgs = Arrays.copyOfRange(args, 2, args.length);
            //Получor command = "(команда)"; nArgs = {"аргумент1", "аргумент2",..."аргументN"};
            //Данный массив может быть пустым
        }
        catch (ArrayIndexOutOfBoundsException e)
        {
            //Вывод списка команд or Howого-либо messages
            //В случае если просто написать "Бот"
        }
    }
}

ڪو به طريقو ناهي ته اسان ڪوڊ جي هن ٽڪرا کان پاسو ڪري سگهون ٿا، ڇاڪاڻ ته حڪم کي دلائل کان الڳ ڪرڻ هميشه ضروري آهي. پر پوء اسان وٽ ھڪڙو اختيار آھي:

• ڪريو جيڪڏھن (command.equalsIngnoreCase("..."))
• تبديل ڪريو (حڪم)
• پروسيسنگ جو ڪو ٻيو طريقو ڪريو ...
• يا تشريح جي مدد جو رستو اختيار ڪريو.

۽ ھاڻي اسان آخر ۾ پھچي ويا آھيون تذڪرو استعمال ڪرڻ جي عملي حصي تي. اچو ته اسان جي ڪم لاء تشريح ڪوڊ ڏسو (اهو مختلف ٿي سگهي ٿو، يقينا).

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

//Указывает, что наша Аннотация может быть использована
//Во время выполнения через Reflection (нам How раз это нужно).
@Retention(RetentionPolicy.RUNTIME)

//Указывает, что целью нашей Аннотации является метод
//Не класс, не переменная, не поле, а именно метод.
@Target(ElementType.METHOD)
public @interface Command //Описание. Заметим, что перед interface стоит @;
{
    //Команда за которую будет отвечать функция (например "привет");
    String name();

     //Аргументы команды, использоваться будут для вывода списка команд
    String args();

     //Минимальное количество аргументов, сразу присвоor 0 (логично)
    int minArgs() default 0;

    //Описание, тоже для списка
    String desc();

     //Максимальное число аргументов. В целом не обязательно, но тоже можно использовать
    int maxArgs() default Integer.MAX_VALUE;

     //Показывать ли команду в списке (вовсе необязательная строка, но мало ли, пригодится!)
    boolean showInHelp() default true;

    //Какие команды будут считаться эквивалентными нашей
    //(Например для "привет", это может быть "Здаров", "Прив" и т.д.)
    //Под каждый случай заводить функцию - не рационально
    String[] aliases();

}

اهم! هر پيٽرولر کي فنڪشن جي طور تي بيان ڪيو ويو آهي (قوس سان). صرف primitives، String ، Enum استعمال ڪري سگھجن ٿا پيرا ميٽرز طور . توهان List<String> args(); - غلطي. ھاڻي جڏھن اسان تشريح بيان ڪئي آھي، اچو ته ھڪڙو ڪلاس ٺاھيون، ان کي سڏين CommandListener .

public class CommandListener
{
    @Command(name = "привет",
            args = "",
            desc = "Будь культурным, поздоровайся",
            showInHelp = false,
            aliases = {"здаров"})
    public void hello(String[] args)
    {
        //Какой-то функционал, на Ваше усмотрение.
    }

    @Command(name = "пока",
            args = "",
            desc = "",
            aliases = {"удачи"})
    public void bye(String[] args)
    {
         // Функционал
    }

    @Command(name = "помощь",
            args = "",
            desc = "Выводит список команд",
            aliases = {"help", "команды"})
    public void help(String[] args)
    {
        StringBuilder sb = new StringBuilder("Список команд: \n");
        for (Method m : this.getClass().getDeclaredMethods())
        {
            if (m.isAnnotationPresent(Command.class))
            {
                Command com = m.getAnnotation(Command.class);
                if (com.showInHelp()) //Если нужно показывать команду в списке.
                {
                    sb.append("Бот, ")
                       .append(com.name()).append(" ")
                       .append(com.args()).append(" - ")
                       .append(com.desc()).append("\n");
                }
            }
        }
        //Отправка sb.toString();

    }
}

اهو قابل ذڪر آهي ته هڪ ننڍڙي تڪليف: t.c. اسان ھاڻي عالمگيريت لاءِ وڙھي رھيا آھيون، سڀني ڪمن ۾ ھڪڙي ئي فارمل پيرا ميٽرن جي لسٽ ھئڻ گھرجي، تنھنڪري جيڪڏھن ڪمانڊ وٽ ڪو به دليل نه آھي، فنکشن وٽ String[] args parameter ھجڻ گھرجي . اسان هاڻي 3 حڪم بيان ڪيا آهن: هيلو، الوداع، مدد. هاڻي اچو ته اسان جي MessageListener کي تبديل ڪريون انهي سان ڪجهه ڪرڻ لاءِ. ڪم جي سهولت ۽ رفتار لاءِ، اسان فوري طور تي اسان جي حڪمن کي HashMap ۾ ذخيرو ڪنداسين :

public class MessageListner
{
    //Map который хранит How ключ команду
    //А How meaning функцию которая будет обрабатывать команду
    private static final Map<String, Method> COMMANDS = new HashMap<>();

    //Объект класса с командами (по сути нужен нам для рефлексии)
    private static final CommandListener LISTENER = new CommandListener();

    static
    {
       //Берем список всех методов в классе CommandListener
        for (Method m : LISTENER.getClass().getDeclaredMethods())
        {
            //Смотрим, есть ли у метода нужная нам Аннотация @Command
            if (m.isAnnotationPresent(Command.class))
            {
                //Берем an object нашей Аннотации
                Command cmd = m.getAnnotation(Command.class);
                //Кладем в качестве ключа нашей карты параметр name()
                //Определенный у нашей аннотации,
                //m — переменная, хранящая наш метод
                COMMANDS.put(cmd.name(), m);

                //Также заносим каждый элемент aliases
               //Как ключ указывающий на тот же самый метод.
                for (String s : cmd.aliases())
                {
                    COMMANDS.put(s, m);
                }
            }
        }
    }

    public void onMessageReceived(MessageReceivedEvent event)
    {

        String message = event.getMessage().toLowerCase();
        if (message.startsWith("бот"))
        {
            try
            {
                String[] args = message.split(" ");
                String command = args[1];
                String[] nArgs = Arrays.copyOfRange(args, 2, args.length);
                Method m = COMMANDS.get(command);
                if (m == null)
                {
                    //(вывод помощи)
                    return;
                }
                Command com = m.getAnnotation(Command.class);
                if (nArgs.length < com.minArgs())
                {
                    //что-то если аргументов меньше чем нужно
                }
                else if (nArgs.length > com.maxArgs())
                {
                    //что-то если аргументов больше чем нужно
                }
                //Через рефлексию вызываем нашу функцию-обработчик
                //Именно потому что мы всегда передаем nArgs у функции должен быть параметр
                //String[] args — иначе она просто не будет найдена;
                m.invoke(LISTENER, nArgs);
            }
            catch (ArrayIndexOutOfBoundsException e)
            {
                //Вывод списка команд or Howого-либо messages
                //В случае если просто написать "Бот"
            }
        }
    }
}

اهو سڀ ڪجهه آهي جيڪو اسان جي ٽيمن کي ڪم ڪرڻ جي ضرورت آهي. هاڻي نئين ڪمانڊ شامل ڪرڻ ڪا نئين ڳالهه ناهي، جيڪڏهن نئين صورت ناهي، جنهن ۾ دليلن جي تعداد کي ٻيهر ڳڻپ ڪرڻو پوندو، ۽ مدد کي به ٻيهر لکڻو پوندو، ان ۾ نيون لائينون شامل ڪندي. هاڻي، هڪ حڪم شامل ڪرڻ لاء، اسان کي صرف هڪ نئين فنڪشن شامل ڪرڻ جي ضرورت آهي @Command تشريح سان CommandListener ڪلاس ۾ ۽ اهو ئي آهي - ڪمانڊ شامل ڪيو ويو آهي، ڪيسن ۾ ورتو وڃي ٿو، مدد خودڪار طور تي شامل ڪئي وئي آهي. اهو بلڪل ناقابل ترديد آهي ته اهو مسئلو ڪيترن ئي ٻين طريقن سان حل ڪري سگهجي ٿو. ها، هر شيءِ جيڪا تشريح/عڪسن جي مدد سان ٿي سگهي ٿي، سا انهن کان سواءِ ٿي سگهي ٿي، رڳو سوال آهي سهولت، بهتري ۽ ڪوڊ جي سائيز، يقيناً، هڪ تشريح کي چڪ هڻڻ جتي به ٿورو اشارو هجي ته ان کي استعمال ڪرڻ ممڪن ٿيندو. اهو سڀ کان وڌيڪ منطقي اختيار نه آهي، هر شي ۾ توهان کي ڄاڻڻ جي ضرورت آهي جڏهن بند ڪرڻ =). پر جڏهن APIs لکڻ، لائبريريون يا پروگرام جنهن ۾ اهو ممڪن آهي ته ساڳئي قسم کي ٻيهر ورجائي (پر بلڪل ساڳيو نه) ڪوڊ، تشريحون بلاشڪ بهترين حل آهن.