যদি মডেলটি ডেটাটিকে বৈধতা দিচ্ছে, তবে এটি খারাপ ইনপুটটিতে ব্যতিক্রম ছোঁড়া উচিত নয়?


9

এই এই প্রশ্নটি পড়ে মনে হয় যে ব্যবহারকারী ইনপুটকে বৈধতা দেওয়ার ক্ষেত্রে ব্যতিক্রম ছুঁড়ে ফেলা উচিত।

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

আমার ভিত্তিটি কি ব্যবসায়ের স্তরে বৈধতা হওয়া উচিত?

আমি কি করবো

সুতরাং আমার কোডটি সাধারণত এইভাবে শেষ হয়:

<?php
class Person
{
  private $name;
  private $age;

  public function setName($n) {
    $n = trim($n);
    if (mb_strlen($n) == 0) {
      throw new ValidationException("Name cannot be empty");
    }
    $this->name = $n;
  }

  public function setAge($a) {
    if (!is_int($a)) {
      if (!ctype_digit(trim($a))) {
        throw new ValidationException("Age $a is not valid");
      }
      $a = (int)$a;
    }
    if ($a < 0 || $a > 150) {
      throw new ValidationException("Age $a is out of bounds");
    }
    $this->age = $a;
  }

  // other getters, setters and methods
}

কন্ট্রোলারে, আমি কেবলমাত্র মডেলটির কাছে ইনপুট ডেটাটি পাস করি এবং ব্যবহারকারীর ত্রুটি (গুলি) দেখানোর জন্য নিক্ষিপ্ত ব্যতিক্রমগুলি ধরি:

<?php
$person = new Person();
$errors = array();

// global try for all exceptions other than ValidationException
try {

  // validation and process (if everything ok)
  try {
    $person->setAge($_POST['age']);
  } catch (ValidationException $e) {
    $errors['age'] = $e->getMessage();
  }

  try {
    $person->setName($_POST['name']);
  } catch (ValidationException $e) {
    $errors['name'] = $e->getMessage();
  }

  ...
} catch (Exception $e) {
  // log the error, send 500 internal server error to the client
  // and finish the request
}

if (count($errors) == 0) {
  // process
} else {
  showErrorsToUser($errors);
}

এটি কি একটি খারাপ পদ্ধতি?

বিকল্প পদ্ধতি

আমি কি isValidAge($a)সত্য / মিথ্যা প্রত্যাবর্তনের জন্য পদ্ধতি তৈরি করতে এবং তারপরে নিয়ামক থেকে কল করতে পারি?

<?php
class Person
{
  private $name;
  private $age;

  public function setName($n) {
    $n = trim($n);
    if ($this->isValidName($n)) {
      $this->name = $n;
    } else {
      throw new Exception("Invalid name");
    }
  }

  public function setAge($a) {
    if ($this->isValidAge($a)) {
      $this->age = $a;
    } else {
      throw new Exception("Invalid age");
    }
  }

  public function isValidName($n) {
    $n = trim($n);
    if (mb_strlen($n) == 0) {
      return false;
    }
    return true;
  }

  public function isValidAge($a) {
    if (!is_int($a)) {
      if (!ctype_digit(trim($a))) {
        return false;
      }
      $a = (int)$a;
    }
    if ($a < 0 || $a > 150) {
      return false;
    }
    return true;
  }

  // other getters, setters and methods
}

এবং নিয়ন্ত্রকটি মূলত একই রকম হবে, চেষ্টা / ধরার পরিবর্তে এখন / অন্যথায় থাকলে এখন রয়েছে:

<?php
$person = new Person();
$errors = array();
if ($person->isValidAge($age)) {
  $person->setAge($age);
} catch (Exception $e) {
  $errors['age'] = "Invalid age";
}

if ($person->isValidName($name)) {
  $person->setName($name);
} catch (Exception $e) {
  $errors['name'] = "Invalid name";
}

...

if (count($errors) == 0) {
  // process
} else {
  showErrorsToUser($errors);
}

তো এখন আমার কি করা উচিৎ?

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


আমি "আসল" কোডটি সামলানোর জন্য ValidationExceptionএবং অন্যান্য ব্যতিক্রমগুলি কিছুটা সংশোধন করেছি
কার্লোস ক্যাম্প্ডারেস

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

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

বৈধতাগুলির জন্য ব্যতিক্রমগুলি প্রক্রিয়াতে প্রকারের ইনজেকশনের অভিনব উপায়। আপনি যেমন কোনও বৈধতা ইন্টারফেস প্রয়োগ করে এমন একটি বস্তু ফিরে দিয়ে একই ফলাফল অর্জন করতে পারেন IValidateResults
প্রতিক্রিয়াশীল

