Java Core: تجمع کنترل شده – از جمع کننده تا جمع کننده

با استفاده از جریان API ، جاوا از نسخه 8 یک رویکرد زیبا و کاربردی برای پردازش داده ها داشته است. collect(...) این پل از جریان یک تجمع هدفمند است – خواه در قالب لیست ها ، نقشه ها ، رشته ها یا ساختارهای داده پیچیده تر. تا جاوا 20 ، پردازش توسط نمونه های جمع کننده تنظیم می شد ، که شامل یک تأمین کننده ، یک باتری ، یک ترکیب کننده و اختیاری یک فینال بود. این مدل برای تجمع ساده به خوبی کار می کند ، اما به سرعت به محدوده آن می رسد ، به ویژه در مورد تجمع پیچیده ، با دولت یا مشروط.

Gatherer: کنترل جدید جریان های جاوا

رابط جدید در جاوا 21 ارائه می شود java.util.stream.Gatherer علاوه بر این ، معناشناسی و کنترل روند تجمع به طور قابل توجهی گسترش می یابد. در حالی که یک جمع کننده داده های منفعل را جمع می کند ، یک جمع کننده به طور فعال به عناصر جاری واکنش نشان می دهد – قابل مقایسه با یک مبدل تخصصی در زبانهای برنامه نویسی کاربردی. جمع آوری کنندگان به ویژه در مواردی که یک تجمع رویه ای یا با محوریت دولت ضروری باشد ، مفید هستند ، و همچنین اجازه می دهند عناصر ، فیلتر ، پرش و پایان صریح فرآیند جمعی – و همه اینها در زمینه یک معماری کاربردی ترکیب شود.

معناشناسی جمع کنندگان

بوها Gatherer تحول a را توصیف می کند Stream در نتیجه نوع R با کنترل نزدیک بر روند تجمع. برخلاف جمع کننده ، که به نوعی یک ظرف برای منطق تجمع است ، جمع کننده اجازه می دهد تا یک پردازش وابسته به شرایط ، از جمله امکان پرش از عناصر (قطره) ، علاوه بر این (تزریق) یا پایان پردازش (پایان دهنده) باشد.

برای انجام این کار ، یک جمع کننده مبتنی بر ایده افسردگی است که در متن پردازنده جریان فراخوانده می شود. این سینک هر عنصر ورودی را دریافت می کند ، می تواند به آن واکنش نشان دهد و در نتیجه به طور فعال بر جریان پردازش تأثیر می گذارد. پردازش واقعی از طریق یک کارخانه آداپتور SO -Called شرح داده شده است ، که انتقال بین شرایط تجمع را مدیریت می کند.

چرا یک جمع کننده بیش از یک جمع کننده بهتر است

در حالی که جمع کننده معمولی در درجه اول به عنوان یک ابزار جمع آوری نهایی – یعنی تبدیل عناصر موجود در جریان به یک ساختار هدف مانند لیست ، نقشه یا تجمع – تبدیل می شود – جمع کننده فراتر از این نقش است. این مکانیزم مستقل را ارائه می دهد که هم از نظر معنایی و هم از نظر عملکردی جدید بیان را برای پردازش جریان باز می کند و به عنوان مثال می تواند عناصر جدیدی را که قبلاً وجود نداشتند تغذیه کنند. این امکان را برای معرفی مقادیر اولیه سازی در ابتدای یک جریان یا هدف قرار دادن علائم کنترل مانند هدر و پاورقی به ابتدا یا پایان – بدون نیاز به گسترش مصنوعی جریان داده اصلی باز می کند.

این آزادی طراحی به ویژه هنگام برخورد با شرایط (حالت) کاملاً واضح است. یک جمع کننده می تواند در یک کشور کار کند و این کشور را تحت تأثیر چندین عنصر قرار دهد. این افق های معنایی جدید را باز می کند: به عنوان مثال ، عملیات پنجره می تواند تدوین شود که در آن از یک منطق زمانی یا پی در پی استفاده می شود-مانند تجمع داده ها تا یک نشانگر “پایان” خاص یا خلاصه گروه های عناصر ، که فقط با یک ترتیب خاص یا ساختار محتوا قابل شناسایی است.

