"সাধারণ পুরানো ডেটা" ক্লাস ব্যবহার করার কোনও কারণ আছে কি?

Question

লিগ্যাসি কোডে আমি মাঝে মধ্যে এমন ক্লাস দেখতে পাই যা ডেটাগুলির জন্য মোড়ক ছাড়া কিছুই নয়। কিছুটা এইরকম:

class Bottle {
   int height;
   int diameter;
   Cap capType;

   getters/setters, maybe a constructor
}

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

এমন কোনও বিষয় রয়েছে যেখানে এই জাতীয় জিনিসগুলি প্রয়োজনীয় হবে? যদি এটি প্রায়শই ব্যবহৃত হয়, এটি কী নকশাটিকে সন্দেহযুক্ত করে?

Comments

এটি আপনার প্রশ্নের পুরোপুরি উত্তর দেয় না তবে এটি প্রাসঙ্গিক বলে মনে হচ্ছে: stackoverflow.com/questions/36701/struct-like-objects-in-java

— অ্যাডাম লিয়ার

আমি মনে করি আপনি যে শব্দটির সন্ধান করছেন তা হ'ল পিওডি (সমতল পুরাতন ডেটা)।

— গৌরব

এটি স্ট্রাকচার্ড প্রোগ্রামিংয়ের একটি সাধারণ উদাহরণ। অগত্যা খারাপ নয়, কেবলমাত্র ওরিয়েন্টেড নয়।

— কনরাড রুডল্ফ

এটি স্ট্যাক ওভারফ্লোতে থাকা উচিত নয়?

— Muad'Dib

@ Muad'Dib: টেকনিক্যালি, এটি হল প্রোগ্রামারদের সম্পর্কে। আপনি সরল পুরাতন ডেটা স্ট্রাকচার ব্যবহার করেন কিনা তা আপনার সংকলকটি যত্ন করে না। আপনার সিপিইউ সম্ভবত এটি উপভোগ করেছে ("আমি ক্যাশে থেকে সতেজ ডেটার গন্ধ পছন্দ করি" সাজানোর ক্ষেত্রে)। এই লোকেরা যারা ঝুলে থাকে "এটি কি আমার পদ্ধতিটিকে আরও খাঁটি করে তোলে?" প্রশ্ন।

— Shog9

Answer 1

অবশ্যই খারাপ নয় এবং আমার মনে কোনও কোডের গন্ধ নয়। ডেটা পাত্রে একটি বৈধ ওও নাগরিক। কখনও কখনও আপনি সম্পর্কিত তথ্য একসাথে করতে চান ulate এর মতো পদ্ধতি থাকলে অনেক বেশি ভালো

public void DoStuffWithBottle(Bottle b)
{
    // do something that doesn't modify Bottle, so the method doesn't belong
    // on that class
}

চেয়ে

public void DoStuffWithBottle(int bottleHeight, int bottleDiameter, Cap capType)
{
}

ক্লাস ব্যবহার করা আপনাকে ডট স্টাফবিথবটলের প্রতিটি কলারকে সংশোধন না করে বোতলটিতে একটি অতিরিক্ত পরামিতি যুক্ত করতে দেয়। এবং আপনি বোতল সাবক্লাস করতে পারেন এবং প্রয়োজনে আপনার কোডের পঠনযোগ্যতা এবং সংগঠনটি আরও বাড়িয়ে তুলতে পারেন।

এছাড়াও সরল ডেটা অবজেক্টস রয়েছে যা উদাহরণস্বরূপ একটি ডাটাবেস ক্যোয়ারির ফলস্বরূপ ফিরে পাওয়া যায়। আমি বিশ্বাস করি সে ক্ষেত্রে তাদের জন্য শব্দটি হ'ল "ডেটা ট্রান্সফার অবজেক্ট"।

কিছু ভাষায় অন্যান্য বিবেচনাও রয়েছে। উদাহরণস্বরূপ, সি # ক্লাসে এবং স্ট্রাক্টগুলি পৃথকভাবে আচরণ করে, যেহেতু স্ট্রাইকগুলি একটি মান ধরণের এবং শ্রেণিগুলি রেফারেন্স টাইপ।

