কোনও চিত্র কি ওওপিতে নিজেকে পুনরায় আকার দিতে সক্ষম হবে?


9

আমি একটি অ্যাপ্লিকেশন লিখছি যার একটি Imageসত্তা থাকবে এবং প্রতিটি টাস্কের দায়বদ্ধতার বিষয়ে সিদ্ধান্ত নিতে আমার ইতিমধ্যে সমস্যা হচ্ছে।

প্রথমে আমার Imageক্লাস আছে। এটির একটি পথ, প্রস্থ এবং অন্যান্য বৈশিষ্ট্য রয়েছে।

তারপর আমি একটি নির্মিত ImageRepositoryবর্গ, চিত্র একটি একক এবং পরীক্ষিত পদ্ধতি, যেমন সঙ্গে পুনরুদ্ধারের জন্য: findAllImagesWithoutThumbnail()

তবে এখন আমারও সক্ষম হওয়া দরকার createThumbnail()। কে মোকাবেলা করা উচিত? আমি একটি ImageManagerক্লাস থাকার কথা ভাবছিলাম , যা একটি অ্যাপ্লিকেশন-নির্দিষ্ট শ্রেণি হবে (সেখানে একটি তৃতীয় পক্ষের চিত্রের ম্যানিপুলেশন পছন্দের পুনঃব্যবহারযোগ্য উপাদানও থাকবে, আমি চক্রটি পুনরায় উদ্ভাবন করছি না)।

অথবা এটি আবার Imageআকার পরিবর্তন করতে 0K হবে ? অথবা দিন ImageRepositoryএবং ImageManagerএকই শ্রেণীতে হবে?

আপনি কি মনে করেন?


চিত্র এ পর্যন্ত কী করে?
উইনস্টন ইওয়ার্ট

আপনি কীভাবে চিত্রগুলির আকার পরিবর্তন করবেন? আপনি কি কেবল চিত্রগুলি সঙ্কুচিত করছেন বা পুরো আকারে ফিরে যেতে ইচ্ছে করতে পারেন?
রোবট

@ উইনস্টোনওয়ার্ট এটি ফর্ম্যাট রেজোলিউশন (যেমন: স্ট্রিং '1440x900'), বিভিন্ন ইউআরএলের মতো ডেটা উত্পন্ন করে এবং আপনাকে 'ভিউ' বা 'ভোট' এর মতো কিছু পরিসংখ্যান সংশোধন করতে দেয়।
চকো ডেভেলপার

@ স্টিভেন বার্নাপ আমি মূল চিত্রটি সবচেয়ে গুরুত্বপূর্ণ বিষয় হিসাবে বিবেচনা করি, আমি কেবল দ্রুত ব্রাউজিংয়ের জন্য থাম্বনেইলগুলি ব্যবহার করি বা যদি ব্যবহারকারী তার ডেস্কটপ বা কোনও কিছুর সাথে মানানসই আকার পরিবর্তন করতে চায় তবে তারা পৃথক জিনিস।
চকো ডেভেলপার

আমি চিত্র শ্রেণিকে অপরিবর্তনীয় করে তুলব যাতে আপনি যখন পাশ কাটিয়ে যান তখন আপনাকে ডিফেন্সিয়ালি কপি করতে না হয়।
ড্যান ওয়াটারওয়ার্থ

উত্তর:


8

জিজ্ঞাসা করা প্রশ্নটির সত্যিকারের উত্তর পাওয়া খুব অস্পষ্ট কারণ এটি কীভাবে Imageঅবজেক্টগুলি ব্যবহৃত হতে চলেছে তার উপর নির্ভর করে ।

আপনি যদি কেবলমাত্র একটি আকারে চিত্রটি ব্যবহার করছেন এবং উত্সের চিত্রটি ভুল আকারের কারণে পুনরায় আকার দিচ্ছেন তবে রিডিং কোডটি পুনরায় আকার দেওয়ার চেয়ে ভাল হতে পারে। আপনার createImageপদ্ধতিটি প্রস্থ / উচ্চতা নিতে এবং তারপরে সেই প্রস্থ / উচ্চতায় চিত্রটি পুনরায় আকার দেওয়া হয়েছে।

