ডিডিডি ওওপি-র সাথে মিলিত: কীভাবে কোনও অবজেক্ট-ভিত্তিক সংগ্রহস্থলটি প্রয়োগ করবেন?


12

ডিডিডি সংগ্রহস্থলের একটি সাধারণ প্রয়োগ খুব বেশি ওও দেখায় না, উদাহরণস্বরূপ একটি save()পদ্ধতি:

package com.example.domain;

public class Product {  /* public attributes for brevity */
    public String name;
    public Double price;
}

public interface ProductRepo {
    void save(Product product);
} 

অবকাঠামো অংশ:

package com.example.infrastructure;
// imports...

public class JdbcProductRepo implements ProductRepo {
    private JdbcTemplate = ...

    public void save(Product product) {
        JdbcTemplate.update("INSERT INTO product (name, price) VALUES (?, ?)", 
            product.name, product.price);
    }
} 

এই জাতীয় ইন্টারফেসটি Productকমপক্ষে গ্রাহকদের সাথে একটি রক্তাল্পতা মডেল হওয়ার প্রত্যাশা করে ।

অন্যদিকে, ওওপি বলেছে যে কোনও জিনিসের Productনিজেকে কীভাবে সংরক্ষণ করতে হবে তা জানা উচিত।

package com.example.domain;

public class Product {
    private String name;
    private Double price;

    void save() {
        // save the product
        // ???
    }
}

জিনিসটি হ'ল, যখন Productকীভাবে নিজেকে বাঁচাতে জানে তখন এর অর্থ ইনফ্রাস্ট্রাকচার কোডটি ডোমেন কোড থেকে আলাদা হয় না।

হতে পারে আমরা সঞ্চয়টি অন্য কোনও বস্তুর কাছে অর্পণ করতে পারি:

package com.example.domain;

public class Product {
    private String name;
    private Double price;

    void save(Storage storage) {
        storage
            .with("name", this.name)
            .with("price", this.price)
            .save();
    }
}

public interface Storage {
    Storage with(String name, Object value);
    void save();
}

অবকাঠামো অংশ:

package com.example.infrastructure;
// imports...

public class JdbcProductRepo implements ProductRepo {        
    public void save(Product product) {
        product.save(new JdbcStorage());
    }
}

class JdbcStorage implements Storage {
    private final JdbcTemplate = ...
    private final Map<String, Object> attrs = new HashMap<>();

    private final String tableName;

    public JdbcStorage(String tableName) {
        this.tableName = tableName;
    }

    public Storage with(String name, Object value) {
        attrs.put(name, value);
    }
    public void save() {
        JdbcTemplate.update("INSERT INTO " + tableName + " (name, price) VALUES (?, ?)", 
            attrs.get("name"), attrs.get("price"));
    }
}

এটি অর্জনের জন্য সর্বোত্তম পদ্ধতির কী? কোনও অবজেক্ট-ভিত্তিক সংগ্রহস্থল কার্যকর করা কি সম্ভব?


6
ওওপি বলেছে যে কোনও পণ্য অবজেক্ট নিজেকে কীভাবে সংরক্ষণ করতে হবে তা জানা উচিত - আমি নিশ্চিত নই যে এটি সত্যই সঠিক ... নিজেই ওওপি সত্যই এটি নির্দেশ করে না, এটি একটি নকশা / প্যাটার্ন সমস্যা বেশি (যেখানে আপনি ডিডিডি / যাই হোক না কেন -
-উজে আসুন

1
মনে রাখবেন যে ওওপি প্রসঙ্গে, এটি বস্তুর বিষয়ে কথা বলছে। কেবল অবজেক্টস, ডেটা অধ্যবসায় নয়। আপনার বক্তব্য ইঙ্গিত দেয় যে কোনও জিনিসের অবস্থা নিজের বাইরে পরিচালনা করা উচিত নয়, যার সাথে আমি সম্মত agree কিছু অধ্যবসায় স্তর (যা OOP এর রাজ্যের বাইরে) থেকে লোড / সঞ্চয় করার জন্য একটি সংগ্রহস্থল দায়ী। শ্রেণীর বৈশিষ্ট্য এবং পদ্ধতিগুলির নিজস্ব অখণ্ডতা বজায় রাখা উচিত, হ্যাঁ, তবে এর অর্থ এই নয় যে অন্য কোনও অব্যবস্থা রাষ্ট্রকে টিকিয়ে রাখার জন্য দায়বদ্ধ হতে পারে না। এবং, গেটার্স এবং সেটারগুলি হ'ল অবজেক্টের ইনকামিং / আউটগোয়িং ডেটার অখণ্ডতা নিশ্চিত করা।
jleach

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

1
@ জ্লেইচ আপনি ঠিক বলেছেন, আমাদের ওওপি-র অপরিবর্তনীয়তা আলাদা, আমার জন্য গেটার্স + সেটাররা মোটেও কোনও ওওপি নয়, অন্যথায় আমার প্রশ্নের কোনও ধারণা ছিল না। যাহোক তোমাকে ধন্যবাদ! :-)
ttulka

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

