আপনি জাভা প্রকল্পগুলিতে প্যাকেজ নামকরণের জন্য কোন কৌশল ব্যবহার করেন এবং কেন? [বন্ধ]


88

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

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

  1. কার্যকরী: আপনার প্যাকেজগুলিকে ব্যবসায়ের ডোমেন অনুসারে তাদের পরিচয়ের পরিবর্তে তাদের ফাংশন অনুসারে নামকরণ to এর জন্য আর একটি শব্দ 'স্তর' অনুসারে নামকরণ করা হতে পারে। সুতরাং, আপনার কাছে * .ui প্যাকেজ এবং একটি * .ডোমেন প্যাকেজ এবং একটি * .কম প্যাকেজ রয়েছে। আপনার প্যাকেজগুলি উল্লম্বের চেয়ে অনুভূমিক টুকরা।

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

  2. যৌক্তিক: আপনার প্যাকেজগুলিকে তাদের ব্যবসায়ের ডোমেন পরিচয় অনুসারে নামকরণ এবং সেই প্যাকেজে কার্যকারিতার উল্লম্ব টুকরোগুলি সহ প্রতিটি ক্লাস স্থাপন করা।

    আমি এর আগে কখনও বলেছি বা শুনেছি না, তবে এটি আমার কাছে এক টন অর্থবোধ করে।

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

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

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

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

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


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

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

@ এলজেনসো: বলুন যে গ্রহটিকে বলুন :) গ্রহের ক্ষেত্রে প্রথম বিভাগটি হল "বৈশিষ্ট্যগুলি", যা মোতায়েনের একক এবং কার্যকারিতাও। "বৈশিষ্ট্য" এর ভিতরে, "প্লাগইনগুলি" থাকে যা সাধারণত স্তর দ্বারা বিভক্ত হয় - তবে একই "বৈশিষ্ট্য" এর মধ্যে থাকা প্লাগইনগুলি সর্বদা একসাথে মোতায়েন করা উচিত। আপনার যদি কেবল একক ডিপ্লোয়মেন্ট ইউনিট থাকে তবে প্রথমে স্তর দ্বারা ভাগ করে নেওয়া এবং কেবল তখন কার্যকারিতা দ্বারা যদিও তা বোধগম্য হতে পারে। একাধিক স্থাপনার ইউনিটগুলির সাথে, আপনি কেবল উপস্থাপনা স্তর স্থাপন করতে চান না - আপনি অতিরিক্ত কার্যকারিতা চান want
পিটার btibraný

আমার একটি প্রয়োগের ব্যবসায় স্তর সম্পর্কিত একটি নির্দিষ্ট প্রশ্ন রয়েছে, নামকরণের সম্মেলনটি কী হওয়া উচিত?
Bionix1441

উত্তর:


32

প্যাকেজ ডিজাইনের জন্য, আমি প্রথমে স্তর দ্বারা ভাগ করি, তারপরে অন্য কোনও কার্যকারিতা দ্বারা।

কিছু অতিরিক্ত নিয়ম রয়েছে:

  1. স্তরগুলি সাধারণ (নীচে) থেকে সুনির্দিষ্ট (শীর্ষে) স্ট্যাক করা হয়
  2. প্রতিটি স্তরের একটি সার্বজনীন ইন্টারফেস রয়েছে (বিমূর্ততা)
  3. একটি স্তর কেবলমাত্র অন্য স্তরের পাবলিক ইন্টারফেসের উপর নির্ভর করতে পারে (এনক্যাপসুলেশন)
  4. একটি স্তর কেবলমাত্র আরও সাধারণ স্তরগুলির উপর নির্ভর করতে পারে (উপর থেকে নীচে অবধি নির্ভরতা)
  5. একটি স্তর সাধারণত তার নীচে স্তর উপর নির্ভর করে

সুতরাং, উদাহরণস্বরূপ কোনও ওয়েব অ্যাপ্লিকেশনটির জন্য, আপনার অ্যাপ্লিকেশন স্তরটিতে নীচের স্তরগুলি থাকতে পারে (উপরে থেকে নীচে):

  • উপস্থাপনা স্তর: ইউআই তৈরি করে যা ক্লায়েন্ট স্তরতে প্রদর্শিত হবে
  • অ্যাপ্লিকেশন স্তর: যুক্তিযুক্ত যা একটি প্রয়োগের জন্য নির্দিষ্ট, রাষ্ট্রযোগ্য contains
  • পরিষেবা স্তর: ডোমেন দ্বারা কার্যবিধির গ্রুপ, রাজ্যহীন
  • ইন্টিগ্রেশন স্তর: ব্যাকএন্ড স্তরতে অ্যাক্সেস সরবরাহ করে (ডিবি, জেমস, ইমেল, ...)