আপনার যদি একাধিক আকারের প্রয়োজন হয় এবং মেমোরিটি যদি উদ্বেগের বিষয় না হয় তবে চিত্রটি মূলত পড়া হিসাবে প্রদর্শন করার সময় মেমরির মধ্যে রাখা ভাল এবং প্রদর্শনের সময় কোনও আকার পরিবর্তন করা ভাল। এই জাতীয় ক্ষেত্রে, আপনি ব্যবহার করতে পারেন বেশ কয়েকটি ভিন্ন ডিজাইন। ইমেজ widthএবং heightসংশোধন করা উচিত, কিন্তু আপনাকে হয় একটি আছে চাই displayপদ্ধতি যে একটি অবস্থান এবং একটি টার্গেট উচ্চতা / প্রস্থ নেন অথবা আপনি কিছু পদ্ধতি একটি প্রস্থ / উচ্চতা যে একটি বস্তু যে যাই হোক না কেন ডিসপ্লে সিস্টেম আপনি ব্যবহার করছেন ফিরে গ্রহণ করেছে। আমি ব্যবহার করা বেশিরভাগ অঙ্কন এপিআই আপনাকে ড্র করার সময় লক্ষ্য আকার নির্দিষ্ট করতে দেয়।

যদি প্রয়োজনীয়তাগুলি বিভিন্ন মাপের অঙ্কন করার কারণ হিসাবে প্রায়শই পারফরম্যান্সকে উদ্বেগজনক করে তোলে, আপনার কাছে এমন একটি পদ্ধতি থাকতে পারে যা মূলের উপর ভিত্তি করে একটি ভিন্ন আকারের একটি নতুন চিত্র তৈরি করে। বিকল্প হিসাবে আপনার Imageশ্রেণীর ক্যাশে অভ্যন্তরীণভাবে আলাদা আলাদা উপস্থাপনা করা হবে যাতে আপনি প্রথমবার displayথাম্বনেল আকারের সাথে কল করলে এটি পুনরায় আকার দেয় যখন দ্বিতীয়বার কেবল এটি শেষবারের চেয়ে সংরক্ষণ করা ক্যাশেড অনুলিপিটি আঁকবে। এটি আরও মেমরি ব্যবহার করে তবে এটি বিরল যে আপনার কয়েকটি সাধারণ আকারের চেয়ে বেশি হবে।

অন্য বিকল্পটি হ'ল একটি একক Imageশ্রেণি যা বেস চিত্রটি ধরে রাখে এবং সেই শ্রেণিতে এক বা একাধিক উপস্থাপনা থাকে। একটি Imageনিজেই একটি উচ্চতা / প্রস্থ হবে না। পরিবর্তে, এটি ImageRepresentationএকটি উচ্চতা এবং প্রস্থ ছিল একটি দিয়ে শুরু হবে । আপনি এই প্রতিনিধিত্ব আঁকতে চাই। কোনও চিত্রকে "আকার" দিতে, আপনি Imageনির্দিষ্ট উচ্চতা / প্রস্থের মেট্রিক সহ উপস্থাপনের জন্য জিজ্ঞাসা করতে পারেন । এটি এটির পরে মূলটির পাশাপাশি এই নতুন প্রতিনিধিত্বকে অন্তর্ভুক্ত করবে। অতিরিক্ত জটিলতার জন্য মেমোরিতে ঘুরতে ঘুরতে এটি ঠিক আপনাকে নিয়ন্ত্রণ দেয় control

আমি ব্যক্তিগতভাবে ক্লাসগুলিতে অপছন্দ করি যা শব্দটি ধারণ করে Managerকারণ "ম্যানেজার" খুব অস্পষ্ট শব্দ যা ক্লাসটি ঠিক কী করে তা সম্পর্কে আপনাকে সত্যিই বেশি কিছু জানায় না। এটি কি আজীবন অবজেক্ট পরিচালনা করে? এটি কী বাকি অ্যাপ্লিকেশন এবং যে জিনিসটি পরিচালনা করে তার মধ্যে দাঁড়িয়ে আছে?


