Магазин взуття

МЕТОДИЧНІ ВКАЗІВКИ 1. При виконанні курсового проекту обов’язковим є використання об’єктно-орієнтованого програмування. 2. Клас як тип, визначений користувачем, повинен містити приховані поля й наступні методи: конструктори, що визначають, як ініціалізуються об’єкти класу; набір методів, що реалізовують властивості класу (методи, щоповертають значення прихованих полів класу описуються з модифікатором const, для того, щоб не змінювалися значення полів); набір операцій, що дозволяє копіювати, присвоювати, порівнювати об’єкти і проводити з ними необхідні дії; клас виключень, який використовується для повідомлень про помилки за допомогою генерації виняткових ситуацій. 3. У курсовому проекті повинно використовуватися не менше трьох класів, причому діалог з користувачем повинен бути реалізований як окремий клас. 4. Кожен клас повинен бути реалізований у вигляді двох файлів: заголовного (*.h), такого, що містить опис класу і модуля тіла (файл, що містить реалізацію методів класу – *.срр). Основна функція main() реалізується у вигляді окремого файлу – головна програма. Якщо в роботі використовуються глобальні функції, вони також повинні бути розміщені в окремому файлі. 5. У курсовому проекті повинні використовуватися перевизначені функції-операції для виконання необхідних операцій. Наприклад, для додавання елементу в список можна перенавантажувати операцію додавання (+) або інкремент (++). 6. Для реалізації запису даних у файл і отримання даних із файлу слід використовувати файлові потоки. 7. Передбачити перевірку коректності даних. При перевірці використовувати механізм виняткових ситуацій. РЕКОМЕНДАЦІЇ ЩОДО ПРОГРАМУВАННЯ 1. При створенні класу слід добре продумати його інтерфейс – засоби роботи з класом для тих програм, які його використовуватимуть. Інтерфейс повинен бути інтуїтивно зрозумілим і включати тільки методи. Поля даних класу повинні бути прихованими. 2. Не слід визначати методи типу get/set для всіх прихованих полів класу – це все одно, що відкрити до них доступ, тільки складнішим способом. Поля класу вводяться тільки для того, щоб реалізувати властивості класу, представлені в його інтерфейсі за допомогою методів. 3. Не потрібно розширювати інтерфейс класу без необхідності, “про всяк випадок”, оскільки збільшення кількості методів веде до трудності розуміння класу користувачем. В ідеалі інтерфейс повинен бути повним, тобто надавати можливість виконати будь-які розумні дії з класом, і мінімальним – без дублювання і перетину можливостей методів. 4. У вигляді методів рекомендується визначати тільки дії, що реалізовують властивості класу. Якщо яку-небудь дію можна реалізувати, не звертаючись до прихованих полів класу, її немає необхідності описувати як метод; краще описати її як звичайну функцію, помістивши її в загальний з класом простір імен. Якщо функція виконує дію, що не є властивістю класу, але потребує доступу до його прихованих полів, її слід оголосити як дружню. Але в загальному випадку дружніх функцій і класів треба уникати, оскільки головною ідеєю ООП є мінімізація зв’язків між інкапсульованими класами. 5. Для збільшення продуктивності програми методи, що часто викликаються, можна оголосити як вбудовані (inline). В основному це стосується коротких методів, тіло яких виявляється менше розміру коди, що генерується для їх виклику. Окрім прискорення програми за рахунок виключення викликів, це дає можливість компілятору проводити повнішу оптимізацію. Проте необхідно враховувати, що директива inline носить для компілятора рекомендаційний характер. 6. Конструктори і деструктори робити вбудовуваними не рекомендується, оскільки в них фактично присутній код, що поміщається компілятором, розмір цього коду може бути досить значним (наприклад, в конструкторі похідного класу повинні бути викликані конструктори всіх базових і вкладених класів). 7. Перевизначені операції класу повинні мати інтуїтивно зрозумілий загальноприйнятий зміст (наприклад, не слід примушувати операцію “+” виконувати що-небудь, окрім складання або додавання). 8. Якщо яка-небудь операція перевантажена, слід, якщо можливо, перенавантажувати і аналогічні операції, наприклад “+”, “+=” і “++” (компілятор цього автоматично не зробить). При цьому операції повинні мати ту ж семантику, що і їх стандартні аналоги. 9. І конструктор копіювання, і операція присвоєння, що створюються за замовчуванням, виконують поелементне копіювання з області-джерела в область-приймача. Після копіювання два відповідні вказівники різних об’єктів посилатимуться на одну і ту ж область пам’яті, якщо об’єкт міститиме тільки вказівники. При знищенні першого з об’єктів ця пам’ять буде звільнена, а повторна спроба звільнити її при знищенні другого об’єкту приведе до невизначеної поведінки програми. Тому для класів, що містять поля-вказівники, слід завжди явно визначати конструктор копіювання і операцію присвоєння, що виконують виділення пам’яті під динамічні поля об’єкту. 10. Динамічна пам’ять, виділена в конструкторі об’єкту, повинна звільнятися в його деструкторі. Невиконання цієї вимоги приводить до витоків пам’яті. Видалення нульового вказівника безпечне (при цьому нічого не відбувається), тому якщо конструктори, конструктори копіювання і операція присвоєння написані правильно, будь-який вказівник або посилається на виділену область пам’яті, або рівний нулю, і до нього можна застосовувати delete без перевірки. 11. Різниця між конструктором копіювання і операцією присвоєння полягає в тому, що остання працює у тому випадку, коли об’єкт-приймач вже існує, тому в ній перед виділенням динамічній пам’яті слід звільнити пам’ять, зайняту раніше. З цього виходить, що при реалізації операції присвоєння для класів, що містять поля-вказівники, необхідно проводити перевірку на самоприсвоювання і в цьому випадку залишити об’єкт без змін. Необхідно також пам’ятати про те, що операція присвоєння повинна повертати посилання на константу. 12. У конструкторах для завдання початкових значень полям рекомендується використовувати ініціалізацію, а не присвоєння. Ініціалізація більш універсальна, оскільки може застосовуватися в тих випадках, коли присвоєнням користуватися не можна (наприклад, при завданні значень константним полям або посиланням). Крім того, вона виконується ефективніше, тому що створення об’єкту в C++ починається з ініціалізації його полів конструктором за замовчуванням, після чого виконується конструктор, що викликається. 13. Необхідно враховувати і той факт, що поля ініціалізуються в порядку їх оголошення, а не в порядку появи в списку ініціалізації. Тому для зменшення числа можливих помилок порядок визначення полів в списку ініціалізації конструктора повинен відповідати порядку їх оголошення в класі. 14. Статичні поля не повинні ініціалізуватися в конструкторі, оскільки їм потрібно присвоювати початкове значення тільки один раз для кожного класу, а конструктор виконується для кожного об’єкту класу. Статичні поля ініціалізуються в глобальній області визначення (поза будь-якою функцією). 15. Конструктори копіювання також повинні використовувати списки ініціалізації полів, оскільки інакше для базових класів і вкладених об’єктів будуть викликані конструктори за замовчуванням. 16. Операція присвоєння не успадковується, тому вона повинна бути визначена в похідних класах. При цьому з неї слід явним чином викликати відповідну операцію базового класу. Відкрите наслідування класу Y з класу X означає, що Y є різновидом класу X. Базовий клас X є більш загальним поняттям, ніж похідний клас Y. Скрізь, де можна використовувати X, можна використовувати і Y, але не навпаки (пригадаєте, що на місце посилань на базовий клас можна передавати посилання на будь-якій з похідних). Необхідно пам’ятати, що під час виконання програми не існує ієрархії класів і передачі повідомлень об’єктам базового класу з похідних – є тільки конкретні об’єкти класів, поля яких формуються на основі ієрархії на етапі компіляції. 17. Методи, які повинні мати всі похідні класи, але які не можуть бути реалізовані на рівні базового класу, повинні бути віртуальними. Наприклад, всі об’єкти ієрархії повинні вміти виводити інформацію про себе. Оскільки інформація зберігається в різних полях похідних класів, тому цю функцію не можна реалізувати в базовому класі. Функцію потрібно назвати в усіх класах одинаково і оголосити як віртуальну з тим, щоб інші методи базового класу могли викликати її залежно від фактичного типу об’єкту, з яким вони працюють. З цієї причини деструктори оголошуються як віртуальні. 18. При перевизначенні віртуальних методів не можна змінювати успадковане значення аргументу за замовчуванням, оскільки по правилах C++ воно визначається типом вказівника, а не фактичним типом об’єкту, що викликав метод. ЗАГАЛЬНІ ПРИНЦИПИ РОЗРОБКИ Культура кодування 1. Дублювання коду в програмі строго забороняється. 2. Не застосовуйте функціональну декомпозицію. Для повторного використання коду застосовуйте засоби ООП, наприклад, спадкування. 3. Давайте змінним та константам значущі імена. 4. Уникайте довгих і складних методів, розбивайте їх на кілька коротких. При модифікації коду максимально використовуйте рефакторинг (комплекс заходів, спрямованих на збільшення продуктивності, зменшення кількості коду і поліпшення його читабельності). 5. Завжди звертайте увагу на попередження компілятора. Намагайтеся, щоб їх не було. Про коментарі 1. Код повинен легко читатися і без коментарів. Висловлюйте свої думки за допомогою алгоритмічної мови, а не англійської чи української. 2. Текст коментаря відокремлюйте від слеша одним пробілом. Перша буква речення повинна бути прописаний, в кінці речення повинна стояти крапка // This is a sample comment. This is yet another comment sentence. 3. Не використовуйте коментарі в стилі C: / * ... * / 4. Коментар не повинен перефразувати те, що написано в коді. Намагайтеся давати змістовні пояснення. Наприклад, коментар «Increment i by one» до коду «i ++;» це погана практика, а коментар «Update the number of customer accounts processed» – хороша. 5. Коментарі до методів, властивостей, класів, інтерфейсів та інших конструкцій мови повинні мати XML-формат для можливої генерації програмних документів надалі.