ফলাফল প্যাকেজ বিন্যাসের জন্য, এগুলি কিছু অতিরিক্ত নিয়ম:

  • প্রতিটি প্যাকেজ নামের মূল হয় <prefix.company>.<appname>.<layer>
  • একটি স্তর ইন্টারফেস কার্যকারিতা দ্বারা আরও বিভক্ত: <root>.<logic>
  • একটি স্তরের ব্যক্তিগত প্রয়োগটি ব্যক্তিগত সহকারে উপস্থাপিত হয়: <root>.private

এখানে একটি উদাহরণ লেআউট।

উপস্থাপনা স্তরটি দেখার প্রযুক্তি দ্বারা এবং বিকল্পভাবে (গ্রুপগুলির) অ্যাপ্লিকেশন দ্বারা ভাগ করা হয়।

com.company.appname.presentation.internal
com.company.appname.presentation.springmvc.product
com.company.appname.presentation.servlet
...

অ্যাপ্লিকেশন স্তরটি ব্যবহারের ক্ষেত্রে বিভক্ত।

com.company.appname.application.lookupproduct
com.company.appname.application.internal.lookupproduct
com.company.appname.application.editclient
com.company.appname.application.internal.editclient
...

পরিষেবা স্তরটি ব্যবসায় ডোমেনগুলিতে বিভক্ত হয়, ব্যাকএন্ড স্তরতে ডোমেন লজিক দ্বারা প্রভাবিত।

com.company.appname.service.clientservice
com.company.appname.service.internal.jmsclientservice
com.company.appname.service.internal.xmlclientservice
com.company.appname.service.productservice
...

ইন্টিগ্রেশন স্তরটি 'প্রযুক্তি' এবং অ্যাক্সেস অবজেক্টগুলিতে বিভক্ত।

com.company.appname.integration.jmsgateway
com.company.appname.integration.internal.mqjmsgateway
com.company.appname.integration.productdao
com.company.appname.integration.internal.dbproductdao
com.company.appname.integration.internal.mockproductdao
...

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

আমি কেন মনে করি উল্লম্ব পদ্ধতির এত ভাল নয়?

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

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


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

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

8
এই নিবন্ধটি বেশ সুন্দরভাবে ব্যাখ্যা করেছে যে প্যাকেজ-বাই-লেয়ারের পরিবর্তে প্যাকেজ-বাই-বৈশিষ্ট্যটি ব্যবহার করা কেন ভাল ।
টম

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

18

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

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

স্পষ্টতই, সমস্ত ধরণের সফ্টওয়্যার একরকম নয় এবং উল্লম্ব ভাঙ্গন কিছু প্রকল্পে পুনরায় ব্যবহারযোগ্যতা এবং ঘনিষ্ঠতা-পরিবর্তনের লক্ষ্য অর্জনের ক্ষেত্রে বিবেচনা করতে পারে।


ধন্যবাদ, এটি খুব স্পষ্ট Aআমি এই প্রশ্নে বলেছি, আমি মনে করি আপনি যতক্ষণ প্রযুক্তির সন্ধান করতে পারবেন তার চেয়ে কার্যকারিতার উল্লম্ব টুকরা বদলে যাওয়ার চেয়ে অনেক কম। এটি কি আপনার অভিজ্ঞতা হয়নি?
টিম দর্শক

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

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


@ বুউনগুইন প্যাকেজ ডিজাইনের নীতিগুলির লিঙ্কটি নষ্ট হয়ে গেছে।
জননীব 25'15

5

উভয় বিভাগের সাধারণত উপস্থিত থাকে। শীর্ষ থেকে, স্থাপনার ইউনিট রয়েছে are এগুলির নামকরণ করা হয়েছে 'যৌক্তিকভাবে' (আপনার শর্তে, মনে করুন গ্রহের বৈশিষ্ট্যগুলি)। ডিপ্লোয়মেন্ট ইউনিটের অভ্যন্তরে, আপনার প্যাকেজগুলির কার্যকরী বিভাগ রয়েছে (ভাবেন এক্সলিপ প্লাগইন)।

