Ruby on Rails и принципите, върху които е изграден

Ruby on Rails и принципите, върху които е изграден

avatar Ekaterina Temelkova 3 минути
Ruby on Rails и принципите, върху които е изграден

Два са основните принципи, върху които е изграден web framework-a Ruby on Rails - Don’t repeat yourself (DRY) и Convention over Configuration (CoC).

Don't repeat yourself (DRY)
DRY принципът може да се обобщи като „Всяко парченце знание трябва да има едно единствено, недвусмислено представяне вътре, в рамките на една система“. Принципът е формулиран от Анди Хънт и Дейв Томас в тяхната книга „Прагматичният програмист“. Когато DRY принципът е приложен успешно, промяната на кой да е отделен елемент в дадена система не изисква промяна в останалите елементи, които нямат логическа връзка с променяния елемент. Що се касае до елементите, които са свързани логически помежду си - всички те се променят предвидимо и еднакво, като по този начин се поддържат в синхрон. Освен използването на методи и подпрограми в своя код, Томас и Хънт се облягат на генератори на код, системи за автоматично изграждане и скриптови езици, за да наблюдават в действие DRY принципа.

Convention over Configuration (CoC)
CoC принципа е парадигма при дизайна на софтуерни рамки, чрез който да се намали броят решения, които разработчикът работещ със съответния фреймуърк трябва да направи, без това да се отразява на неговата гъвкавост. Този принцип е тясно свързан с Ruby on Rails, най-вече защото е разработен от автора на фреймуърка, но е базиран на по-стари идеи като „sensible defaults”, “POLA”*, който се използва най-вече в дизайна на потребителски интерфейс. На практика фразата Convention over Configuration означава, че разработчикът може да се концентрира върху най-неконвенционалните аспекти на приложението, което разработва. За пример: ако имаме клас „Sales” в нашия модел, съответстващата таблица в базата данни по подразбиране получава същото име.

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

Употребата на фрази при Ruby on Rails е фокусирана върху съответния файлов проект по подразбиране, както и на структурата на директориите, което от своя страна спестява на разработчиците да пишат XML конфигурационни файлове, чрез които да определят кои модули трябва да бъдат заредени от фреймуърка - нещо, което е характерно за по-ранни софтуерни рамки. Друг метод за намаляването броя решения, които разработчика трябва да вземе включва употребата и съчетаването на програмни идиоми и конфигурационни файлове с многопластова архитектура.

Недостатъци на подхода CoC могат да се проявят поради конфликти с други принципи при софтуерния дизайн, като принципът от "Zen of Python"**, който гласи "Explicit is better than implicit" ("Изрично е по-добре от прикрито/имплицитно", може да се разбира като "По-добре директно, ясно изказано, отколкото косвено, индиректно" т.е. XML). Също така фреймуърк, базиран на CoC принципа често включва DSL, който предлага ограничен набор от конструкции или Inversion of control (IoC), при който разработчика може да въздейства на "поведението" използвайки ограничен набор от "куки" ("hooks"), като това може да направи имплементирането на "поведение" трудно изразимо от предоставената конвенция в сравнение със случаите, в които се използва софтуерна библиотека, която не се опитва да намалява количеството на решенията, които разработчиците трябва да направят.

Ако всичко, прочетено дотук, събужда интереса ви към Ruby on Rails, не пропускайте да се включите в нашето практическо обучение "Уеб програмиране с Ruby on Rails" още сега от ТУК

_______________________________________________________________________________________
* POLA - Principle of least astonishment - "Принцип на най-малкото учудване", известен още като "Закон за най-малката изненада" е принцип при дизайна на потребителски интерфейс, който гласи, че ако дадена необходима опция/свойство имат висока степен на изненада (спрямо потребителя), може да е наложително тази опция/свойство да се преработи.

**Zen of Python - Колекция от 20 софтуерни принципа, които силно са повлияли езика за програмиране Python.

Автор: Георги Кацаров