কীভাবে আপনি গেটার এবং সেটটারগুলি এড়াতে পারবেন?


85

আমি খুব সুন্দরভাবে ক্লাস ডিজাইনের সাথে কিছু কঠিন সময় পাচ্ছি। আমি পড়েছি যে বস্তুগুলি তাদের আচরণ প্রকাশ করে, তাদের ডেটা নয়; সুতরাং, ডেটা সংশোধন করার জন্য গেটর / সেটার ব্যবহার না করে প্রদত্ত শ্রেণীর পদ্ধতিগুলি "ক্রিয়া" বা বস্তুটিতে ক্রিয়াকলাপ হওয়া উচিত। উদাহরণস্বরূপ, একটি 'অ্যাকাউন্ট' বস্তু, আমরা পদ্ধতি আছে হবে Withdraw()এবং Deposit()বদলে setAmount()ইত্যাদি দেখুন: কেন গেটার এবং সেটার পদ্ধতি মন্দ হয়

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




8
আমি বাতলান যে আপনি মোকাবেলা করতে আছে যদি জাভা বিন্স স্পেসিফিকেশন , আপনি হবে getters এবং setters থাকার হও। প্রচুর জিনিস জাভা বিন (জেএসপিসে এক্সপ্রেশন ভাষা) ব্যবহার করে এবং এগুলি এড়ানোর চেষ্টা করা সম্ভবত ... চ্যালেঞ্জের হতে পারে।

4
... এবং, মাইকেলটি থেকে বিপরীত দৃষ্টিকোণ থেকে: আপনি যদি জাভাবিয়ানস স্পেক ব্যবহার না করেন (এবং আমি ব্যক্তিগতভাবে মনে করি যে আপনি যদি নিজের অবজেক্টটি যেখানে প্রয়োজন সেখানে ব্যবহার না করেন তবে আপনার এটি এড়ানো উচিত), তবে এর দরকার নেই there's গেটরসগুলিতে "গেট" ওয়ার্ট, বিশেষত এমন বৈশিষ্ট্যগুলির জন্য যাগুলির সাথে কোনও সম্পর্কিত সেটার নেই। আমি মনে করি একটি পদ্ধতি নামক name()উপর Customerযেমন পরিষ্কার, বা পরিষ্কার, একটি পদ্ধতি নামক চেয়ে getName()
ড্যানিয়েল প্রাইডেন

2
@ ড্যানিয়েল প্রাইডেন: নাম () এর অর্থ সেট করা বা পাওয়া উভয়ই হতে পারে? ...
ইন্টেলিডিটা

উত্তর:


55

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

উদাহরণ হিসাবে, কল্পনা করুন যে আপনার প্রকল্পটি দাবা বা যুদ্ধের মতো একটি বোর্ড গেম game আপনার উপস্থাপনা স্তরে এটি উপস্থাপনের বিভিন্ন উপায় থাকতে পারে (কনসোল অ্যাপ্লিকেশন, ওয়েব পরিষেবা, জিইউআই, ইত্যাদি), তবে আপনার একটি মূল ডোমেনও রয়েছে। আপনার কাছে থাকতে পারে একটি বর্গ হ'ল Coordinateবোর্ডে একটি অবস্থান উপস্থাপন করে। এটি লেখার "দুষ্ট" উপায়টি হ'ল:

public class Coordinate
{
    public int X {get; set;}
    public int Y {get; set;}
}