"এটি চিত্রের অবজেক্টগুলি কীভাবে ব্যবহৃত হবে তার উপর নির্ভর করে depends" এই বিবৃতিটি সত্যই এনক্যাপসুলেশন এবং আলগা সংযোগের ধারণার সাথে সামঞ্জস্যপূর্ণ নয় (যদিও এটি এই ক্ষেত্রে নীতিটি কিছুটা দূরে নিয়ে যেতে পারে)। পার্থক্যের একটি আরও ভাল বিষয় হ'ল এবং চিত্রের রাজ্যে অর্থপূর্ণভাবে আকার রয়েছে কি না।
ক্রিস বাই

দেখে মনে হচ্ছে আপনি কোনও চিত্র সম্পাদনা অ্যাপ্লিকেশন পয়েন্টের কথা বলছেন। সম্পূর্ণরূপে পরিষ্কার নয় ওপি চাইলে না হু?
andho

6

কেবল কয়েকটি প্রয়োজনীয় প্রয়োজনীয়তা রয়েছে তাই জিনিসগুলিকে সহজ রাখুন এবং আপনার যখন প্রয়োজন তখন আপনার নকশাকে উন্নত করুন। আমার ধারণা, বেশিরভাগ রিয়েল-ওয়ার্ল্ডের ক্ষেত্রে ডিজাইনটি শুরু করার মতো কোনও ভুল নেই:

class Image
{
    public Image createThumbnail(int sizeX, int sizeY)
    {
         // ...
         // later delegate the actual resize operation to a separate component
    }
}

আপনার যখন আরও বেশি পরামিতিগুলি পাস করতে হবে তখন জিনিসগুলি ভিন্ন হতে পারে createThumbnail()এবং সেই পরামিতিগুলির নিজস্ব জীবনকাল প্রয়োজন of উদাহরণস্বরূপ, ধরে নেওয়া যাক আপনি কয়েকটি শতাধিক চিত্রের জন্য থাম্বনেইল তৈরি করতে যাচ্ছেন, কিছু নির্দিষ্ট গন্তব্যের আকার, অ্যালগরিদম বা গুণমানের আকার পরিবর্তন করুন। এর অর্থ হ'ল createThumbnailআপনি অন্য ক্লাসে স্থানান্তরিত করতে পারেন, উদাহরণস্বরূপ, কোনও পরিচালক শ্রেণি বা একটি ImageResizerশ্রেণি, যেখানে এই পরামিতিগুলি কনস্ট্রাক্টর দ্বারা পাস করা হয় এবং তাই ImageResizerবস্তুর আজীবন আবদ্ধ থাকে।

আসলে, যখন আমি সত্যিই এটি প্রয়োজন তখন আমি প্রথম পদ্ধতির সাথে এবং রিফ্যাক্টর দিয়ে শুরু করব।


ভাল, আমি যদি একটি পৃথক উপাদানকে কলটি ইতিমধ্যে অর্পণ করছি তবে কেন ImageResizerএটি প্রথম শ্রেণীর একটি শ্রেণির দায়িত্ব হিসাবে তৈরি করবেন না ? দায়িত্বটি নতুন শ্রেণিতে সরিয়ে দেওয়ার পরিবর্তে আপনি কখন কোনও কল অর্পণ করেন?
সানগো

2
@ সাঙ্গো: ২ টি সম্ভাব্য কারণ: (১) - সম্ভবত ইতিমধ্যে বিদ্যমান - পৃথক উপাদানকে অর্পণ করার কোডটি কেবল একটি সাধারণ এক-লাইনার নয়, সম্ভবত 4 থেকে 6 টি কমান্ডের অনুক্রম, সুতরাং এটি সংরক্ষণের জন্য আপনার একটি জায়গা প্রয়োজন । (২) সিনট্যাকটিকাল চিনি / ব্যবহারের সহজতা: এটি লেখার জন্য কেবল খুব সুদর্শন হবে Image thumbnail = img.createThumbnail(x,y)
ডক ব্রাউন

+1 আঃ আমি দেখছি। ব্যাখ্যার জন্য ধন্যবাদ :)
স্যাঙ্গো

4