উত্তর:


7

তুমি লিখেছিলে

অন্যদিকে, ওওপি বলেছে যে কোনও পণ্য অবজেক্টের নিজেকে কীভাবে সংরক্ষণ করতে হবে তা জানা উচিত

এবং একটি মন্তব্যে।

... এটি সম্পন্ন সমস্ত অপারেশন জন্য দায়ী করা উচিত

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

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

যাইহোক, আপনার অ্যাপ্লিকেশন সত্যিকারের ব্যবসায়িক ক্রিয়াকলাপগুলিকে সমর্থন করার সাথে সাথে পণ্য কেনা বা বেচা, স্টক রাখা এবং সেগুলি পরিচালনা করা বা তাদের জন্য কর গণনা করা, আপনি খুব সহজেই কাজ শুরু করেন যা কোনও Productশ্রেণিতে সংবেদনশীলভাবে স্থাপন করা যেতে পারে operations উদাহরণস্বরূপ, এমন কোনও অপারেশন হতে পারে CalcTotalPrice(int noOfItems)যা অ্যাকাউন্টে ভলিউম ছাড় নেওয়ার সময় একটি নির্দিষ্ট পণ্যের product n আইটেমের জন্য মূল্য গণনা করে।

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


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

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

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

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

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

5

ট্রাম্পস তত্ত্ব অনুশীলন করুন।

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

নিশ্চিত হয়ে এটি পণ্যের ডেটা লুকানোর ওওপি নিয়মকে ভঙ্গ করে। তবে এটি ভাল কাজ করে।

ব্যতিক্রম কিছু সাধারণ ভাল নিয়ম তৈরির চেয়ে সবকিছুকে কভার করে নিয়মিত নিয়মগুলির সেট তৈরি করা আরও শক্ত।


3

ডিডিডি ওওপির সাথে দেখা করে

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

অন্যদিকে, ওওপি বলেছে যে কোনও পণ্য অবজেক্টের নিজেকে কীভাবে সংরক্ষণ করতে হবে তা জানা উচিত।

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

ডাটাবেসের মেমরি উপস্থাপনা এবং এর অবিস্মরণীয় স্মৃতিসৌধের মধ্যে ডেটা অনুলিপি করার কিছু উপায় থাকা দরকার । সীমানায় , জিনিসগুলি বেশ প্রাথমিক হয়ে উঠেছে get

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

হতে পারে আমরা সঞ্চয়টি অন্য কোনও বস্তুর কাছে অর্পণ করতে পারি:

এটি অবশ্যই কাজ করে - আপনার অবিরাম সঞ্চয়স্থান কার্যকরভাবে কলব্যাক হয়ে যায়। আমি সম্ভবত ইন্টারফেসটি আরও সহজ করে তুলব:

interface ProductStorage {
    onProduct(String name, double price);
}

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

এই পদ্ধতির - কলব্যাকের মাধ্যমে ডেটা পাস করা, টিডিডিতে মক বিকাশে গুরুত্বপূর্ণ ভূমিকা পালন করেছিল ।

নোট করুন যে কলটি তথ্য ফেরত পাঠানোতে কোনও ক্যোয়ারী থেকে তথ্য ফেরত দেওয়ার মতো সমস্ত বিধিনিষেধ রয়েছে - আপনি আপনার ডেটা স্ট্রাকচারের মিউটেটেবল অনুলিপিগুলি অতিক্রম করবেন না।

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

আমি ডিওডিডিকে একটি ওওপি কৌশল হিসাবে বুঝতে পারি এবং তাই আমি দেখতে পারি যে এই দ্বিধায়নের বিরোধিতা পুরোপুরি বুঝতে চাই।

একটি জিনিস মনে রাখতে হবে - ব্লু বুকটি পনের বছর আগে লেখা হয়েছিল, যখন জাভা ১.৪ পৃথিবীতে ঘোরাঘুরি করেছিল। বিশেষত, বইটি জাভা জেনেরিকের পূর্বাভাস দেয় - আমাদের কাছে তখন অনেক বেশি কৌশল উপলব্ধ রয়েছে যখন ইভান্স তার ধারণাগুলি বিকাশ করছিল।


2
এগুলিও উল্লেখ করার মতো বিষয়: "নিজেকে বাঁচান" এর জন্য সর্বদা অন্যান্য বস্তুর সাথে ইন্টারঅ্যাকশন প্রয়োজন (কোনও ফাইল সিস্টেম অবজেক্ট, বা একটি ডেটাবেস, বা একটি দূরবর্তী ওয়েব পরিষেবা, এর মধ্যে কিছুতে অ্যাক্সেস নিয়ন্ত্রণের জন্য একটি অধিবেশন প্রতিষ্ঠার প্রয়োজন হতে পারে)। সুতরাং এই জাতীয় একটি বিষয় স্ব-স্থায়ী এবং স্বাধীন হবে না would OOP এর জন্য এটি প্রয়োজন হয় না, যেহেতু এর উদ্দেশ্য হ'ল বস্তুটি encapsulate এবং সংযুক্তি হ্রাস করা।
ক্রিস্টোফ

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

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

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

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

