Daniel Sapoundjiev on
  Data in sofware -

Данни в разработката на софтуер

Data in software

17 Май 2015

Данните в софтуерните приложения

Въведение

Повечето книги за програмиране разясняват различните типове данни ползвани в даден език за програмиране.
Също така обясняват как се създават променливи от тези типове.

След което обясняват и как най-общо се ползват.
Примерно създаваш обект от даден клас, после попълваш данните и после ги изпечатваш.

Но за по-големи и по-сложни системи понякога е трудно да си изгради начин на мислене човек.
А и сякаш в повечето книги за програмиране не се изяснява как да се гледа на данните в този случай.

А данните са организирани и свързание помежду си по някакъв начин. Тези структури остават не толкова добре засегнати.
А една система основно се състои от тези структури данни, които се променят по време на работа на програмата.

Процеси свързани с данните

Ако се приеме, че с процеси и ресурси можем да опишем всевъзможни системи,
то и данните ще намерят място в тези начин на представяне.

Най-общо казано, един или повече потребители на една система извършват процеси.
В тези процеси участва и системата.
Тези процеси касаят данните по следните начини:
- Добавят се нови данни в системата
- Премахват се данни от системата
- Променят се данни от системата

Като разбира се, един процес може едновремено да променя данни, да добавя и да премахва.

Данните в програмата трябва да са организирани в някаква структура.
Ако не са, то няма да могат да бъдат откривани и ползвани от кода.

Данните могат да дойдат от различни места в системата.
Потребител може да ги въведе.
Може да ги въведе с клавиатура
Може да ги въведе с мишка
Може да дойдат от друга система.
Може да дойдат от файл на хард диска, от сървис в интернет.

Данните могат да се въведат с няколко натискания на мишката
или с няколко натискания на бутоните от клаватурата.

Състояния на софтуера

Примерно ако се кликне с мишката на определено място това означава определено нещо.
Тъй като при работата с програма в повечето слачаи има монитор и мишка.
и мишката клика на определени места на монитора.
Но много зависи в какво състояние е програмата, когато се клика.
Така ако се клика на едно и също място в различни състояния на програмата, се разбират различни неща.
Примерно ако се клика с мишката на дадени места от екрана може да искаме да вземаме тези позиции.
Ако преди това е натиснат бутон за даден инструмент, то значи, че ще се прави нещо определено

Добавяне на крива от няколко точки

Потребителят натиска бутон за чертане на плавна крива.
С това свое действие потребителя променя състоянието на програмата.
Променя някакви данни в програмата.
Този вид данни често се пренебрегват, защото носят информация за това как ще се държи програмата в споследствие.
А не конкретни данни, които се ползват от потребителя. Но това също са данни, част от системата.
И те също се въвеждат от потребителя.
Тези данни могат да се нарекат - Програмни данни за функциониране на системата

След което потребителя започва да клика с мишката на определени позиции по екрана.
Така той отново въвежда данни. Дава някаква информация на системата.
Това може да бъде позиции на точки от кривата. Тогава трябва да клика на определени места на екрана.
Но това може да бъде и бутон чрез който да се откаже да чертае кривата.
Може да бъде и бутон чрез който да каже, че вече е дал необходимата информация за точките и кривата може да бъде добавене.
Потребителят може да въведе информация чрез няколко клика или чрез един клик. В зависимост от информацията.

Потребителят кликва повторно върху последно добавената точка
По този начин програмата разбира, че потребителя е въвел всички точки и добавя новата крива.

Но преди това на някакъв още по-ранен стадии потребителя е дал и някаква друга информация.
Кликнал е върху бутон за избор на слой.
Така той е казал, че каквото и да се чертае ще се добавя в този слой.
Също така може да е кликнал и на бутон за дебелина на линята и вид на линията.
По този начин е казал, че каквото и да се чертае ще има тази дебелина и вид.
Също така е избрал менюто Нов или Отвори.
По този начин е казал, че каквото и да се прави от тук нататък то ще променя конкретен модел.

На практика потребителя казва на програмата в какво състояние да застане.
Нещо като да инструктираш човек. Вземи лопатата, отиди до градината, започни да копаеш, Спри да копаеш, Вземи дърво, Постави го.
Но командите са по опростени. Например, вземи лопата и прави движениея с ръка, после вземи дърво и прави пак движения.
Двиеженията са еднотипни но в зависимост от предходните иструкции и действия сега това движение ще доведе до нещо различно.
Може да се предвиди какво да се прави предварително за да се достигне до някакъв етап на който определени движения ще доведат до желан резултат.

Потребителя иска с минимум действия да извърши работата. Но минимюм действия не винаги е минимум на брой.
Примерно ако трябва да направи два клика близо един до друг, това ще е за предпочитане пред два клика, които са отделечени един от друг.
Също може да предпочете да направи два клика за нещо, което прави рядко, но за сметка на това да има по-малко кликове за нещо, което прави по-често.

Може да се каже, че всяко действие е подготовка за нещо друго. Или предпоставка за последващо действие.
Всяко действие ти отваря възможност за последващо действие.

Примерно, ако не стартираш програмата не може да свършиш определен вид работа, не може и да извършиш и някои действия които програмата позволява.
Може да се каже, че всяко действие ти отключва възможност за следващо действие.
Това е и до голяма степен валидно за самия живот.
Примерно, ако купиш тенджера ще можеш да сготвиш.
Купуването не е само въпрос на придобиване. То е и въпрос на нещо да дойде близо до теб. Да може след това да извършиш малко на брой деиствия, за кратко време,
за да може да го ползваш.
Примерно, една тенджера може и да не я купиш. Може да я вземеш назаем или под наем.
Тогава тя ще стои на някокво близко разстояние до теб и ще можеш лесно да си сготвиш боб.
Може да предпочетеш да не купуваш тенджера и всеки път, когато искаш да сготвиш да ходиш някъде надалече, където ще можеш да ползваш.
Но трябва да занесеш и продуктите до там, което също може да се окаже бавно и трудно.

