সংক্ষিপ্ত সংস্করণ:
জাভাতে একক-অ্যাসাইনমেন্ট শৈলীর নির্ভরযোগ্যতার সাথে কাজ করার জন্য আপনার (1) কিছু প্রকারের অপরিবর্তনীয়-বন্ধুত্বপূর্ণ অবকাঠামো এবং (2) সংকলক- বা টেল-কল নির্মূলের জন্য রানটাইম-স্তরের সমর্থন প্রয়োজন।
আমরা অনেকগুলি অবকাঠামো লিখতে পারি, এবং স্ট্যাকটি পূরণ না করার চেষ্টা করার জন্য জিনিসগুলি ব্যবস্থা করতে পারি। তবে যতক্ষণ না প্রতিটি কল একটি স্ট্যাক ফ্রেম নেয়, আপনি কতটা পুনরাবৃত্তি করতে পারবেন তার একটি সীমা থাকবে। আপনার পুনরাবৃত্তিগুলি ছোট এবং / অথবা অলস রাখুন এবং আপনার বড় সমস্যা হওয়া উচিত নয়। আপনি যে সমস্যার মধ্যে চলে যাবেন সেগুলির বেশিরভাগটির জন্য একবারে মিলিয়ন ফলাফল ফেরার দরকার নেই। :)
এছাড়াও নোট করুন, যেহেতু প্রোগ্রামটি চলার উপযুক্ত হওয়ার জন্য দৃশ্যমান পরিবর্তনগুলিকে প্রভাবিত করতে পারে তাই আপনি সবকিছু অপরিবর্তনীয় করতে পারবেন না । তবে, আপনি আপনার নিজস্ব সামগ্রীর বিশাল অংশকে অপরিবর্তনীয় রাখতে পারবেন, প্রয়োজনীয় কয়েকটি পরিবর্তনীয় (উদাহরণস্বরূপ) একটি ক্ষুদ্র উপসেটটি কেবলমাত্র কয়েকটি নির্দিষ্ট পয়েন্টে ব্যবহার করতে পারেন যেখানে বিকল্পগুলি খুব কঠোর হবে।
দীর্ঘ সংস্করণ:
সোজা কথায়, একটি জাভা প্রোগ্রাম সম্পূর্ণরূপে চলকগুলি এড়াতে পারে না যদি এটি কিছু করার মতো কিছু করতে চায়। আপনি এগুলি ধারণ করতে পারেন এবং এইভাবে পরিবর্তনকে বিশাল মাত্রায় সীমাবদ্ধ করতে পারেন তবে ভাষা এবং এপিআইয়ের একেবারে নকশা - শেষ পর্যন্ত অন্তর্নিহিত সিস্টেমটি পরিবর্তনের প্রয়োজনের সাথে - সম্পূর্ণ অপরিবর্তনীয়তা অক্ষম করে তোলে।
জাভা শুরু থেকেই একটি অপরিহার্য , অবজেক্ট-ওরিয়েন্টেড ভাষা হিসাবে ডিজাইন করা হয়েছিল ।
- অপরিহার্য ভাষাগুলি প্রায়শই কোনও না কোনও রূপের পরিবর্তনশীল ভেরিয়েবলের উপর নির্ভর করে। তারা পুনরাবৃত্তির উপর পুনরাবৃত্তির পক্ষে থাকে, উদাহরণস্বরূপ, এবং প্রায় সমস্ত পুনরাবৃত্ত গঠন - এমনকি
while (true)এবং for (;;)! - পুনরুক্তি থেকে পুনরাবৃত্তিতে পরিবর্তিত কোথাও পরিবর্তনশীলটির উপর সম্পূর্ণ নির্ভরশীল।
- অবজেক্ট-ওরিয়েন্টেড ভাষাগুলি প্রতিটি প্রোগ্রামকে একে অপরের কাছে বার্তা প্রেরণ করার গ্রাফ হিসাবে প্রায় প্রতিটি প্রোগ্রামের কল্পনা করে, এবং প্রায় সমস্ত ক্ষেত্রেই কোনও কিছুর পরিবর্তন করে সেই বার্তাগুলির প্রতিক্রিয়া জানায়।
এই নকশাগুলির সিদ্ধান্তের শেষ ফলাফলটি হ'ল পরিবর্তিত পরিবর্তনশীল ব্যতীত জাভার কোনও কিছুর রাজ্য পরিবর্তন করার উপায় নেই - এমনকি মুদ্রণের মতো সহজ কিছু "হ্যালো ওয়ার্ল্ড!" স্ক্রিনে একটি আউটপুট স্ট্রিম জড়িত, যার মধ্যে একটি পরিবর্তনীয় বাফারে স্টাইলিং বাইট অন্তর্ভুক্ত ।
সুতরাং, সমস্ত ব্যবহারিক উদ্দেশ্যে, আমরা আমাদের নিজস্ব কোড থেকে ভেরিয়েবলগুলি নিষিদ্ধ করার মধ্যে সীমাবদ্ধ । ঠিক আছে, আমরা কিন্ডা করতে পারি। প্রায়। মূলত আমাদের যা প্রয়োজন তা হ'ল প্রায় সমস্ত পুনরাবৃত্তি পুনরাবৃত্তির সাথে প্রতিস্থাপন করা এবং পরিবর্তিত মান প্রত্যাবর্তনকারী পুনরাবৃত্ত কলগুলির সাথে সমস্ত রূপান্তর। তাই ভালো...
class Ints {
final int value;
final Ints tail;
public Ints(int value, Ints rest) {
this.value = value;
this.tail = rest;
}
public Ints next() { return this.tail; }
public int value() { return this.value; }
}
public Ints take(int count, Ints input) {
if (count == 0 || input == null) return null;
return new Ints(input.value(), take(count - 1, input.next()));
}
public Ints squares_of(Ints input) {
if (input == null) return null;
int i = input.value();
return new Ints(i * i, squares_of(input.next()));
}
মূলত, আমরা একটি লিঙ্কযুক্ত তালিকা তৈরি করি, যেখানে প্রতিটি নোড নিজেই একটি তালিকা। প্রতিটি তালিকার একটি "মাথা" (বর্তমান মান) এবং একটি "লেজ" (অবশিষ্ট সাবলিস্ট) রয়েছে। বেশিরভাগ কার্যকরী ভাষাগুলি এগুলির মতো কিছু করে, কারণ এটি দক্ষ অপরিবর্তনীয়তার পক্ষে খুব উপযুক্ত। একটি "পরবর্তী" অপারেশন কেবল লেজটি ফিরিয়ে দেয়, যা সাধারণত পুনরাবৃত্ত কলগুলির একটি স্ট্যাকের মধ্যে পরবর্তী স্তরে পাস করা হয়।
এখন, এটি এই স্টাফের একটি অত্যন্ত ওভারসিম্প্লিফাইড সংস্করণ। তবে জাভাতে এই পদ্ধতির সাথে কোনও গুরুতর সমস্যা প্রদর্শন করা যথেষ্ট good এই কোডটি বিবেচনা করুন:
public function doStuff() {
final Ints integers = ...somehow assemble list of 20 million ints...;
final Ints result = take(25, squares_of(integers));
...
}
যদিও ফলাফলের জন্য আমাদের কেবল 25 টি ints প্রয়োজন, এটি squares_ofজানে না। এটি প্রতিটি সংখ্যার স্কয়ারটি ফিরিয়ে দিতে চলেছে integers। 20 মিলিয়ন স্তরের গভীর পুনরাবৃত্তি জাভাতে বেশ বড় সমস্যা তৈরি করে।
দেখুন, কার্যকরী ভাষাগুলির মধ্যে আপনি সাধারণত এ জাতীয় উদ্বেগ প্রকাশ করেন, "লেজ কল বিলোপ" নামে একটি বৈশিষ্ট্য রয়েছে। এর অর্থ কী, যখন সংকলকটি কোডটির শেষ কাজটিকে নিজের কল করতে দেখায় (এবং ফাংশনটি অকার্যকর থাকে তবে ফলাফলটি ফেরত দেয়), এটি একটি নতুন সেট আপ না করে বর্তমান কলের স্ট্যাক ফ্রেম ব্যবহার করে এবং পরিবর্তে একটি "জাম্প" করে একটি "কল" (যাতে ব্যবহৃত স্ট্যাক স্পেস স্থির থাকে) of সংক্ষেপে, এটি পূর্বে-পুনরাবৃত্তিকে পুনরাবৃত্তিতে পরিণত করার দিকে প্রায় 90% পথ যায় way এটি স্ট্যাককে উপচে না ফেলে সেই বিলিয়ন ইনটগুলির সাথে কাজ করতে পারে। (এটি অবশেষে স্মৃতিশক্তি থেকে সরে যেতে চাইবে, তবে এক বিলিয়ন ইনটসের তালিকা জড়ো করা আপনাকে 32-বিট সিস্টেমে যাইহোক স্মৃতিশক্তির দিকে জড়িয়ে ফেলবে))
জাভা এটি করে না, বেশিরভাগ ক্ষেত্রে। (এটি সংকলক এবং রানটাইমের উপর নির্ভর করে তবে ওরাকল এর বাস্তবায়ন এটি করে না)) পুনরাবৃত্ত ফাংশনে প্রতিটি কল মেমরির স্ট্যাক ফ্রেমের মূল্য খায়। খুব বেশি ব্যবহার করুন এবং আপনি একটি স্ট্যাক ওভারফ্লো পাবেন। সমস্ত স্ট্যাক উপচে পড়া কিন্তু প্রোগ্রামের মৃত্যুর গ্যারান্টি দেয়। সুতরাং আমরা এটি না করতে হবে তা নিশ্চিত করতে হবে।
একটি আধা-কার্যত ... অলস মূল্যায়ন। আমাদের এখনও স্ট্যাকের সীমাবদ্ধতা রয়েছে তবে সেগুলির সাথে আমাদের আরও নিয়ন্ত্রণের কারণগুলির সাথে যুক্ত হতে পারে। আমাদের কেবল 25 ফিরিয়ে দিতে মিলিয়ন ইনট গণনা করতে হবে না :) :)
সুতরাং আসুন আমাদের কিছু অলস-মূল্যায়নের অবকাঠামো তৈরি করুন। (এই কোডটি কিছুক্ষণ আগে পরীক্ষা করা হয়েছিল, তবে আমি তখন থেকে এটিকে কিছুটা সংশোধন করেছি; ধারণাটি পড়ি, সিনট্যাক্স ত্রুটিগুলি নয় :) :))
// Represents something that can give us instances of OutType.
// We can basically treat this class like a list.
interface Source<OutType> {
public Source<OutType> next();
public OutType value();
}
// Represents an operation that turns an InType into an OutType.
// Note, these can be the same type. We're just flexible like that.
interface Transform<InType, OutType> {
public OutType appliedTo(InType input);
}
// Represents an action (as opposed to a function) that can run on
// every element of a sequence.
abstract class Action<InType> {
abstract void doWith(final InType input);
public void doWithEach(final Source<InType> input) {
if (input == null) return;
doWith(input.value());
doWithEach(input.next());
}
}
// A list of Integers.
class Ints implements Source<Integer> {
final Integer value;
final Ints tail;
public Ints(Integer value, Ints rest) {
this.value = value;
this.tail = rest;
}
public Ints(Source<Integer> input) {
this.value = input.value();
this.tail = new Ints(input.next());
}
public Source<Integer> next() { return this.tail; }
public Integer value() { return this.value; }
public static Ints fromArray(Integer[] input) {
return fromArray(input, 0, input.length);
}
public static Ints fromArray(Integer[] input, int start, int end) {
if (end == start || input == null) return null;
return new Ints(input[start], fromArray(input, start + 1, end));
}
}
// An example of the spiff we get by splitting the "iterator" interface
// off. These ints are effectively generated on the fly, as opposed to
// us having to build a huge list. This saves huge amounts of memory
// and CPU time, for the rather common case where the whole sequence
// isn't needed.
class Range implements Source<Integer> {
final int start, end;
public Range(int start, int end) {
this.start = start;
this.end = end;
}
public Integer value() { return start; }
public Source<Integer> next() {
if (start >= end) return null;
return new Range(start + 1, end);
}
}
// This takes each InType of a sequence and turns it into an OutType.
// This *takes* a Transform, rather than just *implementing* Transform,
// because the transforms applied are likely to be specified inline.
// If we just let people override `value()`, we wouldn't easily know what type
// to return, and returning our own type would lose the transform method.
static class Mapper<InType, OutType> implements Source<OutType> {
private final Source<InType> input;
private final Transform<InType, OutType> transform;
public Mapper(Transform<InType, OutType> transform, Source<InType> input) {
this.transform = transform;
this.input = input;
}
public Source<OutType> next() {
return new Mapper<InType, OutType>(transform, input.next());
}
public OutType value() {
return transform.appliedTo(input.value());
}
}
// ...
public <T> Source<T> take(int count, Source<T> input) {
if (count <= 0 || input == null) return null;
return new Source<T>() {
public T value() { return input.value(); }
public Source<T> next() { return take(count - 1, input.next()); }
};
}
(মনে রাখবেন যে এটি যদি জাভাতে প্রকৃতপক্ষে কার্যকর হয় তবে উপরের মত কিছুটা কোড ইতিমধ্যে এপিআইয়ের অংশ হতে পারে))
এখন, জায়গায় একটি পরিকাঠামো রয়েছে, কোড লিখতে এটি বরং তুচ্ছ, যা পারস্পরিক পরিবর্তনশীলগুলির প্রয়োজন হয় না এবং কম পরিমাণে ইনপুটের জন্য কমপক্ষে স্থিতিশীল।
public Source<Integer> squares_of(Source<Integer> input) {
final Transform<Integer, Integer> square = new Transform<Integer, Integer>() {
public Integer appliedTo(final Integer i) { return i * i; }
};
return new Mapper<>(square, input);
}
public void example() {
final Source<Integer> integers = new Range(0, 1000000000);
// and, as for the author's "bet you can't do this"...
final Source<Integer> squares = take(25, squares_of(integers));
// Just to make sure we got it right :P
final Action<Integer> printAction = new Action<Integer>() {
public void doWith(Integer input) { System.out.println(input); }
};
printAction.doWithEach(squares);
}
এটি বেশিরভাগ ক্ষেত্রেই কাজ করে তবে এটি ওভারফ্লোগুলি স্ট্যাকের জন্য কিছুটা প্রবণ। take2 বিলিয়ন ইন্ট ইনং করার চেষ্টা করুন এবং তাদের উপর কিছু পদক্ষেপ নিন। : পি এটি অবশেষে একটি ব্যতিক্রম ছুঁড়ে ফেলবে, কমপক্ষে +৪+ জিবি র্যাম স্ট্যান্ডার্ড হওয়া পর্যন্ত। সমস্যাটি হ'ল, কোনও প্রোগ্রামের মেমরির পরিমাণ এটির স্ট্যাকের জন্য সংরক্ষিত থাকে that এটি সাধারণত 1 থেকে 8 MiB এর মধ্যে থাকে। (আপনি বড় জন্য অনুরোধ করতে পারেন, কিন্তু এটা যে সব অনেক আপনি কত জন্য অনুরোধ কোন ব্যাপার না - আপনি কল take(1000000000, someInfiniteSequence), আপনি হবে । একটি ব্যতিক্রম পাবেন) সৌভাগ্যবসত, অলস মূল্যায়ন সঙ্গে, দুর্বল স্পট একটি এলাকায় আমরা আরো ভালো করতে পারেন নিয়ন্ত্রণ । আমরা শুধু আমাদের কত যত্ন নিতে হবে take()।
এটি এখনও স্কেলিং আপ প্রচুর সমস্যা হবে, কারণ আমাদের স্ট্যাক ব্যবহার রৈখিকভাবে বৃদ্ধি। প্রতিটি কল একটি উপাদান পরিচালনা করে এবং বাকীটি অন্য কলটিতে চলে। এখন আমি এটি সম্পর্কে চিন্তা করি, যদিও, একটি কৌশল আমরা টানতে পারি যা আমাদের আরও খানিকটা হেডরুম অর্জন করতে পারে: কলগুলির শৃঙ্খলে কল গাছকে পরিণত করুন। এর মতো আরও কিছু বিবেচনা করুন:
public <T> void doSomethingWith(T input) { /* magic happens here */ }
public <T> Source<T> workWith(Source<T> input, int count) {
if (count < 0 || input == null) return null;
if (count == 0) return input;
if (count == 1) {
doSomethingWith(input.value());
return input.next();
}
return (workWith(workWith(input, count/2), count - count/2);
}
workWithমূলত কাজটি দুটি ভাগে বিভক্ত করে এবং প্রতিটি অর্ধেককে অন্য কলটিতে অর্পণ করে। যেহেতু প্রতিটি কল কাজের তালিকার আকার একের চেয়ে অর্ধেক কমিয়ে দেয়, সুতরাং এটি লৈঙ্গিকতার চেয়ে রৈখিকতার চেয়ে স্কেল করা উচিত।
সমস্যাটি হ'ল, এই ফাংশনটি একটি ইনপুট চায় - এবং একটি লিঙ্কযুক্ত তালিকার সাথে দৈর্ঘ্য পেতে পুরো তালিকাটি অনুসরণ করতে হবে। এটি সহজে সমাধান করা যায়, যদিও; কেবল পরোয়া করি না আছে কত এন্ট্রি। :) উপরের কোডটি Integer.MAX_VALUEগণনার মতো কিছু নিয়ে কাজ করবে , যেহেতু নাল কোনওভাবেই প্রক্রিয়াজাতকরণ বন্ধ করে দেয়। গণনাটি বেশিরভাগ সেখানে থাকে তাই আমাদের কাছে একটি শক্ত বেস মামলা রয়েছে। যদি আপনি Integer.MAX_VALUEকোনও তালিকায় এন্ট্রি বেশি রাখার প্রত্যাশা করেন , তবে আপনি workWithতার ফেরতের মানটি পরীক্ষা করতে পারেন - এটি শেষে নালাগুলি হওয়া উচিত। অন্যথায়, পুনরাবৃত্তি।
মনে রাখবেন, এটি যতটা উপাদানকে আপনি বলেছেন তেমন এটি স্পর্শ করে। এটি অলস নয়; এটি অবিলম্বে তার কাজ করে। আপনি এটি কেবল ক্রিয়াকলাপের জন্যই করতে চান - এটি হ'ল জিনিস যাঁর একমাত্র উদ্দেশ্য তালিকার প্রতিটি উপাদানটিতে নিজেকে প্রয়োগ করা। যেহেতু আমি এই মুহূর্তে এটি ভাবছি, আমার কাছে মনে হচ্ছে লিনিয়ারটি রাখলে ক্রমগুলি অনেক কম জটিল হবে; কোনও সমস্যা হওয়া উচিত নয়, যেহেতু সিক্যুয়েন্সগুলি তাদেরকে যেভাবেই কল করে না - তারা কেবল এমন বস্তু তৈরি করে যা তাদের আবার কল করে।