А тепер - перше завдання квесту.

Вам дано конкретну задачу з аналітичної геометрії. Насправді завдання звучить так: "Написати для бібліотеки Geometry фунцію (процедуру), залежно від конкретної задачі, надалі - модуль), яка буде розв'язувати БУДЬ-ЯКУ задачу такого типу, незалежно від конкретних чисел, що стоять в умові задачі для прикладу.

Категоричними умовами, яких треба дотримуватися, є таке. У біблітеці, яку ми всі пишемо, вже прийнято певні рішення щодо програмної реалізації основних понять геометрії у вигляді певних структур даних (record). Це означає, що Ваш модуль повинен приймати вхідну інформацію і повертати результат у термінах цих типів даних. Тобто, якщо Ваше завдання звучить так: "Записати рівняння прямої лінії, яка...", то Ви маєте написати модуль, що як значення має повертати змінну типу tLine і, відповідно, вхідні параметри мають бути саме змінними типів, відповідних поняттям геометрії. Якщо сказано "Записати рівняння прямої лінії, яка проходить через таку-то точку та такі-то пряму та площину", то КАТЕГОРИЧНО вхідними даними мають бути саме змінні типу tPoint, tLine та tPlane -- ті, що їх реалізовано у Вашій версії бібліотеки.

На етапі проектування псувати саму бібліотеку Geometry не варто. Ви маєте здійснити ТРИфайловий проект.

unit MyLab1;

uses Geometry, Crt, ...

Interface
procedure SmthIsDoing(p: pPlane; M: pPoint; var Res: pLine; var RС: Integer);

Implementation

procedure SmthIsDoing(p: pPlane; M: pPoint; var Res: pLine; var RС: Integer);
begin
  ...........
end; 

Begin
  writeln('tMyLab for Geometry. V1.0 (C) Petryshyn Olesia, 2011');
End.

program Holovna;

uses Crt, MyLab1, Geometry;

var
  p: pPlane; 
  M: pPoint; 
  Res: pLine;
  RС: Integer; { Ретурн коде! :) }
  ......

Begin
  { 
     Тут треба задати початкові значення для вхідних величин,
     звернутися до своєї "проці"
     та вивести результати її роботи.
  }
End.

Ретельна перевірка коректності вхідних даних - ще одна хороша думка, що прийшла була колись в голову бігбосу на етапі розробки специфікацій. Який мануал не пиши, а дурний користувач обов'язково спроможеться передати до Вашого модуля некоректні дані. Коректна реакція на некоректні дані користувача - це гречно, шляхетно та кошерно. А якщо програма на помилкові вхідні дані реагує "злітанням" та "вивалюванням" в операційну систему, це просто ознака непрофесійності авторів розробки. Випишіть всі варіанти некоректностей, що можуть трапитися через фантазії користувача. А може, й через ляпи ваших колег, що працюють поруч. Всі ці перевірки треба буде реалізувати у вашому модулі.

Чи є у Вашої задачі варіанти наборів коректних вхідних даних, що їх доведеться обробляти за різними алгоритмами? Чи не забули Ви реалізувати їх всі? А реалізувавши, чи відтестували?

Головна програма Вашого проекту пишеться лише з метою продемонструвати роботу Вашої функції або процедури. Тому до інтерфейсу (діалогу з користувачем) вимог аж ніяких. Зате є жорстка вимога щодо ВІДСУТНОСТІ виведення куди-небудь усередені тієї процедури, що її Вам замовлено. Спілкуватися "зі світом широким" Ваша "проця" має через список параметрів, а не засобами введення-виведення, які є різними у різних середовищах та у різних користувачів, а ми тут пишемо пакет з претензією на універсальність.

Ось це все бігбос Тарас і висловив нашому герою, розвалившись у своєму фотелі, закинувши ноги на приставний столик, явно копіюючи своїх американських замовників, і потягуючи каву з горнятка.

За другим разом Вовчик все зробив як слід, роботу здав. Випробувальний термін минув, і тепер він - у штаті.

А Ви?