উত্তর:


7

আমি অতীতে যে পদ্ধতির ব্যবহার করেছি তা হ'ল সমস্ত বৈধতা যুক্তি নিবেদিত বৈধকরণের ক্লাসে রাখা।

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

এই পদ্ধতির অনুসরণ করে আপনি কোন স্তরটিতে যা ঘটে তার উপর নির্ভর করে বৈধতা ত্রুটিগুলি আলাদাভাবে আচরণ করতে পারেন:

  • যদি ডেটা ইন্টিগ্রিটি বৈধকরণ মডেলটিতে ব্যর্থ হয়, তবে একটি ব্যতিক্রম ছুঁড়ে দিন।
  • যদি ব্যবহারকারী ইনপুট বৈধকরণ উপস্থাপনা স্তরটিতে ব্যর্থ হয়, তবে একটি সহায়ক টিপ প্রদর্শন করুন এবং আপনার মডেলটির মানটি ধাক্কা দিতে বিলম্ব করুন।

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

আমি সম্মত হই যে বৈধতার জন্য পুরো নতুন ক্লাস যুক্ত করা ওভারকিল, কমপক্ষে এই তুলনামূলক সহজ ক্ষেত্রে। এটি আরও অনেক জটিলতার সমস্যার জন্য দরকারী হতে পারে।

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

1
মডেল থেকে বৈধতা পৃথক পৃথক একই সাথে সংযোগ এবং সংহতি অবস্থান থেকে বোঝা যায়। এই সাধারণ দৃশ্যে এটি ওভারকিল হতে পারে তবে পৃথক ভ্যালিডেটর শ্রেণিকে আরও বেশি আবেদনময়ী করতে এটি কেবল একটি একক "ক্রস ফিল্ড" বৈধকরণের নিয়ম নেবে।
শেঠ এম

8

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

আপনি এবং আপনার সহকর্মীরা যদি এতে খুশি হন তবে আমি কোনও পরিবর্তন করার দরকার নেই।

বাস্তববাদী দৃষ্টিকোণ থেকে একমাত্র যেটি প্রশ্নবিদ্ধ তা হ'ল আপনি Exceptionনির্দিষ্ট কিছু নির্দিষ্ট করে না ফেলে নিক্ষেপ করছেন । সমস্যাটি হ'ল আপনি যদি ধরেন তবে আপনি Exceptionব্যতিক্রমগুলি ধরা শেষ করতে পারেন যা ব্যবহারকারীর ইনপুটকে বৈধতা দেওয়ার সাথে কোন সম্পর্ক রাখে না।


এখন অনেক লোক আছেন যারা বলেন "ব্যতিক্রম কেবল ব্যতিক্রমী জিনিসের জন্য ব্যবহার করা উচিত, এবং এক্সওয়াইজেড ব্যতিক্রমী নয়" say (উদাহরণস্বরূপ, @ ড্যান 1111 এর উত্তর ... যেখানে তিনি ব্যবহারকারীর ত্রুটিগুলি "পুরোপুরি স্বাভাবিক" হিসাবে লেবেল করেছেন))

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

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

ব্যতিক্রম বিরুদ্ধে যুক্তি যে, তারা হয় করতে কোড কঠিন বুঝতে ভুলবেন না। তবে ফ্লিপ-সাইডটি হ'ল যখন সেগুলি যথাযথভাবে ব্যবহৃত হয়, তারা কোড বোঝা সহজ করে তুলতে পারে।


সংক্ষেপে - ব্যতিক্রমগুলি ব্যবহার বা না ব্যবহারের সিদ্ধান্তটি মেধাগুলি মাপার পরে নেওয়া উচিত ... এবং কিছু সরলবাদী গোড়ামির ভিত্তিতে নয়।


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

ভ্যালিডেশনএক্সসেপশন এবং অন্যান্য ব্যতিক্রমগুলি / সিসি @ ড্যান 1111 সামলানোর জন্য আমি "আসল" কোডটি কিছুটা পরিবর্তন করেছি
কার্লোস ক্যাম্পার্ডার্স

1
+1, প্রতিটি পদ্ধতি কলের রিটার্নের মান পরীক্ষা করে নেওয়ার অন্ধকার যুগে ফিরে যাওয়ার চেয়ে আমার বর্ণনামূলক বৈধকরণের ধারণাটি বেশি ছিল। সাধারণ কোড = সম্ভাব্য কম ত্রুটি।
হেইনজি