Comments

নাহ। DoStuffWithএকটি পদ্ধতি থাকা উচিত এরBottle গলি মধ্যে বর্গ (এবং সম্ভবত অপরিবর্তনীয়, অত্যধিক হওয়া উচিত)। আপনি উপরে যা লিখেছেন তা কোনও ওও ভাষার ভাল প্যাটার্ন নয় (যদি না আপনি কোনও উত্তরাধিকারের API এর সাথে ইন্টারফেস করছেন)। এটা তোলে হয় , তবে একটি অ-OO যেমন পণ্য পরিবেশে একটি বৈধ নকশা।

— কনরাড রুডলফ

@ জাভিয়ার: তাহলে জাভাও সেরা উত্তর নয়। জা-র ও-তে জোর দেওয়া অপ্রতিরোধ্য, ভাষা মূলত অন্য কোনও কিছুর পক্ষে ভাল নয়।

— কনরাড রুডলফ

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

— কনরাড রুডলফ

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

— অ্যাডাম লিয়ার

@ কনরাড, আমি একমত নই যে ডু স্টফউইথ বোতল বোতল ক্লাসে যাওয়া উচিত। একটি বোতল কেন নিজের সাথে স্টাফ করতে হয় তা জানতে হবে? doStuffWithBટલ ইঙ্গিত দেয় যে বোতল দিয়ে অন্য কিছু করা হবে। বোতল যদি এটি ছিল, যে আঁট সংযোজন হবে। তবে, বোতল শ্রেণীর যদি একটি (সম্পূর্ণ) পদ্ধতি থাকে তবে তা সম্পূর্ণ উপযুক্ত appropriate

— নেমি

Answer 2

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

এখানে Bottleএকটি ডেটা ক্লাস):

void selectShippingContainer(Bottle bottle) {
    if (bottle.getDiameter() > MAX_DIMENSION || bottle.getHeight() > MAX_DIMENSION ||
            bottle.getCapType() == Cap.FANCY_CAP ) {
        shippingContainer = WOODEN_CRATE;
    } else {
        shippingContainer = CARDBOARD_BOX;
    }
}

এখানে আমরা Bottleকিছু আচরণ দিয়েছি ):

void selectShippingContainer(Bottle bottle) {
    if (bottle.isBiggerThan(MAX_DIMENSION) || bottle.isFragile()) {
        shippingContainer = WOODEN_CRATE;
    } else {
        shippingContainer = CARDBOARD_BOX;
    }
}

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

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

আপনি এই ক্ষেত্রের সাথে ক্লাসে থাকা উচিত এমন কিছু যুক্তি না লিখে কোনও বস্তুর অনেকগুলি ক্ষেত্র খুব কমই ব্যবহার করতে পারবেন of সেই যুক্তিটি কী তা নির্ণয় করুন এবং তারপরে এটি যেখানে যুক্ত তা নিয়ে যান।

Comments

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

— আলব

"পুরানো সি / সি ++ প্রোগ্রামারদের দ্বারা যারা কখনও ওওতে রূপান্তর করেননি"? সি ++ প্রোগ্রামার সাধারণত সাধারণত ওও হয়, কারণ এটি একটি ওও ভাষা, যেমন সি এর পরিবর্তে সি ++ ব্যবহারের সম্পূর্ণ পয়েন্ট

— ন্যাপফ্যালকন

Answer 3

এটি যদি আপনার প্রয়োজনীয় ধরণের জিনিস হয় তবে তা ঠিক আছে তবে দয়া করে দয়া করে এটি পছন্দ করুন

public class Bottle {
    public int height;
    public int diameter;
    public Cap capType;

    public Bottle(int height, int diameter, Cap capType) {
        this.height = height;
        this.diameter = diameter;
        this.capType = capType;
    }
}

পরিবর্তে মত কিছু

public class Bottle {
    private int height;
    private int diameter;
    private Cap capType;

    public Bottle(int height, int diameter, Cap capType) {
        this.height = height;
        this.diameter = diameter;
        this.capType = capType;
    }

    public int getHeight() {
        return height;
    }

    public void setHeight(int height) {
        this.height = height;
    }