حتی ساختارهای پیچیده تصمیم گیری ، مانند موارد مورد نیاز در فرآیندهای تجزیه چند مرحله ای یا هنگامی که درختان تصمیم گیری طی می شوند ، می توانند با ظرافت و اعلامیه توسط جمع کنندگان تحت تأثیر دولت اجرا شوند. این رابط در روح برنامه نویسی عملکردی باقی مانده است: تحول و تجمع به طور جداگانه شرح داده شده است ، اما جمع کننده به شما امکان می دهد تا آن را به روشی متصل کنید که قبلاً فقط از طریق هک های جریان ضروری یا دشوار برای انتظار امکان پذیر بود.

یک مزیت دیگر در تأثیر کنترل شده عناصر گذشته بر رفتار فعلی نهفته است. یک جمع کننده می تواند تصمیم به رد یک عنصر بگیرد زیرا یک عنصر قبلی زمینه خاصی را تعیین کرده است. این توانایی در زمینه حساسیت در زمینه در شرایطی که جریان داده ها از نظر ساختاری “تمیز نیستند” مرتبط هستند – یعنی مطابق با تعریف نیست یا حاوی خطا است. این به عنوان مثال پرونده های ورود به سیستم ، صادرات داده های متناقض یا تجزیه و تحلیل زبان طبیعی اعمال می شود.

یک مثال بتونی: گروه بندی با منطق فیلتر

بگذارید تصور کنیم که ما فقط می خواهیم آن عناصر را از جریان رشته هایی که دارای یک خاصیت خاص هستند ، جمع آوری کنیم و سپس آنها را گروه بندی کنیم – برای مثال ، تمام کلماتی که طولانی تر از پنج شخصیت هستند مطابق نامه اولیه آنها گروه بندی می شوند. این نیاز را می توان با یک جمع کننده تدوین کرد ، اما نیاز به ترکیبی از پردازش اولیه دارد (برای مثال filter(...)) و گروه بندی پایین دست. از طرف دیگر ، با یک جمع کننده ، این فرایند ترکیبی را می توان با ظرافت ، مشروط و در یک مرحله ترسیم کرد:

Gatherer>> gatherer =
    Gatherer.ofSequential(
        () -> new HashMap>(),
        (map, element, downstream) -> {
            if (element.length() > 5) {
                char key = element.charAt(0);
                map.computeIfAbsent(
key, 
k -> new ArrayList()).add(element);
            }
            return true;
        }
    );

در این مثال ، هر عنصر تصمیم می گیرد که آیا به نتیجه می رسد یا خیر. منطق مستقیماً در جمع کننده تعبیه شده است. مقدار بازگشت true سیگنال هایی که باید پردازش ادامه یابد. آیا در عوض شما false بازگشت ، جریان زودرس به پایان می رسد – رفتاری که با جمع کننده های معمولی نمی توان به آن رسید.

ادغام در DID-API

رابط Gatherer بین طرز کار متوالی و موازی تمایز قائل است. تمایز اصلی از روشهای کارخانه ناشی می شود:

Gatherer.ofSequential(...) // Nur sequenziell nutzbar

Gatherer.ofConcurrent(...) // Für parallele Streams geeignet

یکی با ofConcurrent(...) جمع آوری کننده تولید شده ممکن است در جریان های موازی استفاده شود ، اما باید الزامات خاصی را برآورده کند: این باید یک موضوع ایمن باشد یا بر اساس باتری های موضوعی باشد. این تقریباً مطابق با منطق برای جمع کننده های موازی است ، که در آن مدیریت دولت داخلی امکان پردازش همزمان عناصر مختلف در موضوعات مستقل را فراهم می کند.