আমি মনে করি এটি Imageক্লাসের অংশ হতে হবে , কারণ একটি বাহ্যিক শ্রেণিতে পুনর্নির্মাণের জন্য পুনরায় প্রয়োগকারীটির বাস্তবায়ন জানতে হবে Image, যার ফলে এনক্যাপসুলেশন লঙ্ঘন করা হবে। আমি ধরে নিচ্ছি যে Imageএটি একটি বেস ক্লাস, এবং আপনি কংক্রিট চিত্রের ধরণের (পিএনজি, জেপিইজি, এসভিজি, ইত্যাদি) জন্য পৃথক সাবক্লাস ব্যবহার করবেন। অতএব, আপনার হয় হয় একই আকার পরিবর্তনকারী ক্লাস, বা একটি জেনেরিক রেজাইজার থাকতে হবে যা একটি switchবিবৃতি যা বাস্তবায়ন শ্রেণীর উপর ভিত্তি করে আকার পরিবর্তন করে - একটি ক্লাসিক ডিজাইনের গন্ধ।

আপনার দৃষ্টিভঙ্গি Imageইমেজ, এবং উচ্চতা এবং প্রস্থের পরামিতি সম্বলিত একটি সংস্থান গ্রহণ করুন এবং নিজেকে যথাযথভাবে তৈরি করতে পারে এমন একটি পদ্ধতির হতে পারে । তারপরে আকার পরিবর্তন করা মূল উত্স (চিত্রের অভ্যন্তরে ক্যাশেড) এবং নতুন আকারের পরামিতি ব্যবহার করে একটি নতুন অবজেক্ট তৈরি করার মতো সহজ হতে পারে। যেমন foo.createThumbnail()সহজভাবে return new Image(this.source, 250, 250)। ( অবশ্যই, এর Imageকংক্রিট ধরণের হওয়ার সাথে foo)। এটি আপনার চিত্রগুলি পরিবর্তনযোগ্য এবং তাদের বাস্তবায়নগুলি ব্যক্তিগত রাখে।


আমি এই সমাধান মত, কিন্তু আমি বুঝতে পারে না কেন তুমি resizer অভ্যন্তরীণ বাস্তবায়ন জানা প্রয়োজন যে না Image। এটির জন্য প্রয়োজনীয় সমস্ত হ'ল উত্স এবং লক্ষ্য মাত্রা।
চকো ডেভেলপার

যদিও আমি মনে করি বাহ্যিক শ্রেণীর থাকার অর্থবোধ করা হয়নি কারণ এটি অপ্রত্যাশিত হবে, এটির জন্য এনক্যাপসুলেশন লঙ্ঘন করতে হবে না বা পুনরায় আকার দেওয়ার সময় এটির কোনও সুইচ () বিবৃতি নেওয়া দরকার হবে না। শেষ পর্যন্ত কোনও চিত্র কোনও কোনও 2 ডি অ্যারে এবং ইন্টারফেসটি স্বতন্ত্র পিক্সেলগুলি পেতে এবং সেট করতে দেয় যতক্ষণ না আপনি অবশ্যই চিত্রের আকার পরিবর্তন করতে পারবেন।
হোয়াটসামাম

4

আমি জানি যে ওওপি ডেটা এবং আচরণকে একত্রে আবদ্ধ করার বিষয়ে, তবে আমি মনে করি না যে কোনও চিত্রের ক্ষেত্রে এই ক্ষেত্রে পুনরায় আকার দেওয়ার যুক্তি এম্বেড করা ভাল ধারণা, কারণ কোনও চিত্র নিজেকে কীভাবে পুনরায় আকার দেবে তা জানার দরকার নেই একটি ছবি.

একটি থাম্বনেইল আসলে একটি আলাদা চিত্র। সম্ভবত আপনার একটি ডেটাস্ট্রাকচার থাকতে পারে যা কোনও ফটোগ্রাফের সাথে সম্পর্ককে ধরে রাখে এবং এটি থাম্বনেইল (যা উভয়ই চিত্র)।