উদাহরণস্বরূপ, বৈশিষ্ট্য com.feature, এবং এটি নিয়ে গঠিত com.feature.client, com.feature.coreএবং com.feature.uiপ্লাগ-ইন। প্লাগিনগুলির অভ্যন্তরে, আমার অন্যান্য প্যাকেজগুলির সাথে আমার খুব সামান্য বিভাজন রয়েছে, যদিও এটি খুব অস্বাভাবিকও নয়।

আপডেট: বিটিডব্লিউ, ইনফিউকিউ: http://www.infoq.com/preferencesations/code-organization-large-projects- এ কোড সংগঠন সম্পর্কে জুয়ারজেন হোলারের দুর্দান্ত আলোচনা রয়েছে । জুয়েরজেন স্প্রিং এর অন্যতম স্থপতি এবং এই স্টাফ সম্পর্কে অনেক কিছু জানেন knows


আমি বেশ অনুসরণ করি না। সাধারণত আপনি com.apache.wicket.x দেখতে পাবেন যেখানে এক্স হয় কার্যক্ষম বা যৌক্তিক। আমি সাধারণত com.x দেখতে পাই না আমি মনে করি আপনি বলছেন যে আপনি একটি com.company.project.feature.layer কাঠামো সঙ্গে যেতে হবে? আপনার কি কারণ আছে?
টিম দর্শক

কারণ হ'ল "com.company.project.feature" স্থাপনার একক। এই স্তরে কিছু বৈশিষ্ট্য optionচ্ছিক, এবং এড়িয়ে যেতে পারে (যেমন মোতায়েন নয়)। তবে বৈশিষ্ট্যের অভ্যন্তরে জিনিসগুলি alচ্ছিক নয় এবং আপনি সাধারণত সেগুলি চান। এখানে স্তরগুলি দ্বারা বিভাজন করা আরও অর্থবোধ করে।
পিটার btibraný

4

বেশিরভাগ জাভা প্রকল্পগুলি আমি প্রথমে জাভা প্যাকেজগুলি টুকরো টুকরো টুকরো টুকরো করার পরে কাজ করেছি then

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


কি মত চেহারা হতে পারে? ডোমেইন ডটপ্যানি.প্রজেক্ট.ফুনশন.লোগিকাল্লাইস?
টিম দর্শক

যথেষ্ট! egdcpweb.profiles, dcpweb.regifications, dcpapis, dcppers شتون ইত্যাদি সাধারণত বেশ ভালভাবে কাজ করে, আপনার মাইলেজ আলাদা হতে পারে। আপনি ডোমেন মডেলিং ব্যবহার করছেন কিনা তাও নির্ভর করে - আপনার যদি একাধিক ডোমেন থাকে তবে আপনি প্রথমে ডোমেন দ্বারা বিভক্ত হতে চাইতে পারেন।
বেন হার্ডি

আমি ব্যক্তিগতভাবে বিপরীত, যৌক্তিক তারপর কার্যকরী পছন্দ। অ্যাপলস.আরপিসি, আপেল.মডেল এবং তারপরে কলা.মডেল, কলা.স্টোর
এমপি।

সমস্ত ওয়েব স্টাফ একসাথে ভাগ করে নেওয়ার চেয়ে সমস্ত অ্যাপল স্টাফ একসাথে গ্রুপ করার পক্ষে আরও মূল্য রয়েছে is
এমপি।

3

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

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


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

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

3

আমি ব্যক্তিগতভাবে গ্রুপিং ক্লাসগুলি যুক্তিযুক্তভাবে পছন্দ করি তবে এর মধ্যে প্রতিটি কার্যকরী অংশগ্রহণের জন্য একটি সাবপ্যাকেজ অন্তর্ভুক্ত থাকে।

প্যাকেজিংয়ের লক্ষ্যগুলি

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

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

আমার যৌক্তিক প্যাকেজিং কাঠামোর একটি উদাহরণ

উদাহরণস্বরূপ উদ্দেশ্যে দুটি মডিউল নামকরণ করতে দেয় - একটি প্যাকেজ গাছের একটি নির্দিষ্ট শাখার অধীনে শ্রেণিবদ্ধ করে এমন ধারণা হিসাবে নাম মডিউলটি ব্যবহার করে ill