2
@ dan1111 - আমি আপনার মতামত দেওয়ার অধিকারকে সম্মান করি, আপনার মন্তব্যে কিছুই মতামত ব্যতীত অন্য কিছু নয় । বৈধতার "স্বাভাবিকতা" এবং বৈধতা ত্রুটিগুলি পরিচালনা করার পদ্ধতির মধ্যে কোনও যৌক্তিক সংযোগ নেই। আপনি যা করছেন তা হ'ল ডগমা আবৃত্তি করছে।
স্টিফেন সি

@ স্টেফেনসি, প্রতিবিম্বের পরে আমি অনুভব করি যে আমি আমার মামলাটি খুব দৃ .়তার সাথে জানিয়েছি। আমি সম্মত হই যে এটি ব্যক্তিগত পছন্দ বেশি।

6

আমার মতে, অ্যাপ্লিকেশন ত্রুটি এবং ব্যবহারকারীর ত্রুটির মধ্যে পার্থক্য করা দরকারী এবং কেবলমাত্র পূর্বের ব্যতিক্রমগুলি ব্যবহার করুন।

  • ব্যতিক্রমগুলি এমন জিনিসগুলিকে আচ্ছাদিত করে যা আপনার প্রোগ্রামকে যথাযথভাবে সম্পাদন করা থেকে বিরত করে

    এগুলি অপ্রত্যাশিত ঘটনা যা আপনাকে চালিয়ে যাওয়া থেকে বিরত করে এবং তাদের নকশা এটি প্রতিফলিত করে: তারা সাধারণ সম্পাদন ভঙ্গ করে এবং এমন জায়গায় যায় যা ত্রুটি পরিচালনার অনুমতি দেয়।

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

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

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

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

আপনার মূল কোডটি সমস্যাযুক্ত:

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

বিকল্প কোডটিতেও সমস্যা রয়েছে:

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

প্রস্তাবিত নকশা

  • মেক setAge()আগমন সাফল্যের সত্য এবং ব্যর্থতা উপর মিথ্যা।

  • এর রিটার্ন মানটি পরীক্ষা করুন setAge()এবং যদি এটি ব্যর্থ হয় তবে ব্যবহারকারীকে অবহিত করুন যে বয়সটি অবৈধ ছিল, কোনও ব্যতিক্রম ছাড়াই নয়, তবে একটি সাধারণ ক্রিয়া যা ব্যবহারকারীকে ত্রুটি প্রদর্শন করে।


তাহলে আমি এটি কিভাবে করব? বিকল্প প্রস্তাব দিয়ে আমি প্রস্তাব করেছি বা সম্পূর্ণ আলাদা কিছু নিয়ে যা আমি ভাবিনি? এছাড়াও, আমার ভিত্তিটি কি "ব্যবসায়ের স্তরে বৈধকরণ হওয়া উচিত" মিথ্যা?
কার্লোস ক্যাম্পাদ্রেস

@ কার্লোস ক্যাম্পডারেস, আপডেটটি দেখুন; আপনি মন্তব্য হিসাবে আমি তথ্য যোগ করা ছিল। আপনার মূল ডিজাইনের সঠিক স্থানে বৈধতা ছিল, তবে সেই বৈধতাটি সম্পাদন করতে ব্যতিক্রমগুলি ব্যবহার করা ভুল ছিল।

বিকল্প পদ্ধতিটি setAgeআবার যাচাই করতে বাধ্য করে , তবে যুক্তিটি মূলত "যদি এটি বৈধ হয় তবে নির্ধারিত বয়সে অন্যটি বাদ দিন" এটি আমাকে আবার স্কোয়ারে নিয়ে যায় না।
কার্লোস ক্যাম্পাদ্রেস

2
বিকল্প পদ্ধতি এবং প্রস্তাবিত নকশা দিয়ে আমি উভয়ই দেখতে পাচ্ছি একটি সমস্যা হ'ল বয়সটি কেন অবৈধ ছিল তা পার্থক্যের দক্ষতা হারাবে। এটা সত্য বা কোন ত্রুটির স্ট্রিং (হাঁ, পিএইচপি soooo মলিন হয়) ফিরে যাওয়ার করা সম্ভব হয়েছে, কিন্তু এই, সমস্যা অনেক হতে পারে কারণ "The entered age is out of bounds" == trueএবং মানুষ সবসময় ব্যবহার করা উচিত ===, তাই এই পদ্ধতির সমস্যা এটা করার চেষ্টা করে চেয়ে বেশি সমস্যাযুক্ত হবে সমাধান করুন
কার্লোস ক্যাম্পার্ডার্স