আমি আমার প্রোগ্রামগুলিকে জিনিসগুলিতে (যেমন চিত্র, ফটোগ্রাফ, থাম্বনেইলস, ইত্যাদি) এবং পরিষেবাদিতে (যেমন ফটোগ্রাফের সংরক্ষণাগার, থাম্বনেইল জেনারেটর ইত্যাদি) বিভক্ত করার চেষ্টা করি। আপনার ডেটা স্ট্রাকচারগুলি সঠিকভাবে পান এবং তারপরে পরিষেবাগুলি সংজ্ঞায়িত করুন যা আপনাকে সেই ডেটা স্ট্রাকচারগুলি তৈরি, হেরফের, রূপান্তর, অবিরাম এবং পুনরুদ্ধার করতে দেয়। সেগুলি সঠিকভাবে তৈরি করা হয়েছে এবং যথাযথভাবে ব্যবহৃত হয়েছে তা নিশ্চিত করার চেয়ে আমি আমার ডেটা স্ট্রাকচারগুলিতে আর কোনও আচরণ রাখি না।

অতএব, না, কোনও থাম্বনেইল কীভাবে তৈরি করা যায় সে সম্পর্কে কোনও যুক্তিতে যুক্তি থাকা উচিত নয়। একটি থাম্বনেইল জেনারেটর পরিষেবা থাকা উচিত যার একটি পদ্ধতি রয়েছে:

Image GenerateThumbnailFrom(Image someImage);

আমার বড় ডেটা স্ট্রাকচারটি দেখতে এরকম হতে পারে:

class Photograph : Image
{
    public Photograph(Image thumbnail)
    {
        if(thumbnail == null) throw new ArgumentNullException("thumbnail");
        this.Thumbnail = thumbnail;
    }

    public Image Thumbnail { get; private set; }
}

অবশ্যই এর অর্থ এই হতে পারে যে আপনি অবজেক্টটি নির্মাণের সময় আপনি যে প্রচেষ্টাটি করতে চান না তা করতে চান, তাই আমি এই ঠিক আছে এর মতো কিছু বিবেচনা করব:

class Photograph : Image
{
    private Image thumbnail = null;
    private readonly Func<Image,Image> generateThumbnail;

    public Photograph(Func<Image,Image> generateThumbnail)
    {
        this.generateThumbnail = generateThumbnail;
    }


    public Image Thumbnail
    {
        get
        {
            if(this.thumbnail == null)
            {
                this.thumbnail = this.generateThumbnail(this);
            }
            return this.thumbnail;
        }
    }
}

... আপনি অলস মূল্যায়ন সহ কোনও ডেটা কাঠামো চান এমন ক্ষেত্রে। (দুঃখিত, আমি আমার নাল চেকগুলি অন্তর্ভুক্ত করি নি এবং আমি এটি থ্রেড-নিরাপদ করে তুলিনি, যা আপনি চাইলে এমন কিছু যা আপনি যদি একটি পরিবর্তনীয় ডেটা কাঠামো নকল করার চেষ্টা করছিলেন)।

আপনি দেখতে পাচ্ছেন যে, এই ক্লাসগুলির কোনওটি কোনও এক ধরণের ফটোগ্রাফারোপোজিটরি দ্বারা নির্মিত হয়েছে, সম্ভবত এটি একটি থাম্বনেল জেনারেটরের রেফারেন্স রয়েছে যা এটি নির্ভরতা ইনজেকশনের মাধ্যমে পেয়েছিল।


আমাকে বলা হয়েছে যে আমার কোনও আচরণ ছাড়াই ক্লাস তৈরি করা উচিত নয়। নিশ্চিত না আপনি যখন 'ডেটা স্ট্রাকচার' বলছেন তখন আপনি ক্লাস বা সি ++ এর কিছু উল্লেখ করছেন (এটি কি এই ভাষা?) আমি জানি এবং ব্যবহার করি কেবলমাত্র ডেটা স্ট্রাকচারগুলি হ'ল আদিম। পরিষেবাগুলি এবং ডিআই অংশটি স্পট রয়েছে, আমি সম্ভবত এটি শেষ করব।
চকো ডেভেলপার

@ চোকো ডেভলপার: পরিস্থিতি অনুসারে মাঝে মাঝে কোনও আচরণ ছাড়াই ক্লাসগুলি দরকারী বা প্রয়োজনীয় হয়। এগুলিকে বলা হয় মান শ্রেণি । সাধারণ ওওপি ক্লাসগুলি কঠোর কোডেড আচরণ সহ ক্লাস। কমপোজেবল ওওপি ক্লাসেও কঠোর কোডেড আচরণ রয়েছে তবে তাদের গঠনের কাঠামোটি একটি সফ্টওয়্যার অ্যাপ্লিকেশন দ্বারা প্রয়োজনীয় অনেকগুলি আচরণের জন্ম দিতে পারে।
রওয়ং