    public int getDiameter() {
        return diameter;
    }

    public void setDiameter(int diameter) {
        this.diameter = diameter;
    }

    public Cap getCapType() {
        return capType;
    }

    public void setCapType(Cap capType) {
        this.capType = capType;
    }
}

অনুগ্রহ.

Comments

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

— টমাসের মালিক

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

— জন

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

— জোনাথন

কনস্ট্রাক্টর ব্যবহারের সুবিধাটি হ'ল এটি ক্লাসটিকে স্থাবর করতে সক্ষম করে তোলে। আপনি যদি বহু-থ্রেডযুক্ত কোডটি লিখতে চান তবে এটি প্রয়োজনীয় essential

— ফরটিআরুনার

আমি যখনই সম্ভব ক্ষেত্রগুলিকে চূড়ান্ত করে তুলব। আইএমএইচও আমি ডিফল্টরূপে ক্ষেত্রগুলি চূড়ান্ত হতে পছন্দ করতাম এবং পরিবর্তনীয় ক্ষেত্রগুলির জন্য একটি কীওয়ার্ড রাখতাম। যেমন

— ভেরি

Answer 4

যেমন @ আন্না বলেছিলেন, অবশ্যই মন্দ নয়। আপনি ক্লাসে অপারেশন (পদ্ধতি) স্থাপন করতে পারেন তা নিশ্চিত, তবে আপনি যদি চান তবেই । আপনি না আছে আছে।

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

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

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

এই ধারণাগুলি ভাল জিনিস হিসাবে শেখানো হয়, সাধারণত শিক্ষকরা যারা এই সমস্যাগুলির সাথে মিলিয়ে মিলিয়ন-লাইনের দৈত্য অ্যাপ্লিকেশনগুলির মধ্যে কাজ করতে পারেন নি।

আমি যা করার চেষ্টা করছি তা এখানে:

1. যতটা সম্ভব ডেটা রাখুন যতটা সম্ভব ডেটা রাখুন, যাতে কোনও উপাত্তে পরিবর্তন এলে এটি অসঙ্গত অবস্থায় প্রবেশের সম্ভাবনা হ্রাস করার জন্য যতটা সম্ভব কোড পয়েন্টে সম্পন্ন করা হয়।

2. যখন ডেটা আন-সাধারণ করতে হবে, এবং অতিরিক্ত কাজ অপ্রয়োজনীয় হয়, তখন এটিকে ধারাবাহিক রাখার প্রসঙ্গে বিজ্ঞপ্তিগুলি ব্যবহার করবেন না। বরং সাময়িক অসঙ্গতি সহ্য করুন। কেবলমাত্র এটি করে এমন একটি প্রক্রিয়া দ্বারা ডেটাগুলির মাধ্যমে পর্যায়ক্রমিক ঝোঁকগুলির সাথে অসঙ্গতি সমাধান করুন। বিজ্ঞপ্তিগুলির প্রবণতা রয়েছে এমন পারফরম্যান্স এবং নির্ভুলতা সমস্যাগুলি এড়িয়ে চলাকালীন এটি ধারাবাহিকতা বজায় রাখার জন্য এই দায়িত্বকে কেন্দ্রিয় করে তোলে। কোডের ফলে এটি অনেক ছোট, ত্রুটিমুক্ত এবং দক্ষ।

Answer 5

আপনি মাঝারি আকারে / বড় অ্যাপ্লিকেশনগুলির সাথে ডিল করছেন যখন এই কারণে ক্লাস এই ধরণের বেশ কার্যকর হয়:

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

সুতরাং সংক্ষেপে বলতে গেলে আমার অভিজ্ঞতায় এগুলি সাধারণত বিরক্তির চেয়ে বেশি কার্যকর।

Answer 6

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

Answer 7

আনা লিয়ার সাথে সম্মত হন,

অবশ্যই খারাপ নয় এবং আমার মনে কোনও কোডের গন্ধ নয়। ডেটা পাত্রে একটি বৈধ ওও নাগরিক। কখনও কখনও আপনি সম্পর্কিত তথ্য একসাথে করতে চান ulate এর মতো পদ্ধতি থাকলে অনেক বেশি ভালো ...