1

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

সংক্ষিপ্ত উত্তর: না। আপনার আবেদনে এমন কোনও জিনিস থাকা উচিত নয় যা খাঁটি প্রযুক্তিগত এবং কোনও ডোমেন-প্রাসঙ্গিকতা না রাখে। এটি অ্যাকাউন্টিং অ্যাপ্লিকেশনটিতে লগিং ফ্রেমওয়ার্কটি কার্যকর করার মতো।

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

এছাড়াও, save()কোনও সামগ্রীতে কেবল যদি সেই ডোমেনের অংশ ("ভাষা") থাকে তবে তাকে অনুমতি দেওয়া উচিত। উদাহরণস্বরূপ, Accountআমি কল করার পরে আমার স্পষ্টভাবে "সংরক্ষণ" করার দরকার নেই transfer(amount)। আমার ঠিকই আশা করা উচিত যে ব্যবসায়ের ফাংশনটি transfer()আমার স্থানান্তরকে বহাল রাখবে।

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


আপনার কথা কি কোথাও দেখার আছে? (আমি দেখতে পাচ্ছি লিঙ্কের নীচে কেবল স্লাইডগুলি)। ধন্যবাদ!
ttulka

আমার কাছে এখানে কেবল জার্মানির একটি রেকর্ডিং রয়েছে: javadevguy.wordpress.com/2018/11/26/…
রবার্ট ব্রুটিগাম

দুর্দান্ত কথা! (ভাগ্যক্রমে আমি জার্মান কথা বলি)। আমি মনে করি আপনার পুরো ব্লগটি পড়া মূল্যবান ... আপনার কাজের জন্য আপনাকে ধন্যবাদ!
ttulka

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

@ লাইভ আপনার প্রশ্নের ব্যাকরণ থেকে বোঝা যায় যে ব্যবসায়িক কার্যাদি বাস্তবায়নে প্রযুক্তি ব্যবহারে কিছু ভুল আছে? আসুন এটি এইভাবে রাখা যাক: এটি ডোমেন এবং প্রযুক্তির মধ্যে সংযোগ নয় যা সমস্যা problem এটি বিভিন্ন বিমূর্ত স্তরগুলির মধ্যে মিলিত হচ্ছে। উদাহরণস্বরূপ AccountNumber উচিত জানি যে এটি একটি হিসাবে প্রতিনিধিত্ব করা যেতে পারে TextField। যদি অন্যরা ("ভিউ" এর মতো) এটি জানত, এটি এমন সংঘবদ্ধতা যা এর অস্তিত্ব নেই, কারণ component উপাদানটির অন্তর্ভুক্তগুলি কী কী রয়েছে তা জানতে হবে AccountNumber
রবার্ট ব্রুটিগাম

1

হতে পারে আমরা সঞ্চয়টি অন্য কোনও বস্তুর কাছে অর্পণ করতে পারি

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

public class Product {
    private String name;
    private Double price;

    void save(Storage storage) {
        storage.save( toString() );
    }
}

আপনি যদি কোনও লগ ফাইল বা একটি ডেটাবেস বা উভয়কেই সঞ্চয় করে থাকেন তবে এখানে পণ্যটির কোনও ধারণা নেই। আপনার 4 বা 40 টি ক্ষেত্র থাকলে এখানে সংরক্ষণের পদ্ধতিটির কোনও ধারণা নেই। এটি আলগাভাবে মিলিত হয়। সেটা একটা ভাল জিনিস.

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

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


এটি আসলে আমার প্রশ্নে পোস্ট করা কোড, তাই না? আমি একটি ব্যবহার করেছি Map, আপনি প্রস্তাবিত একটি Stringবা একটি List। তবে, @ ভয়েসফউউনরেসন তাঁর উত্তরে উল্লিখিত হিসাবে, মিলনটি এখনও রয়েছে, কেবল স্পষ্ট নয়। এটি কোনও ডাটাবেস বা লগ ফাইল উভয় ক্ষেত্রে সংরক্ষণ করার জন্য পণ্যটির ডেটা কাঠামোটি জানা এখনও অপ্রয়োজনীয়, কমপক্ষে যখন কোনও অবজেক্ট হিসাবে ফিরে পড়ুন।
ttulka

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


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

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

0

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

এই বিষয়ে আরও তথ্যের জন্য আমি দুর্দান্ত বইয়ের সুপারিশ করছি: স্কট মিললেট এবং নিক টিউনের "প্যাটার্নস, নীতি ও ডোমেন-চালিত ডিজাইনের অনুশীলন"

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