3

আপনি যে একক কার্যকারিতা বাস্তবায়ন করতে চান তা সনাক্ত করে ফেলেছেন, তাই এখন পর্যন্ত আপনি যা সনাক্ত করেছেন তার থেকে কেন আলাদা করা উচিত নয়? এটা কী একক দায়িত্ব নীতি সুপারিশ করবে সমাধান।

এমন একটি IImageResizerইন্টারফেস তৈরি করুন যা আপনাকে একটি চিত্র এবং একটি লক্ষ্য আকারে পাস করতে দেয় এবং যা একটি নতুন চিত্র দেয়। তারপরে সেই ইন্টারফেসটির একটি বাস্তবায়ন তৈরি করুন। চিত্রগুলিকে পুনরায় আকার দেওয়ার অনেকগুলি উপায় রয়েছে, তাই আপনি একের বেশি দিয়ে শেষ করতে পারেন!


প্রসঙ্গত এসআরপি-র জন্য +1, তবে আমি প্রকৃত আকার পরিবর্তন করবো না, যা ইতিমধ্যে তৃতীয় পক্ষের লাইব্রেরিতে উল্লিখিত হয়েছে।
চকো ডেভেলপার

3

আমি পদ্ধতি সম্পর্কে এই তথ্যগুলি ধরে নিয়েছি, যা চিত্রগুলিকে পুনরায় আকার দেয়:

  • এটি অবশ্যই চিত্রের নতুন অনুলিপি ফিরে আসতে হবে। আপনি নিজেই চিত্রটি পরিবর্তন করতে পারবেন না, কারণ এটি অন্যান্য কোডকেও ভেঙে দেবে যা এই চিত্রটির উল্লেখ রয়েছে।
  • এটি চিত্র শ্রেণীর অভ্যন্তরীণ ডেটা অ্যাক্সেস প্রয়োজন নেই। চিত্র ক্লাসগুলিতে সাধারণত সেই ডেটাগুলিতে (বা এর অনুলিপি) সর্বজনীন অ্যাক্সেসের প্রয়োজন।
  • চিত্রের আকার পরিবর্তন জটিল এবং এর জন্য অনেকগুলি পৃথক পরামিতি প্রয়োজন। এমনকি বিভিন্ন আকার পরিবর্তনকারী অ্যালগরিদমের জন্য এমনকি এক্সটেনসিবিলিটি পয়েন্ট। সমস্ত কিছু পাস করার ফলে বড় পদ্ধতির স্বাক্ষর হবে।

এই তথ্যের উপর ভিত্তি করে, আমি বলব যে চিত্র পুনরায় আকার দেওয়ার পদ্ধতিটি ইমেজ শ্রেণীর নিজেই অংশ হওয়ার কোনও কারণ নেই। শ্রেণীর স্থিতিশীল সহায়ক পদ্ধতি হিসাবে এটি প্রয়োগ করা ভাল হবে।


ভাল অনুমান। যদিও এটি স্থিতিশীল পদ্ধতি হওয়া উচিত তা নিশ্চিত নয়, আমি পরীক্ষার জন্য তাদের এড়াতে চেষ্টা করি।
চকো ডেভেলপার

2

একটি চিত্র প্রক্রিয়াকরণ শ্রেণি উপযুক্ত হতে পারে (বা চিত্র পরিচালক হিসাবে আপনি এটি বলেছেন)। আপনার চিত্রটি চিত্র প্রসেসরের একটি ক্রিয়েটথম্বনল পদ্ধতিতে পাস করুন, উদাহরণস্বরূপ, একটি থাম্বনেইল চিত্র পুনরুদ্ধার করতে।