কখনও কখনও লোকেরা 1999 এর জাভা কোডিং কনভেনশনগুলি পড়তে ভুলে যায় যা এটিকে খুব স্পষ্ট করে তোলে যে এই ধরণের প্রোগ্রামিং পুরোপুরি ঠিক আছে। আসলে আপনি যদি এড়ানো যান তবে আপনার কোডটি গন্ধ পাবে! (অনেক বেশি গেটার / সেটার)

জাভা কোড কনভেনশনস ১৯৯৯ থেকে: উপযুক্ত পাবলিক ইনস্ট্যান্স ভেরিয়েবলগুলির একটি উদাহরণ হল ক্লাসটি মূলত কোনও ডেটা স্ট্রাকচার, কোনও আচরণ ছাড়াই। অন্য কথায়, আপনি যদি ক্লাসের পরিবর্তে কাঠামো ব্যবহার করতেন (যদি জাভা সমর্থিত কাঠামো), তবে শ্রেণীর উদাহরণটি ভেরিয়েবলগুলি সর্বজনীন করা উপযুক্ত। http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#177

যখন সঠিকভাবে ব্যবহার করা হয়, POs (প্লেইন পুরাতন ডেটা স্ট্রাকচারগুলি) POJO এর চেয়ে ঠিক ভাল যেমন POJOs প্রায়শই EJBs এর চেয়ে ভাল হয়।
http://en.wikipedia.org/wiki/Plain_Old_Data_Structures

Answer 8

এমনকি জাভাতেও স্ট্রাইকগুলির তাদের স্থান রয়েছে। নিম্নলিখিত দুটি জিনিস সত্য হলে আপনার কেবলমাত্র সেগুলি ব্যবহার করা উচিত:

• আপনার কেবলমাত্র সামগ্রিক ডেটা দরকার যাতে কোনও আচরণ নেই, যেমন প্যারামিটার হিসাবে পাস করার জন্য
• সামগ্রিক ডেটাতে কী ধরণের মান রয়েছে তা কিছুটা বিবেচ্য নয়

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

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

আপনার অনুমিত-কাঠামোর আচরণ রয়েছে কিনা তা পরীক্ষা করতে, ক্ষেত্রগুলি কখন ব্যবহৃত হয় তা দেখুন look যদি মনে হয় বলুন, জিজ্ঞাসা করবেন না লঙ্ঘন করেছে , তবে আপনার সেই আচরণটি আপনার শ্রেণিতে স্থানান্তরিত করা দরকার।

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

আপনার বোতল উদাহরণটি সম্ভবত উভয় পরীক্ষায় ব্যর্থ হবে। আপনার কাছে এমন (মতামতযুক্ত) কোড থাকতে পারে:

public double calculateVolumeAsCylinder(Bottle bottle) {
    return bottle.height * (bottle.diameter / 2.0) * Math.PI);
}

পরিবর্তে এটি করা উচিত

double volume = bottle.calculateVolumeAsCylinder();

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

এটি আপনার নতুন বোতল শ্রেণীর মতো দেখাবে:

public class Bottle {

    private final int height, diameter;

    private Cap capType;

    public Bottle(final int height, final int diameter, final Cap capType) {
        if (diameter < 1) throw new IllegalArgumentException("diameter must be positive");
        if (height < diameter) throw new IllegalArgumentException("bottle must be taller than its diameter");

        setCapType(capType);
        this.height = height;
        this.diameter = diameter;
    }

    public double getVolumeAsCylinder() {
        return height * (diameter / 2.0) * Math.PI;
    }

    public void setCapType(final Cap capType) {
        if (capType == null) throw new NullPointerException("capType cannot be null");
        this.capType = capType;
    }

    // potentially more methods...

}

Answer 9

IMHO প্রায়শই ভারী অবজেক্ট-ভিত্তিক সিস্টেমে এর মতো পর্যাপ্ত ক্লাস হয় না । আমি সাবধানে এটি যোগ্যতা অর্জন করা প্রয়োজন।

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