আপেল.মডেল আপেল স্টোর কলা.মডেল কলা.স্টোর

সুবিধাদি

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

অন্যান্য লজিকাল ভি কার্যকরী সুবিধা

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

কার্যকারিতা কেন?

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

বিকাশকারী সিস্টেমে পরিবর্তন

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


"যখন বিকাশকারীরা [...] প্যাকেজ ট্রিয়ের সমস্ত অঞ্চল থেকে ফাইলগুলি করে।" আপনি যখন বলছেন এটি নির্বোধ বলে ঠিক আছে আপনি ঠিক বলেছেন। কারণ এই ঠিক সঠিক প্রলেপের বিন্দু হল: পরিবর্তন না আবেদনের সমগ্র গঠন মাধ্যমে লহরী।
এলজেন্সো

পরামর্শের জন্য ধন্যবাদ. আমি নিশ্চিত না যে আমি আপনাকে স্পষ্টভাবে বুঝতে পারছি। আমি বিশ্বাস করি আপনি লজিকাল প্যাকেজগুলির জন্য তর্ক করার চেষ্টা করছেন, আমি কেন তা ঠিক পরিষ্কার করছি না। আপনি নিজের উত্তরটি আরও পরিষ্কার করার চেষ্টা করতে পারেন, সম্ভবত পুনরায় রেকর্ডিং? ধন্যবাদ!
টিম দর্শক

3

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

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

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

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

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

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

তবে ক্রস-ওভার মামলা রয়েছে। যদি আমার উইজেট পরিষেবাটি অনেকগুলি লজিকাল ডোমেন (বৈশিষ্ট্য) ব্যবহার করে তবে আমি একটি " com.myorg.common.service " প্যাকেজ তৈরি করতে পারি । এখানে আরও ভাল সম্ভাবনা রয়েছে যে আমি বৈশিষ্ট্যগুলি জুড়ে পুনরায় ব্যবহারের যোগ্য হওয়ার লক্ষ্য নিয়ে ক্লাস তৈরি করি এবং " com.myorg.common.ui.helpers। " এবং " com.myorg.common.util " এর মতো প্যাকেজগুলি শেষ করি । আমি এমনকি এই সমস্ত "সাধারণ" ক্লাসগুলি একটি পৃথক প্রকল্পে স্থানান্তর করতে পারি এবং এগুলিকে আমার ব্যবসায়-অ্যাপ্লিকেশনটিতে মায়োরগ-কমন্স.জার নির্ভরতা হিসাবে অন্তর্ভুক্ত করতে পারি।


2

এটি আপনার যৌক্তিক প্রক্রিয়াগুলির গ্রানুলারিটির উপর নির্ভর করে?

যদি তারা একক হয়ে থাকে তবে প্রায়শই আপনার জন্য নতুন প্যাকেজ না হয়ে উত্স নিয়ন্ত্রণে একটি নতুন প্রকল্প থাকে।

আমি এই মুহুর্তে যে প্রকল্পটি করছি তা লজিক্যাল বিভাজনের দিকে ধাবিত হচ্ছে, এখানে জাইথন ​​দিকের জন্য একটি প্যাকেজ রয়েছে, একটি নিয়ম ইঞ্জিনের জন্য একটি প্যাকেজ, foo, বার, বিংলিওজল ইত্যাদির জন্য প্যাকেজগুলি I'm XML প্যাকেজ (যা আমি আগে করেছি) না হয়ে সেই প্যাকেজের মধ্যে প্রতিটি মডিউলটির জন্য লেখকগণ, যদিও এখনও একটি মূল এক্সএমএল প্যাকেজ থাকবে যেখানে ভাগ করে যুক্তি যুক্ত হবে। তবে এর একটি কারণ হ'ল এটি এক্সটেনসিবল (প্লাগইন) হতে পারে এবং সুতরাং প্রতিটি প্লাগইনকে তার এক্সএমএল (বা ডাটাবেস, ইত্যাদি) কোডও সংজ্ঞায়িত করতে হবে, সুতরাং এটি কেন্দ্রীভূত করার পরে সমস্যাগুলি প্রবর্তন করতে পারে।

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

যা প্রয়োজন তা হ'ল ট্যাগযুক্ত নামস্থান। কিছু জাইথন ​​কার্যকারিতার জন্য একটি এক্সএমএল পার্সারকে জ্যথন এবং এক্সএমএল উভয়ই ট্যাগ করা যেতে পারে, একটি বা অন্যটি বেছে নেওয়ার পরিবর্তে।