আমি এই রুটটির পরামর্শ দেওয়ার অন্যতম কারণ হ'ল আপনি বলছেন যে আপনি একটি তৃতীয় পক্ষের চিত্র প্রক্রিয়াকরণ গ্রন্থাগার ব্যবহার করছেন। চিত্র শ্রেণীর বাইরে থেকে পুনরায় আকার দেওয়ার কার্যকারিতাটি গ্রহণ করা আপনার পক্ষে কোনও প্ল্যাটফর্ম নির্দিষ্ট বা তৃতীয় পক্ষের কোডকে বিচ্ছিন্ন করা সহজ করে তুলতে পারে। সুতরাং আপনি যদি সমস্ত প্ল্যাটফর্ম / অ্যাপ্লিকেশনগুলিতে আপনার বেস চিত্র ক্লাসটি ব্যবহার করতে পারেন তবে আপনাকে প্ল্যাটফর্ম বা লাইব্রেরি নির্দিষ্ট কোড দিয়ে এটি দূষিত করতে হবে না। এটি সমস্ত চিত্র প্রসেসরে অবস্থিত হতে পারে।


ভাল যুক্তি. এখানকার বেশিরভাগ লোক বুঝতে পারেনি আমি ইতিমধ্যে একটি তৃতীয় পক্ষের লাইব্রেরিতে সবচেয়ে জটিল অংশটি অর্পণ করছি, সম্ভবত আমি যথেষ্ট পরিষ্কার ছিলাম না।
চকো ডেভেলপার

2

মূলত ডক ব্রাউন যেমন বলেছেন:

getAsThumbnail()চিত্র শ্রেণীর জন্য একটি পদ্ধতি তৈরি করুন , তবে এই পদ্ধতিটি কেবল কোনও ImageUtilsশ্রেণীর কাছে কাজটি অর্পণ করা উচিত । সুতরাং এটি কিছু দেখতে হবে:

 class Image{
   // ...
   public Thumbnail getAsThumbnail{
     return ImageUtils.convertToThumbnail(this);
   }
   // ...
 }

এবং

 class ImageUtils{
   // ...
   public static Thumbnail convertToThumbnail(Image i){
     // ...
   }
   // ...
 }

এটি কোডটিকে সহজ-সরল দেখার অনুমতি দেবে। নিম্নলিখিত তুলনা করুন:

Image i = ...
someComponent.setThumbnail(i.getAsThumbnail());

অথবা

Image i = ...
Thumbnail t = ImageUtils.convertToThumbnail(i);
someComponent.setThumbnail(t); 

যদি পরেরটি আপনার পক্ষে ভাল মনে হয় তবে আপনি কোথাও কোথাও এই সহায়ক পদ্ধতি তৈরি করতেও আটকে থাকতে পারেন।


1

আমি মনে করি "ইমেজ ডোমেন" এর মধ্যে আপনার কাছে কেবলমাত্র চিত্র অবজেক্টটি রয়েছে যা স্থাবর ও একঘেয়েমিযুক্ত। আপনি চিত্রটিকে পুনরায় আকারিত সংস্করণের জন্য জিজ্ঞাসা করুন এবং এটি নিজেই একটি আকার পরিবর্তন করেছে। তারপরে আপনি সিদ্ধান্ত নিতে পারেন যে আপনি মূলটি থেকে মুক্তি পেতে চান বা উভয়ই রাখতে চান।

এখন চিত্রটির থাম্বনেল, অবতার ইত্যাদি সংস্করণগুলি সম্পূর্ণরূপে অন্য একটি ডোমেন যা কোনও ব্যবহারকারীকে দিতে কোনও নির্দিষ্ট চিত্রের বিভিন্ন সংস্করণের জন্য ইমেজ ডোমেনকে জিজ্ঞাসা করতে পারে। সাধারণত এই ডোমেনটি এত বিশাল বা জেনেরিকও নয়, তাই আপনি সম্ভবত এটি প্রয়োগের যুক্তিতে রাখতে পারেন।

একটি ছোট স্কেল অ্যাপ্লিকেশনটিতে, আমি পড়ার সময়ে চিত্রগুলি পুনরায় আকার দিতে চাই would উদাহরণস্বরূপ, আমার কাছে অ্যাপাচি পুনর্লিখনের নিয়ম থাকতে পারে যা চিত্র 'http://my.site.com/images/thumbnails/image1.png' চিত্রটি পিএইচপি করার জন্য প্রতিনিধিদের প্রতিনিধিত্ব করতে পারে, যেখানে চিত্র1.png নামটি ব্যবহার করে ফাইলটি পুনরুদ্ধার করা হবে if এবং পুনরায় আকার দিয়েছেন এবং 'থাম্বনেইলস / ইমেজ 1.png' এ সংরক্ষণ করা হয়েছে। তারপরে এই একই চিত্রটির পরবর্তী অনুরোধে, অ্যাপাচি পিএইচপি স্ক্রিপ্ট না চালিয়ে সরাসরি চিত্র পরিবেশন করবে। আপনার অ্যালাইমেজেস উইথআউট থাম্বনেইলসের প্রশ্নটির প্রশ্ন স্বয়ংক্রিয়ভাবে অ্যাপাচি দ্বারা জবাব দেওয়া হবে, যদি না আপনার পরিসংখ্যান করার প্রয়োজন হয়?