তবে এমন অনেকগুলি ক্ষেত্রে রয়েছে যেখানে এই জাতীয় ডেটা ক্ষেত্রগুলির খুব সরু সুযোগ থাকবে scope খুব সোজা উদাহরণ উদাহরণস্বরূপ Nodeএকটি স্ট্রাকচারের ব্যক্তিগত ক্লাস। এটি প্রায়শই Nodeকাঁচা ডেটা সমন্বিত থাকতে পারে যদি বলা হয় যে অবজেক্ট ইন্টারঅ্যাকশনগুলির সংখ্যা কমানোর মাধ্যমে কোডটি খুব সহজ করে তুলতে পারে। এটি একটি ডিউপলিং মেকানিজম হিসাবে কাজ করে যেহেতু বিকল্প সংস্করণে দ্বি-নির্দেশমূলক সংযোগের প্রয়োজন হতে পারে, বলতে Tree->Nodeএবং Node->Treeসহজভাবে বিরোধিতা করতে পারে Tree->Node Data।

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

এরকম ক্ষেত্রে আপনি যতটা ইন্টারঅ্যাকশনগুলি যেতে পারেন তার মতো আরও কিছু দিয়ে শেষ করতে পারেন (এই চিত্রটি সংযুক্তিকে নয়, সংযোগকে নির্দেশ করে, যেহেতু একটি সংযুক্ত চিত্রে নীচের দ্বিতীয় চিত্রের জন্য বিমূর্ত ইন্টারফেস অন্তর্ভুক্ত থাকতে পারে):

... এর বিপরীতে:

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

Answer 10

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

SceneMember 
Message extends SceneMember
Port extends SceneMember
InputPort extends Port
OutputPort extends Port

সুতরাং দৃশ্য মেম্বারটি বেস ক্লাস, এটি সমস্ত কাজ করে, যা দৃশ্যে উপস্থিত হওয়া প্রয়োজন: অ্যাড, ডিলেট, গেট-সেট আইডি ইত্যাদি ইত্যাদি বার্তা বন্দরগুলির মধ্যে সংযোগ, এটির নিজস্ব জীবন রয়েছে। ইনপুটপোর্ট এবং আউটপুটপোর্টের নিজস্ব / i নির্দিষ্ট বৈশিষ্ট্য রয়েছে।

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

সম্ভবত এটি একটি অ্যান্টিপ্যাটার্ন , তবে আমি এটি পছন্দ করি।

(এটি "সাথী" শব্দের মতো, যা "স্ত্রী" এবং "স্বামী" উভয়ের জন্যই ব্যবহৃত হয় You আপনি কোনও কংক্রিট ব্যক্তির জন্য "সাথী" শব্দটি কখনও ব্যবহার করেন না, কারণ আপনি তাঁর / তাঁর যৌনতা জানেন, এবং এটি কোনও ব্যাপার নয়) it যদি সে বিবাহিত হয় বা না হয়, তবে আপনি তার পরিবর্তে "কাউকে" ব্যবহার করেন তবে এটি এখনও বিদ্যমান এবং বিরল, বিমূর্ত পরিস্থিতিতে যেমন একটি আইনের পাঠ্য ব্যবহৃত হয়))

Comments

আপনার বন্দরগুলি কেন সিনেমবার প্রসারিত করতে হবে? কেন সিনেমবার্সে পরিচালনা করতে বন্দর ক্লাস তৈরি করবেন না?

— মাইকেল কে

তাহলে কেন স্ট্যান্ডার্ড মার্কার ইন্টারফেস প্যাটার্ন ব্যবহার করবেন না? মূলত আপনার খালি বিমূর্ত বেস শ্রেণীর সাথে অভিন্ন, তবে এটি অনেক বেশি প্রচলিত মূর্খতা।

— TMN

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

— ern0

@ টিএমএন: সিন মেম্বার (ডেরিভেটিভ) প্রকারের মধ্যে getMemberType () পদ্ধতি রয়েছে, যখন দৃশ্য সিনেমার অবজেক্টের সাবসেটের জন্য সিন স্ক্যান করা হয় তখন বেশ কয়েকটি ঘটনা ঘটে।

— ern0

এটি প্রশ্নের উত্তর দেয় না।

— ইভা