2
তবে অ্যাপ্লিকেশনটির কোডিং করা সত্যই ক্লান্তিকর কারণ setAge()আপনি যে কোনও জায়গায় যে কোনও কিছু করেন না কেন, আপনাকে এটি পরীক্ষা করে দেখতে হবে really ব্যতিক্রম ছোঁড়ার অর্থ হ'ল সবকিছু ঠিকঠাক হয়ে গেছে তা পরীক্ষা করার জন্য মনে রাখার বিষয়ে আপনার চিন্তা করা উচিত নয়। আমি এটি দেখতে পাচ্ছি, কোনও অ্যাট্রিবিউট / সম্পত্তিতে একটি অবৈধ মান সেট করার চেষ্টা করা ব্যতিক্রমী কিছু এবং তারপরে, নিক্ষেপ করার মতো Exception। এটি ডাটাবেস থেকে বা ব্যবহারকারীর কাছ থেকে ইনপুট পাচ্ছে কিনা তা মডেলটির উচিত নয়। এটি কখনও খারাপ ইনপুট গ্রহণ করা উচিত নয়, তাই আমি দেখি যে সেখানে ব্যতিক্রম ছুঁড়ে দেওয়া বৈধ is
কার্লোস ক্যাম্পাদ্রেস

4

আমার দৃষ্টিকোণ থেকে (আমি জাভা লোক) আপনি একে প্রথম উপায়ে কীভাবে প্রয়োগ করেছিলেন এটি সম্পূর্ণ বৈধ।

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

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

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


4

আমার হাস্কেল টুপি চালু করার সাথে উভয় পদ্ধতিরই ভুল are

ধারণাটিগতভাবে যা ঘটে তা হ'ল আপনার প্রথমে একগুচ্ছ বাইট রয়েছে এবং পার্সিং এবং যাচাইকরণের পরে আপনি একটি ব্যক্তি তৈরি করতে পারেন।

ব্যক্তির কিছু নির্দিষ্ট আগ্রাসী থাকে যেমন নাম এবং বয়সের ছদ্মবেশ।

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

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

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

Person p = new Person.Builder().setName(name).setAge(age).build();

বা আরও ভার্জোজ:

Person.Builder builder = new Person.Builder();
builder.setName(name);
builder.setAge(age);
Person p = builder.build();
// Person object must have name and age here

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


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

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

এটি এখনও প্রশ্নের উত্তর দেয় না (কমপক্ষে সম্পূর্ণ না)। আপনি কীভাবে পৃথক ত্রুটি বার্তাগুলি বিল্ডার শ্রেণি থেকে কল স্ট্যাক অব ভিউতে পাস করবেন তা ব্যাখ্যা করতে পারেন?
সাইফার

তিনটি সম্ভাবনা: বিল্ড () ওপির প্রথম উদাহরণের মতো নির্দিষ্ট ব্যতিক্রম ছুঁড়ে ফেলতে পারে। এখানে সর্বজনীন সেট <স্ট্রিং> বৈধতা () থাকতে পারে যা মানব পাঠযোগ্য ত্রুটির একটি সেট দেয়। আই 18 এন-রেডি ত্রুটির জন্য একটি সর্বজনীন সেট <এরর> বৈধতা () দিন) মুল বক্তব্যটি হ'ল এটি কোনও ব্যক্তি অবজেক্টে রূপান্তরকালে ঘটে।
ব্যবহারকারী 239558

2

সাধারণ মানুষের কথায়:

প্রথম পদ্ধতির সঠিক এক।

দ্বিতীয় পদ্ধতিটি ধরে নিয়েছে যে business ব্যবসায়িক ক্লাসগুলি কেবল those নিয়ন্ত্রকরা কল করবেন এবং এগুলি অন্য প্রসঙ্গে থেকে কখনই ডাকা হবে না।

ব্যবসায়ের ক্লাসগুলিতে অবশ্যই ব্যবসায়ের নিয়ম লঙ্ঘন হওয়ার সময় একটি ব্যতিক্রম ছুঁড়ে ফেলা উচিত।

কন্ট্রোলার বা উপস্থাপনা স্তরটি অবশ্যই সিদ্ধান্ত নিতে পারে যে এটি তাদের ছুঁড়ে ফেলেছে বা ব্যতিক্রমগুলি ঘটতে বাধা দেওয়ার জন্য এটি নিজস্ব বৈধতা রয়েছে।

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

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