(আমি জাভাের পরিবর্তে সি # তে কোড উদাহরণ লিখতে যাচ্ছি, ব্রিভিটির জন্য এবং কারণ এটির সাথে আমি আরও বেশি পরিচিত Hope আশা করি এটি কোনও সমস্যা নয় The ধারণাটি একই রকম এবং অনুবাদটি সহজ হওয়া উচিত))

সেটারগুলি অপসারণ: অপরিবর্তনীয়তা

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

public class Coordinate
{
    public int X {get; private set;}
    public int Y {get; private set;}

    public Coordinate(int x, int y)
    {
        X = x;
        Y = y;
    }
}

নোট করুন যে এটি X এবং Y শ্রেণীর পরিবর্তিত শ্রেণীর অন্যান্য পদ্ধতির বিরুদ্ধে সুরক্ষা দেয় না more আরও কঠোরভাবে অপরিবর্তনীয় হওয়ার জন্য, আপনি readonly( finalজাভাতে) ব্যবহার করতে পারেন । তবে যেভাবেই হোক- আপনি আপনার সম্পত্তিগুলি সত্যিকারের অপরিবর্তনীয় করে তুলুন বা কেবল সেটারগুলির মাধ্যমে সরাসরি জনসাধারণের বিবর্তন রোধ করুন- এটি আপনার সর্বজনীন সেটটারগুলি সরানোর কৌশল করে। বেশিরভাগ পরিস্থিতিতে, এটি ঠিক কাজ করে।

গেটারগুলি সরানো, পর্ব 1: আচরণের জন্য ডিজাইন করা

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

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

public class Piece
{
    public Coordinate Position {get; private set;}
}

public class Coordinate
{
    public int X {get; private set;}
    public int Y {get; private set;}
}

    //...And then, inside some class
    public bool DoPiecesCollide(Piece one, Piece two)
    {
        return one.X == two.X && one.Y == two.Y;
    }

এবং এখানে ভাল উপায়:

public class Piece
{
    private Coordinate _position;
    public bool CollidesWith(Piece other)
    {
        return _position.Equals(other._position);
    }
}

public class Coordinate
{
    private readonly int _x;
    private readonly int _y;
    public bool Equals(Coordinate other)
    {
        return _x == other._x && _y == other._y;
    }
}

( IEquatableবাস্তবায়ন সংক্ষিপ্তসার জন্য সংক্ষিপ্ত)। ডেটা মডেলিংয়ের পরিবর্তে আচরণের জন্য ডিজাইনিং করে, আমরা আমাদের গেটারগুলি সরাতে সক্ষম হয়েছি।

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

গেটারগুলি সরানো, পর্ব 2: বাহ্যিক আচরণ

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

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

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

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

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

আমাদের সমস্যার জন্য, এই প্যাটার্নটি ব্যবহার করে সমাধানটি হ'ল:

public class Coordinate
{
    private readonly int _x;
    private readonly int _y;

    public T Transform<T>(IPositionTransformer<T> transformer)
    {
        return transformer.Transform(_x,_y);
    }
}

public interface IPositionTransformer<T>
{
    T Transform(int x, int y);
}

//This one lives in the presentation layer
public class CoordinateToVectorTransformer : IPositionTransformer<Vector2>
{
    private readonly float _tileWidth;
    private readonly float _tileHeight;
    private readonly Vector2 _topLeft;

    Vector2 Transform(int x, int y)
    {
        return _topLeft + new Vector2(_tileWidth*x + _tileHeight*y);
    }
}

আপনি সম্ভবত বলতে পারেন, _xএবং সত্যিই আর কোনও encapsulated _yহয় না । আমরা তাদের তৈরি করতে পারতাম এমন একটি তৈরি করে যা কেবল তাদের সরাসরি ফেরত দেয়। স্বাদের উপর নির্ভর করে আপনি অনুভব করতে পারেন এটি পুরো অনুশীলনকে অর্থহীন করে তুলেছে।IPositionTransformer<Tuple<int,int>>

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

পরিশেষে , এমনকি প্রাথমিকভাবে এটি সুস্পষ্ট না হলেও, বাস্তবে রাষ্ট্রকে প্রকাশের প্রয়োজন এড়াতে আপনার আচরণ হিসাবে প্রয়োজন যা যথেষ্ট তা প্রকাশ করার উপায় রয়েছে । উদাহরণস্বরূপ, Coordinateযার পূর্ববর্তী সংস্করণটি কেবলমাত্র সর্বজনীন সদস্য হিসাবে ব্যবহার করা হয়েছে Equals()(বাস্তবে এটির জন্য সম্পূর্ণ IEquatableবাস্তবায়ন প্রয়োজন ) আপনি নিজের উপস্থাপনা স্তরে নিম্নলিখিত শ্রেণিটি লিখতে পারেন:

public class CoordinateToVectorTransformer
{
    private Dictionary<Coordinate,Vector2> _coordinatePositions;

    public CoordinateToVectorTransformer(int boardWidth, int boardHeight)
    {
        for(int x=0; x<boardWidth; x++)
        {
            for(int y=0; y<boardWidth; y++)
            {
                _coordinatePositions[new Coordinate(x,y)] = GetPosition(x,y);
            }
        }
    }

    private static Vector2 GetPosition(int x, int y)
    {
        //Some implementation goes here...
    }

    public Vector2 Transform(Coordinate coordinate)
    {
        return _coordinatePositions[coordinate];
    }
}

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

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


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

@ ইন্টেলিডাটা ১. আপনি যখন "ক্ষেত্রগুলি পরিবর্তন করুন" বলবেন, আপনি শ্রেণিক সংজ্ঞা পরিবর্তন করবেন বা ডেটা পরিবর্তন করবেন? আধুনিকগুলি কেবলমাত্র পাবলিক সেটারগুলি অপসারণ করেও গেটারগুলি রেখে এড়ানো যায়, সুতরাং ডিটিও দিকটি অপ্রাসঙ্গিক। পূর্ববর্তীটি সত্যই (পুরো) কারণ নয় যে জনসাধারণ প্রাপ্তিরা "দুষ্ট"। দেখুন programmers.stackexchange.com/questions/157526/... উদাহরণস্বরূপ।
বেন অ্যারোনসন

@ ইন্টেলিডিটা ২. আচরণটি না জেনে উত্তর দেওয়া শক্ত। তবে সম্ভবত, উত্তরটি হ'ল: আপনি তা করবেন না। কোন Customerশ্রেণীর এমন আচরণ কী হতে পারে যার জন্য তার টেলিফোন নম্বরটি পরিবর্তন করতে সক্ষম হওয়া প্রয়োজন? সম্ভবত গ্রাহকের টেলিফোন নম্বর পরিবর্তিত হয় এবং আমার ডাটাবেসে সেই পরিবর্তনটি বজায় রাখা দরকার তবে এগুলির কোনওটিই কোনও আচরণ সরবরাহকারী ডোমেন অবজেক্টের দায়িত্ব নয়। এটি একটি ডেটা অ্যাক্সেসের উদ্বেগ এবং সম্ভবত একটি ডিটিও এবং বলতে হবে, একটি ভাণ্ডার সহ পরিচালনা করা হবে।
বেন অ্যারনসন

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

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

71

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

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

আরও পড়া
কখন গেটারস এবং সিটারগুলি ন্যায়সঙ্গত হয়


3
তাহলে 'গেটর / সেটার' সম্পর্কে সমস্ত হাইপ কেন খারাপ?
ইন্টেলিটাটা

46
সফ্টওয়্যার বিকাশকারীদের দ্বারা কেবল স্বাভাবিক পন্টিফিকেশন যাদের আরও ভাল জানা উচিত। আপনি যে নিবন্ধটি সংযুক্ত করেছেন তার জন্য লেখক আপনার দৃষ্টি আকর্ষণ করার জন্য "getters and setters are वाईट" বাক্যাংশটি ব্যবহার করছেন, তবে এর অর্থ এই নয় যে বিবৃতিটি স্পষ্টভাবে সত্য।
রবার্ট হার্ভে

12
@ ইন্টেলিডাটা কিছু লোক আপনাকে বলবে যে জাভা নিজেই খারাপ।
নাল

18
@ মেটাফাইটsetEvil(null);

4
অবশ্যই অ্যাভিল অবতার। অথবা নিকটতম কাজিন।
বিশপ

58

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

তাহলে কেউ কেন "গেটর এবং সেটার পদ্ধতিগুলি খারাপ" বলবে? আপনি এটিকে অনেক কিছু দেখতে পাবেন - কেউ একটি নির্দেশিকা গ্রহণ করেন যা নির্দিষ্ট প্রসঙ্গে পুরোপুরি বৈধ এবং তারপরে আরও কঠোরতার শিরোনাম পেতে প্রসঙ্গটি সরিয়ে ফেলুন। উদাহরণস্বরূপ " উত্তরাধিকারের উপর রচনাটির পক্ষপাতিত্ব করুন " একটি সূক্ষ্ম নীতি, তবে খুব শীঘ্রই যথেষ্ট কেউ প্রসঙ্গটি সরিয়ে "" কেন প্রসারিত হয় তা মন্দ "(হেই, একই লেখক, কী কাকতালীয় ঘটনা!) বা" উত্তরাধিকার মন্দ তা অবশ্যই হবে এবং হতে হবে " ধ্বংস "।

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

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

এটি ভেবে দেখার মতো যে আপনি একই বাস্তবায়ন চালিয়ে গিয়ে সিলেলেটনের নাম পরিবর্তন করে সেখানে নাম পরিবর্তন করে এড়িয়ে চলেছেন can


ওওফ মধ্যে, তথাকথিত বিশেষজ্ঞরা বলে মনে হয় যে এটি ঘটেনি।
ইন্টেলিডিটা

8
তারপরে আবারও কিছু লোক বলেছেন '
ওওপি

7
এফটিআর, আমি মনে করি আরও "বিশেষজ্ঞ" এখনও কোনও কিছু তৈরি না করেই অর্থহীনভাবে সমস্ত কিছুর জন্য গেটার / সেটার তৈরি করতে শেখায় । আইএমও, দ্বিতীয়টি বিপথগামী পরামর্শ কম।

4
@ বামদিকের চৌকো: ঠিক আছে, তবে আমি 'সর্বদা' এবং 'কখনই নয়' এর মধ্যে একটি মাঝারি স্থলটি প্রস্তাব করছি যা 'যখন উপযুক্ত হয় তখন ব্যবহার হয়'।
জ্যাকবিবি

3
আমি মনে করি সমস্যাটি হ'ল অনেক প্রোগ্রামার প্রতিটি বস্তু (বা অনেকগুলি অবজেক্ট) কে একটি ডিটিওতে পরিণত করে। কখনও কখনও এগুলি প্রয়োজনীয় হয়, তবে তাদের যতটা সম্ভব এড়িয়ে চলুন যেহেতু তারা ডেটা আচরণ থেকে পৃথক করে। (ধরে নিচ্ছেন আপনি একজন ধর্মপ্রাণ OOPer)
user949300

11

Customerএকটি ডেটা অবজেক্ট থেকে - ক্লাসটি রূপান্তর করতে , আমরা আমাদের নিজেদেরকে ডেটা ক্ষেত্রগুলি সম্পর্কে নিম্নলিখিত প্রশ্নগুলি জিজ্ঞাসা করতে পারি:

আমরা কীভাবে {ডেটা ফিল্ড use ব্যবহার করতে চাই? {ডেটা ফিল্ড Where কোথায় ব্যবহৃত হয়? {ডেটা ফিল্ড of এর ব্যবহারটি কি ক্লাসে স্থানান্তরিত করা উচিত?

উদাহরণ:

  • এর উদ্দেশ্য কী Customer.Name?

    সম্ভাব্য উত্তরগুলি, লগইন ওয়েব পৃষ্ঠায় নামটি প্রদর্শন করুন, গ্রাহকের কাছে মেলিংয়ে নামটি ব্যবহার করুন।

    যা পদ্ধতি বাড়ে:

    • Customer.FillInTemplate (...)
    • Customer.IsApplicableForMailing (...)
  • এর উদ্দেশ্য কী Customer.DOB?

    গ্রাহকের বয়স যাচাই করা হচ্ছে। গ্রাহকের জন্মদিনে ছাড়। মেলগুলির।

    • Customer.IsApplicableForProduct ()
    • Customer.GetPersonalDiscount ()
    • Customer.IsApplicableForMailing ()

মতামত দেওয়া, উদাহরণ বস্তু Customer- উভয় একটি ডেটা অবজেক্ট হিসাবে এবং "বাস্তব" বস্তু হিসাবে নিজস্ব দায়বদ্ধতা - এটি খুব বিস্তৃত; অর্থাত্ এটির অনেক বেশি সম্পত্তি / দায়িত্ব রয়েছে। যা হয় হয় প্রচুর উপাদানগুলির উপর নির্ভর করে Customer(এর বৈশিষ্ট্যগুলি পড়ে) বা Customerপ্রচুর উপাদানগুলির উপর নির্ভর করে। গ্রাহকের বিভিন্ন দৃষ্টিভঙ্গি থাকতে পারে, সম্ভবত প্রত্যেকের নিজস্ব স্বতন্ত্র শ্রেণি 1 থাকতে হবে :

  • গ্রাহক Accountএবং আর্থিক লেনদেনের প্রসঙ্গে সম্ভবত কেবলমাত্র ব্যবহৃত হয়:

    • মানুষকে তাদের অর্থ স্থানান্তর সঠিক ব্যক্তির কাছে যায় তা সনাক্ত করতে সহায়তা করুন; এবং
    • গ্রুপ Accountএস।

    এই গ্রাহক মত ক্ষেত্র দরকার নেই DOB, FavouriteColour, Tel, এবং সম্ভবত এমনকি Address

  • কোনও গ্রাহক কোনও ব্যাঙ্কিং ওয়েবসাইটে লগ ইন করে এমন কোনও ব্যবহারকারী প্রসঙ্গে।

    প্রাসঙ্গিক ক্ষেত্রগুলি হ'ল:

    • FavouriteColour, যা ব্যক্তিগতকৃত তাদের আকারে আসতে পারে;
    • LanguagePreferences, এবং
    • GreetingName

    গেটর এবং সেটটারগুলির সাথে সম্পত্তিগুলির পরিবর্তে এগুলি একটি একক পদ্ধতিতে ক্যাপচার করা যেতে পারে:

    • পার্সোনালাইজ ওয়েবপেজ (টেমপ্লেট পৃষ্ঠা);
  • বিপণন এবং ব্যক্তিগতকৃত মেলিংয়ের প্রসঙ্গে গ্রাহক।

    এখানে কোনও ডাটাবজেক্টের বৈশিষ্ট্যের উপর নির্ভর না করে বরং বস্তুর দায়িত্ব থেকে শুরু করে; উদাহরণ:

    • IsCustomerInterestedInAction (); এবং
    • GetPersonalDiscounts ()।

    এই গ্রাহকের অবজেক্টের একটি FavouriteColourসম্পত্তি আছে এবং / অথবা কোনও Addressসম্পত্তি অপ্রাসঙ্গিক হয়ে পড়েছে: সম্ভবত বাস্তবায়ন এই বৈশিষ্ট্যগুলি ব্যবহার করে; তবে এটি কিছু মেশিন লার্নিং কৌশল ব্যবহার করতে পারে এবং গ্রাহকের সাথে পূর্ববর্তী মিথস্ক্রিয়াগুলি ব্যবহার করে কোন পণ্যগুলিতে গ্রাহক আগ্রহী তা আবিষ্কার করতে পারে।


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


4
আপভোট করুন কারণ আপনি প্রকৃতপক্ষে প্রশ্নের উত্তর দিচ্ছেন :) তবে এটাও স্পষ্ট যে প্রস্তাবিত সমাধানগুলি কেবল গেটস / সেটটারের চেয়ে বেশি খারাপ - উদাহরণস্বরূপ ফিলিএনটেম্পলেট উদ্বেগের নীতির বিচ্ছেদকে স্পষ্টভাবে ভেঙে দেয়। যা কেবল দেখায় যে প্রশ্নের ভিত্তিটি ত্রুটিযুক্ত।
জ্যাকবিবি

@ ক্যাস্পার ভ্যান ডেন বার্গ: এবং গ্রাহকের কাছে সাধারণত যেমন অনেকগুলি বৈশিষ্ট্য রয়েছে তখন আপনি প্রাথমিকভাবে সেগুলি কীভাবে সেট করবেন?
ইন্টেলিডিটা

2
@ ইন্টেলি ডেটা আপনার মানগুলি সম্ভবত কোনও ডাটাবেস, এক্সএমএল ইত্যাদি থেকে আসে are গ্রাহক বা গ্রাহক বিল্ডার সেগুলি পড়েন, তারপরে (যেমন জাভায়) ব্যক্তিগত / প্যাকেজ / অভ্যন্তরীণ শ্রেণীর অ্যাক্সেস, বা (আইক) প্রতিবিম্ব ব্যবহার করে সেট করুন। নিখুঁত নয়, তবে আপনি সাধারণত পাবলিক সেটটারগুলি এড়াতে পারেন। (আরও কিছু তথ্যের জন্য আমার উত্তর দেখুন)
user949300

6
আমি মনে করি না গ্রাহক শ্রেণীর এই বিষয়গুলির কোনও সম্পর্কে জানা উচিত।
কোডসইনচাউস

এরকম কিছু নিয়ে কি হবে Customer.FavoriteColor?
গাবে 20'15

8

টি এল; ডিআর

  • আচরণের জন্য মডেলিং করা ভাল।

  • ভাল (!) বিমূর্ততার জন্য মডেলিং করা ভাল।

  • কখনও কখনও ডেটা অবজেক্টগুলির প্রয়োজন হয়।


আচরণ এবং বিমূর্ততা

গেটর এবং সেটটারগুলি এড়ানোর বিভিন্ন কারণ রয়েছে। মডেলিং ডেটা এড়ানোর জন্য, আপনি যেমনটি উল্লেখ করেছেন একটি হ'ল। এটি আসলে গৌণ কারণ। বড় কারণ হ'ল বিমূর্ততা সরবরাহ করা।

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

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

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


গ্রাহক ক্লাস

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

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

তবুও, সেটটাররা / অপ্রয়োজনীয় পরিষেবাগুলি সরবরাহ করতে পারে: তারা ইমেল ঠিকানাগুলির সঠিক ফর্ম্যাট, ডাক ঠিকানাগুলির যাচাইকরণ ইত্যাদি নিশ্চিত করতে পারে একইভাবে, "প্রাপ্তরা" Name <user@server.com>ফর্ম্যাটে ইমেল-ঠিকানা সরবরাহের মতো উচ্চ-স্তরের পরিষেবা সরবরাহ করতে পারে নাম ক্ষেত্র এবং জমা থাকা ইমেল ঠিকানা ব্যবহার করে বা সঠিকভাবে ফর্ম্যাটেড ডাক ঠিকানা সরবরাহ করা ইত্যাদি course অবশ্যই, এই উচ্চ স্তরের কার্যকারিতাটি কী বোঝায় তা আপনার ব্যবহারের ক্ষেত্রে খুব বেশি নির্ভর করে। এটি সম্পূর্ণ ওভারকিল হতে পারে, অথবা এটি সঠিকভাবে করার জন্য এটি অন্য শ্রেণীর কাছে কল করতে পারে। বিমূর্ত স্তর স্তরের পছন্দ সহজ নয়।


ঠিক আছে, যদিও আমি লিঙ্গ অংশের সাথে একমত নই ...;)
ইন্টেলিডিটা

6

ক্যাস্পারের উত্তরটি প্রসারিত করার চেষ্টা করা হচ্ছে, সেটার বিরুদ্ধে লড়াই করা এবং নির্মূল করা সহজ। বরং একটি অস্পষ্ট, হ্যান্ডউইভিং (এবং আশা করি হাস্যকর) যুক্তিতে:

কাস্টোমারের নাম কখন পরিবর্তন হবে?

কদাপি। তারা বিবাহিত হতে পারে। অথবা সাক্ষী সুরক্ষায় চলে গেলেন। তবে সেক্ষেত্রে আপনি নিজের বাসা, আত্মীয়-স্বজনের পাশের জায়গা এবং অন্যান্য তথ্যও সম্ভবত পরীক্ষা করে দেখতে এবং চান।

ডিওবি কখন পরিবর্তন হবে?

শুধুমাত্র প্রাথমিক তৈরি বা ডেটা এন্ট্রি স্ক্রুআপে। বা যদি তারা ডোমিনকান বেসবল খেলোয়াড় হয়। :-)

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

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

(প্রশ্নের হিসাবে অ্যাডেন্ডাম কিছুটা বদলে গেছে ...)

ধরা যাক যে আপনার অ্যাপ্লিকেশনটি রিলেশনাল ডাটাবেসগুলির ভারী ব্যবহার করে। এটা Customer.saveToMYSQL()বা Customer.readFromMYSQL()পদ্ধতি আছে বোকামি হবে । এটি একটি কংক্রিট, অ-মানক এবং সত্তা পরিবর্তন করার সম্ভাবনাতে অনাকাঙ্ক্ষিত মিলন তৈরি করে । উদাহরণস্বরূপ, আপনি যখন স্কিমা পরিবর্তন করেন বা পোস্টগ্র্রেস বা ওরাকল এ পরিবর্তন করেন।

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

এইভাবে আপনি (সম্ভবত) গেটার এবং সেটটারগুলির প্রয়োজনীয়তা এড়াতে বা হ্রাস করতে পারেন।

এবং, হলুব নিবন্ধের মূল বিষয়, আপনি যদি সমস্ত কিছুর জন্য গেটার এবং সেটটার ব্যবহার করেন এবং ডাটাবেস পরিবর্তন করেন তবে উপরেরটির তুলনা করুন এবং তার বিপরীতে করুন।

একইভাবে, ধরা যাক আপনি প্রচুর এক্সএমএল ব্যবহার করেন। আইএমও, আপনার গ্রাহকটিকে একটি অ্যাবস্ট্রাক্ট স্ট্যান্ডার্ড, যেমন পাইথন xml.etree.ElementTree বা জাভা org.w3c.dom.Element হিসাবে দম্পতি করা ভাল । গ্রাহক এটি থেকে নিজেকে সেট করে। আবার, আপনি (সম্ভবত) গেটার এবং সেটটারগুলির প্রয়োজনীয়তা কমিয়ে দিতে পারেন।


আপনি কি বলবেন যে কোনও বিল্ডার প্যাটার্নটি ব্যবহার করা ভাল?
ইন্টেলিডিটা

নির্মাতা কোনও অবজেক্টের নির্মাণকে আরও সহজ এবং আরও শক্তিশালী করার জন্য দরকারী এবং যদি আপনি চান তবে অবজেক্টটি অপরিবর্তনীয় হতে দেয়। তবে এটি এখনও (আংশিকভাবে) সত্যটি প্রকাশ করে যে অন্তর্নিহিত অবজেক্টটির একটি ডিওবি ক্ষেত্র রয়েছে, সুতরাং এটি মৌমাছি-সব শেষ নয়।
user949300

1

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

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

এটি প্রায় বিভিন্ন উপায় আছে। একটি উপায় হ'ল ডেটা "বন্ধু" এর কাছে উপলব্ধ করা। যদিও বন্ধুত্ব উত্তরাধিকারসূত্রে পাওয়া যায় নি, বন্ধুর কাছ থেকে তথ্যের অনুরোধ করে যা কিছু সিরিয়ালাইজার, অর্থাৎ বেস সিরিয়ালাইজার তথ্যটিকে "ফরোয়ার্ডিং" করে এটি কাটিয়ে উঠতে পারে।

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

যদি আপনার ভাষাটি বিশেষত সি ++ হয় তবে এর চারপাশের এক উপায় হ'ল জনসাধারণের "স্ট্রাক্ট" ডেটা এবং তারপরে আপনার শ্রেণীর সদস্য হিসাবে এই "স্ট্রাক্ট" এর উদাহরণ থাকতে পারে এবং বাস্তবে আপনি যে সমস্ত ডেটা সঞ্চয় করতে চলেছেন / এটিতে সংরক্ষণ করতে পুনরুদ্ধার করুন। তারপরে আপনি একাধিক ফর্ম্যাটে আপনার ডেটা পড়তে / লিখতে সহজেই "র‍্যাপারস" লিখতে পারেন।

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


0

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

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

বিপরীতে আপনি যখন কোনও নেটওয়ার্ক পরিষেবা কল করেন তখন আপনার একটি সুস্পষ্ট ইনপুট সরবরাহ করা হয়। সাধারণত একটি ব্যাকরণ (জেএসএন বা এক্সএমএলের মতো) এবং পরিষেবাটি কল করার সমস্ত বিকল্পের গোপন হওয়ার কোনও কারণ নেই। ধারণাটি হ'ল আপনি পরিষেবাটিকে নিজের পছন্দ মতো কল করতে পারেন এবং ডেটা ফর্ম্যাটটি সর্বজনীন এবং প্রকাশিত।

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

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

তবে জাভা-র মতো ভাষায়ও এটি ঘটে থাকে, কেবলমাত্র জিনিসগুলি আপনি অবজেক্ট বা বস্তুর অ্যারে can অবজেক্টস থেমেসেলভ কয়েকটি দেশীয় ধরণের (ইন্টি, ফ্লোট ...) ধরে রাখতে পারে তবে এগুলি সবই। তবে অবজেক্টগুলি কেবল সরকারী ক্ষেত্র এবং সেগুলি দিয়ে একটি সাধারণ কাঠামোর মতো আচরণ করতে পারে all

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

সেটার পদ্ধতিতে আপনি কিছু যুক্তি / চেক যোগ করতে পারেন এমন যুক্তিও রয়েছে।

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

তবে এটি পুরানো অভ্যাস এবং পুরাতন অভ্যাসগুলি অপসারণ করা কঠিন ... আপনি এমনকি কলেজগুলি বা শিক্ষক দ্বারা হুমকির মুখে পড়তে পারেন যদি আপনি সব জায়গায় গেটস / সেটারকে অন্ধভাবে না রাখেন তবে তারা কী এবং তারা কী তা আরও ভালভাবে বুঝতে ব্যাকগ্রাউন্ডের অভাব হয় যদি না.

এই সমস্ত গ্রাহকরা / সেটটারদের বয়লারপ্লেট কোডটি চালানোর জন্য আপনার সম্ভবত ভাষা পরিবর্তন করতে হবে। (সি # বা লিস্পের মতো)। আমার কাছে গেটার্স / সেটার কেবল আরও এক বিলিয়ন ডলার ভুল ...


6
সি # বৈশিষ্ট্যগুলি প্রকৃতপক্ষে
গেটার্স

1
[জিএস] ইটারগুলির সুবিধা হ'ল আপনি যে কাজগুলি সাধারণত করেন না তা করতে পারেন (মানগুলি পরীক্ষা করুন, পর্যবেক্ষকদের অবহিত করুন), অ-বিদ্যমান ক্ষেত্রগুলি ইত্যাদি অনুকরণ করুন এবং মূলত আপনি এটি পরে পরিবর্তন করতে পারবেন । সঙ্গে Lombok , boilerplate, সর্বস্বান্ত হয়: @Getter @Setter class MutablePoint3D {private int x, y, z;}
মার্টিনাস

1
@ মাআর্টিনাস নিশ্চিতভাবেই [জিএস] ইত্তার অন্য যে কোনও পদ্ধতি যেমন করতে পারে তেমন কিছু করতে পারে। এর অর্থ হ'ল যে কোনও কলার কোডকে তারা নির্ধারণ করা যে কোনও মান একটি ব্যতিক্রম ছুঁড়ে ফেলতে পারে, পরিবর্তন করা যেতে পারে বা সম্ভাব্য পরিবর্তনের বিজ্ঞপ্তি প্রেরণ করা উচিত ... বা অন্য যাই হোক না কেন। আরও কম-বেশি [জিএস] ইটার কোনও ক্ষেত্রে অ্যাক্সেস সরবরাহ করছে না তবে সালিসি কোড করছে।
নিকোলাস বসকেট 20'15

@ ইন্টেলিডিটা সি # বৈশিষ্ট্যগুলি বয়লারপ্লেটের 1 টি অকেজো অক্ষর লিখতে দেয় না এবং এই সমস্ত গিটার / সেটার স্টাফের যত্ন না নেওয়ার জন্য ... এটি প্রকল্প লম্বকের চেয়ে ইতিমধ্যে ভাল অর্জন। এছাড়াও আমার কাছে কেবল গেটার্স / সেটারযুক্ত একটি পজো এখানে এনক্যাপসুলেশন সরবরাহ করার জন্য নয় বরং একটি ডেটা ফর্ম্যাট প্রকাশ করার জন্য যা কোনও পরিষেবার সাথে বিনিময় হিসাবে পড়তে বা লিখতে মুক্ত। এনক্যাপসুলেশনটি তখন নকশার প্রয়োজনের বিপরীত।
নিকোলাস বসকেট 20'15

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

0

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

আমি মনে করি এই প্রশ্নটি কাঁটাযুক্ত কারণ আপনি ডেটা পপুলেশন করার আচরণের পদ্ধতি সম্পর্কে চিন্তিত কিন্তু Customerঅবজেক্টগুলির শ্রেণি কীভাবে আচরণ করা যায় তা সম্পর্কে কোনও ইঙ্গিত আমি দেখতে পাই না ।

কোনও ব্যবহারকারী / অভিনেতা হিসাবে আপনার সফ্টওয়্যার ব্যবহার করে বিভিন্ন কাজ সম্পাদন করে এমন Customerএক শ্রেণীর অবজেক্টের 'গ্রাহক' হিসাবে বিভ্রান্ত করবেন না ।

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

গেটার্স / সেটারগুলি খারাপ হওয়ার বিষয়ে লিঙ্কিত নিবন্ধ থেকে:

ওও ডিজাইন প্রক্রিয়াটি ব্যবহারের ক্ষেত্রে কেন্দ্র করে: একজন ব্যবহারকারী একক কাজ সম্পাদন করে যার কিছু কার্যকর ফলাফল হয়। (লগইন করা কোনও ব্যবহারের ক্ষেত্রে নয় কারণ এতে সমস্যা ডোমেনে কোনও কার্যকর ফলাফলের অভাব রয়েছে pay পেচেক আঁকাই ব্যবহারের ক্ষেত্রে is

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

আপনার অর্ডার সিস্টেমটি Rockক্রয়ের আদেশের সাথে সংযুক্ত হতে পারে এবং যতক্ষণ Rockতার ঠিকানা সংজ্ঞায়িত করা থাকে ততক্ষণ সিস্টেমের কিছু অংশ নিশ্চিত করতে পারে যে কোনও আইটেম শিলা সরবরাহ করা হয়েছে।

এই সমস্ত ক্ষেত্রেই Rockকেবলমাত্র একটি ডেটা অবজেক্ট এবং আমরা হাইপোথটিকালগুলির পরিবর্তে কার্যকর ফলাফলগুলির সাথে নির্দিষ্ট আচরণগুলি সংজ্ঞায়িত না করা অবধি এক অব্যাহত থাকবে।


এটা চেষ্টা কর:

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

কোনও Rockবস্তু কি একটি আদেশ দেয় বা এটি এমন কিছু যা আপনার সিস্টেমে ক্রিয়াকলাপ ঘটাতে UI উপাদানগুলিতে ক্লিক করে কোনও মানুষ একটি কাজ করে?


গ্রাহক এমন এক অভিনেতা যা অনেক কিছু করে, তবে এর সাথে প্রচুর পরিমাণে তথ্য যুক্ত থাকে; এটি 2 টি পৃথক শ্রেণি, একজন অভিনেতা হিসাবে 1 এবং ডেটা অবজেক্ট হিসাবে 1 তৈরি করা ন্যায্যতা দেয়?
ইন্টেলিডিটা

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

0

আমি এখানে এসকিউএল-স্পিকিং অবজেক্টগুলির পদ্ধতির উল্লেখ করে আমার 2 সেন্ট যুক্ত করছি ।

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

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

পরিশেষে, আমি লক্ষ করতে চাই যে অবজেক্ট সন্ধানের পদ্ধতিটি সাবসিস্টেমগুলিতে সিস্টেম পচনের সাথে খুব মিল । দুটিই আচরণের ভিত্তিতে তৈরি, অন্য কিছু নয় not

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