অথবা আমি wibbling করছি।


আমি আপনার বক্তব্য পুরোপুরি বুঝতে পারি না। আমি মনে করি আপনি যা বলছেন তা হ'ল আপনার প্রকল্পের জন্য সবচেয়ে কার্যকর এবং আপনার পক্ষে যুক্তিযুক্ত কিছুটা কার্যকরীভাবে যুক্তিযুক্ত যুক্তিযুক্ত হওয়া উচিত this এর কোনও নির্দিষ্ট ব্যবহারিক কারণ রয়েছে?
টিম দর্শক

যেমনটি আমি বলেছিলাম, আমি অন্তর্নির্মিত কার্যকারিতা বাড়ানোর জন্য প্লাগইন আনতে যাচ্ছি। একটি প্লাগইন এর এক্সএমএল (এবং শেষ পর্যন্ত ডিবিতে) লিখতে এবং কার্যকারিতা সরবরাহ করতে সক্ষম হতে চলেছে। সুতরাং আমার কাছে কি com.xx.feature.xml বা com.xx.xml.feature আছে? প্রাক্তনটি আরও পরিচ্ছন্ন বলে মনে হচ্ছে।
জিবিবি

2

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

আমার জন্য, অনুভূমিকের চেয়ে উল্লম্ব নামকরণ সিস্টেমে বজায় রাখা এবং ভিজ্যুয়ালাইজ করা এটি অনেক সহজ। উপাদান 1.display এর উপাদান 2.dataaccess এর একটি রেফারেন্স থাকলে, ডিসপ্লে.কম্পোনাল 1 এর ডেটাস্যাক্সের একটি রেফারেন্স রয়েছে তার চেয়ে বেশি সতর্কতা ঘন্টা বন্ধ করে দেয়। উপাদান 2।

অবশ্যই, উভয় দ্বারা ভাগ করা উপাদানগুলি তাদের নিজস্ব প্যাকেজে যায়।


আমি আপনাকে তখন বুঝতে পারছি, আপনি উল্লম্ব নামকরণের সম্মেলনের পক্ষে ছিলেন ocate আমি মনে করি এটি যখন একটি * .utils প্যাকেজটির জন্য হয়, যখন আপনার একাধিক টুকরো জুড়ে ক্লাসের প্রয়োজন হয়।
টিম দর্শক

2

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

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

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


1

আমি ব্যক্তিগতভাবে ফাংশনাল নামকরণের জন্য যেতে হবে। সংক্ষিপ্ত কারণ: এটি কোড সদৃশতা বা নির্ভরশীল দুঃস্বপ্ন এড়িয়ে চলে।

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

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

যৌক্তিক নামকরণের ক্ষেত্রে আমি আপনার প্রতিটি পয়েন্টকে আরও স্পষ্টভাবে প্রতিক্রিয়া জানাতে চেষ্টা করব।

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

  2. এটি মূলত নির্ভর করে আপনি কীভাবে আপনার প্রকল্পটি আঁকছেন on অবশ্যই, যৌক্তিক এবং কার্যকরী দর্শনটি অরথোগোনাল। সুতরাং আপনি যদি একটি নামকরণের কনভেনশন ব্যবহার করেন তবে কিছু অর্ডার রাখতে আপনার অন্য নামটি ক্লাসের নামগুলিতে প্রয়োগ করতে হবে, বা একটি নামকরণের কনভেনশন থেকে অন্য গভীরতায় কাঁটাচামচ করা উচিত।

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

  4. বড়, বাণিজ্যিক প্রকল্পগুলিতে, প্রযুক্তি পরিবর্তনগুলি আপনার বিশ্বাসের চেয়ে প্রায়শই ঘটে। উদাহরণস্বরূপ, আমি ইতিমধ্যে এক্সএমএল পার্সারের 3 বার, ক্যাচিং প্রযুক্তির 2 বার এবং জিওলোক্যালিজেশন সফ্টওয়্যারটির 2 বার পরিবর্তন করতে হয়েছিল। ভাল জিনিস আমি উত্সর্গীকৃত প্যাকেজে সমস্ত কৌতূহল বিবরণ লুকিয়ে রেখেছিলাম ...


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

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

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

1