বড় আকারের অ্যাপ্লিকেশনটিতে, আমি সমস্ত নতুন চিত্রগুলি একটি পটভূমির কাজটিতে প্রেরণ করতাম, যা চিত্রটির বিভিন্ন সংস্করণ উত্পন্ন করার যত্ন নেয় এবং উপযুক্ত স্থানে এটি সংরক্ষণ করে। আমি একটি সম্পূর্ণ ডোমেন বা ক্লাস তৈরি করতে বিরক্ত করব না কারণ এই ডোমেনটি স্প্যাগেটি এবং খারাপ সসের ভয়াবহ জগাখিচুয়ায় পরিণত হওয়ার খুব কমই সম্ভাবনা।


0

সংক্ষিপ্ত উত্তর:

আমার পুনঃব্যবস্থাপনা এই পদ্ধতিগুলি চিত্রের শ্রেণিতে যুক্ত করছে:

public Image getResizedVersion(int width, int height);
public Image getResizedVersion(double percentage);

চিত্র অবজেক্টটি এখনও অদম্য, এই পদ্ধতিগুলি একটি নতুন চিত্র ফিরিয়ে দেয়।


0

ইতিমধ্যে বেশ কয়েকটি দুর্দান্ত উত্তর রয়েছে, সুতরাং আমি বস্তুগুলি এবং তাদের দায়িত্বগুলি চিহ্নিত করার পিছনে একটি হিউরিস্টিক্স সম্পর্কে কিছুটা ব্যাখ্যা করব।

ওওপি বাস্তব জীবনের চেয়ে পৃথক যে বাস্তব জীবনে বস্তুগুলি প্রায়শই প্যাসিভ থাকে এবং ওওপিতে তারা সক্রিয় থাকে। এবং এটি অবজেক্ট চিন্তার মূল বিষয় । উদাহরণস্বরূপ, বাস্তব জীবনে কে চিত্রের আকার পরিবর্তন করবে? একটি মানব, যা শ্রদ্ধা মধ্যে স্মার্ট। তবে ওওপিতে কোনও মানুষ নেই, তাই পরিবর্তে অবজেক্টগুলি স্মার্ট। ওওপি-তে এই "মানবকেন্দ্রিক" পদ্ধতির প্রয়োগের একটি উপায় হ'ল পরিষেবা শ্রেণিগুলি উদাহরণস্বরূপ, কুখ্যাত Managerশ্রেণিগুলি ব্যবহার করা। সুতরাং অবজেক্টগুলিকে প্যাসিভ ডেটা-স্ট্রাকচার হিসাবে বিবেচনা করা হয়। এটি কোনও ওওপ উপায় নয়।

সুতরাং দুটি বিকল্প আছে। প্রথমটি, একটি পদ্ধতি তৈরি করা Image::createThumbnail(), ইতিমধ্যে বিবেচিত। দ্বিতীয়টি হ'ল একটি ResizedImageক্লাস তৈরি করা । এটি কোনও ডেকরেটার হতে পারে Image(এটি কোনও Imageইন্টারফেস সংরক্ষণ করা উচিত কিনা তা আপনার ডোমেনের উপর নির্ভর করে ) যদিও এর কিছু এনক্যাপসুলেশন সমস্যা দেখা দেয়, কারণ এর ResizedImageকোনও Imageউত্স থাকতে হবে। তবে কোনও Imageএকটি এসআরপি অনুসারে কাজ করে একটি পৃথক ডোমেন অবজেক্টে রেখে বিশদ বিবরণ দিয়ে অভিভূত হবে না।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.