От разгледаното по-горе може да се извдеде, че софтуерът може да има много състояния
Примерно едно от тях да показва дали е отворен файла или не. Това е някакво булево състояние.
Друго състояние може да показва кой инструмент е избран към момента. Това е състояние, което може да приеме една от много стойности.
Състоянията имат дървовидна структура. Също така на едно ниво може да има няколко състояния на софтуера.

Състояния могат да бъдат и дали даден проорец е скрит или козаван на екрана.
Дали дадена форма е видима на екрана.

Живот на данните

Данните като цяло могат да съществуват временно в оперативната памет или за по-дълго време на постоянен носител.
При приемане на данни в системата тя може да ги съхранява в оперативната памет или в постоянната.
Може да ги съхрани временно в опаративната памет и после да ги запази и в постоянната.
Може това да го реши потребителя.

Данните идват от някъде.
Седят някъде
Ползват се за нещо
Отиват някъде
Променят се
Изтриват се.

Когато една данна дойде тя стои някъде.
Тази данна може да се промени. Но дали ще е нова данна това.
Когато се изтрие и изчезва.

Нова данна може да се въведе от човек.
Може да се дублира вече съществуваща.
Може да се изчисли на базата на същесвуващи данни

Програмиране за създаване на модела от данни

Програмистът е важно да напише бързо кода.
После този код да работи бързо
Също така да работи добре, да няма бъгове.
Да се спести време от тестове и разработка.

Когато програмиста пише код, той обикновено създава нови файлове, с нови класове за различните даннови обекти.
В него юзва други класове
Добавя методи и функции.
Добавя пропъртита.
Добавя списъци.

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

За обектите от данни може да се подходи по следния начин.
Създава се един клас, който може да държи всякакви данни.
Т.е. по време на програмиране не е необходимо да се създават повече файлове.
Не е необходимо да се добавят в тях класове, да се добавят полета и методи.

Не е необходимо да се добавя код за уведомяване при промяна на данните.

Обогатяване на данни

Даден елемент от данни може в даден момент да му се добави нова данна.
Но при повечето елементи от този тип това може да не се случи.
Тогава не е необходимо при създаване на такъв елемент да се пази място за конкретната данна.
С помощта на пропърти клас може да се добавят и махат полета.
Така се ползва по оптимално паметта.

Обогатяването на данни не е естествена част от обектно ориентираното програмиране.
Но когато даден клас трябва да притежава много данни в някаква ситуация,
това не означава, че всички обекти от този клас ще имат нужда от тези данни.
Затова можем да обогатяваме класа с нови данни. По този начин пестим памет, по-бърз става кода.
В ООП каквито данни се дефинират в класовете, такива се ползват. Заделят се при създаването на обект, това не е много добре.
За да се нопише някакъв общ код при промяна на данни трябва този код да е при всеки един клас и поле.
Всяко поле си има име, и ако някъде го сгрешиш компилатора ще си каже. Това е добре.

В момента на много места се ползват мапове, които държат връзката между обект и допълнителни данни.
Също така се ползва и поле Data от тип TObject, където човек да си слага данни по собствено осмотрение.
Също се ползва и поле таг, за произволни данни от целочислен тип.
Но това не е необходимо, защото класовете ще могат да се обогатяват с каквито данни има нужда.
Но трябва да се внимава да не ползват еднакви имена различни логики при обогатяването.
Това разбира се може да се случи и при обектното програмиране. Две различни логики да ползват общо поле на клас.

Групиране на данните в моделите

В моделите на данните се налага групиране на еднотипни данни.
Това се реализира посредством списъци от тези данни.
В един списък динамично по време на изпълнение на програмата могат да се добавят или премахват данни.
Но тези данни могат да се групират на подгрупи. Тогава могат да притежават полета към коя група принадлежат.
Примерно определени полета могат да се разглеждат като такива, които поставят обекта в група.
Такова поле може да бъде цвят.
Но може обектите да нямат такова поле, а да се направят отделни списъци, които да държат данни за съответен цвят.
Така погледнато може да стигнем още по далеч, да имаме само празни обекти, а за всеки вид данни да имаме списъци.
Тогава поставяме обекта в определен списък, когато искаме да има някоя стойност.
Това би било добре, когато се итерират данни. Примерно искаме да имаме всички обекти с някое поле.
Но когато ни трябва да проверим за даден обект каква е стойността, то ще трябва да го търсим в цял списък, което е по-бавно.
Когато и двете ни трябват, то се получава дублиране на данните. Имаме поле за стойността, а също така и списък за обектите с тази стойност.
Да вземем за пример, че трябва да се имплементира селекция на обекти. Да се знае кой обект е селектиран и кой не.
Тогава е добре да имаме данните в отделен списък, примерно ако трябва да изтрием всички селектнати обекти или трябва да ги деселектнем.
Но в същото време ни трябва и бързо да разберем дали даден обект е селектнат.
Тогава правим списък с всички селектнати елементи, но и всъщото време имаме и поле показващо дали даден обект е селектнат.

Групирането може да се имплементира, като отделни списъци за всяка група
или като поле за принадлежност към група
Когато се итерира в отделна група е много по-лесно.
Подреждането в отделна група е също по-лесно.

Back to main menu