প্যাকেজগুলি মোটেও ব্যবহার না করা একটি আকর্ষণীয় পরীক্ষা (রুট প্যাকেজ বাদে))

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

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


0

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

আমি প্রায়শই এই সুরক্ষিত বা ডিফল্ট পদ্ধতিগুলি অন্য কোথাও ব্যবহার করি না - সম্ভবত ক্লাসের ইউনিট পরীক্ষাগুলি ব্যতীত - তবে আমি যখন করি তখন এটি সর্বদা একই স্তরের ক্লাস থেকে আসে


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

আমি সুরক্ষিত এবং ডিফল্ট পদ্ধতিগুলি প্রায় কখনও ব্যবহার করি না। 99% হয় পাবলিক বা বেসরকারী। কিছু ব্যতিক্রম: (1) শুধুমাত্র ইউনিট পরীক্ষা দ্বারা ব্যবহৃত পদ্ধতিগুলির জন্য ডিফল্ট দৃশ্যমানতা, (2) সুরক্ষিত বিমূর্ত পদ্ধতি যা কেবল বিমূর্ত বেস শ্রেণি থেকে ব্যবহৃত হয়।
এসকো লুন্তটোলা

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

0

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


উভয় পথে যাওয়ার কি কোনও কারণ আছে?
টিম দর্শক

সম্পদ শ্রেণি দ্বারা বিভক্ত করা (আরও সাধারণভাবে: ব্যবসায়িক ডোমেন দ্বারা) কোডের মাধ্যমে নতুন লোকের পক্ষে তাদের পথ খুঁজে পাওয়া সহজ করে তোলে। ফাংশন দ্বারা বিভক্ত করা encapsulation জন্য ভাল। আমার জন্য, জাভাতে "প্যাকেজ" অ্যাক্সেস সি ++ এর "বন্ধু" এর মতো।
কোয়ান্ট_দেব

@ কোয়ান্ট_দেব আমি "..এর সাথে ফাংশন এনক্যাপসুলেশনের পক্ষে ভাল" এর সাথে আমি একমত নই। আমার ধারণা আপনার সম্পূর্ণ বিপরীতটি সত্য is এছাড়াও, কেবল "সুবিধার্থে" বাছাই করবেন না। প্রত্যেকের জন্য একটি মামলা আছে (আমার উত্তর দেখুন)।
i3ensays

-3

আমার অভিজ্ঞতা থেকে, পুনরায় ব্যবহারযোগ্যতা সমাধানের চেয়ে আরও বেশি সমস্যা তৈরি করে। সর্বশেষ ও সস্তা প্রসেসর এবং মেমরির সাহায্যে, আমি পুনরায় ব্যবহারের জন্য দৃ tight়ভাবে সংহত করার চেয়ে কোডের নকলকে পছন্দ করব।


4
কোড পুনঃব্যবহার হার্ডওয়্যারের দাম সম্পর্কে নয় তবে কোড রক্ষণাবেক্ষণের ব্যয় সম্পর্কে।
ব্যবহারকারী 2793390

4
সম্মত হন, তবে একটি সাধারণ মডিউলে কোনও কিছু ঠিক করা পুরো কোডকে প্রভাবিত করে না। আপনি কোন রক্ষণাবেক্ষণ ব্যয়ের কথা বলছেন?
রঘু কস্তুরি

4
একটি মডিউল মধ্যে একটি বাগ ফিক্স পুরো অ্যাপ্লিকেশন প্রভাবিত করা উচিত। আপনি কেন একই বাগ একাধিকবার ঠিক করতে চান?
ব্যবহারকারী 2793390

আপনার নিজের কোডটি লেখার পরে বছরের কয়েক বছর ধরে রাখতে হবে? আমার আগে যারা এসেছিল তাদের আমি অভিশাপ দিয়েছি যারা কম্পিউটার প্রোগ্রামিংয়ের ক্ষেত্রে এইরকম অপ্রয়োজনীয় দৃষ্টিভঙ্গি নিয়েছিল। নকলের কারণে আপনার কোডটি একাধিকবার ঠিক করতে আমার সময় ব্যয় করা উভয়ই অকার্যকর এবং বিরক্তিকর। রিডানডেনসি সেই ভয়ানক ভুলগুলির মধ্যে একটি যা আমি শেষ পর্যন্ত প্রদান করেছি।
ডেভিড রেক্টর
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.