Перейти до основного вмісту

Роздуми про ідеальну архітектуру додатків. Частина 2: Розвіюємо міфи?

Зміст

Частина 2

Пролог

Пройшло вже декілька дній з моменту публикації першого посту по даній темі. Ох і наслухався я про себе за цей час, ну, не так про себе, як про саму ідею. На жаль, все "Фу..." не пішло в коментарі. Хтось писав в скайп і джаббер, хтось в особистому співлкуванні. Підбиваючи підсумки: всі засумнівались і посміхались. Але... Багато хто так і не зрозумів, що я хочу донести, тобто неправильно зрозуміли суть задачі, яку я пробую вирішити, і зараз я це хотів би поправити. це швидше моя помилка.

Я не пробую створити універсальний засіб вирішення інженерних задач

Це в корені оманливе твердження, яке я отримав в коментарях до попереднього поста. Універсальне рішення - це наш мозгок Але найбільш цікавий момент тут в тому, що він не призначений напряму вирішувати задачі. Схему його роботи шивдше можна подати як: "навчитись рішати" -> "рішити". А в наш час ще й створити засіб для того, щоб задачу, яку ми навчились рішати - вирішував хтось іншй. Наприклад, арифметичні операції прекрасно виконує калькулятор.

До чого я веду?

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

Наводжу приклад

практично всі великі комерційні комп'ютерні ігри створюються на об'єктно-оріентованих мовах програмування (в основному це С++). Спроба зробити гру, користуючисьь тільки структурним підходом призведе самі розумієте до чого.

Але тут такий цікавий факт. Маючи, наприклад, в своєму розпорядженні, грубо кажучи, функцію main (розглянемо варіант на С), ми можемо написати будь-який додаток:

int main() {
    // Do any task in the world
    return 0;
}

Тобто, по суті, ось воно! =) Відсутність фреймворку, якихось архітектурних правил і обмежень і привело нас до ціли. Користуючись таким "фреймворком" можна зробити все.

Смішно, правда?

Дійсно, понаписував тут про терминаторів, про всяку фігню і дойшов до того, що фреймворки нафіг не потрібні. Не зовсім так.
Суть моїх починань в тому, що розвиваючи код, наведений вище таким чином, щоб він спрощував життя розробнику і при цьому не накладав на нього обмежень у вирішенні якої б то не було задачі, ми отримаємо те, що нам і потрібно. Ну, а, оскільки я, все ж таки згадував, що пробувати виконати реалізацію будемо на Python, то початком будет що? Правильно, - порожній Python-модуль.
Тобто, клжен раз додаючи рядок коду в фреймворк варто задумуватись і доводити, що такий підхід не змусить розробника, який знаходиться в здравому умі і світлій пам'яті, втикати костилі в програму.

Висновок

Справи з підкоренням світу йдуть досить погано, але, дякуючи впевненості Андрія Свєтлова в тому, що задача більш проста, якось до неї повернусь, може навіть напишу про прогрес тут.
Надіюсь, що вніс деяку ясність в ідею, викладену в попередній публікації, якщо не запутав вас ще більше :)

Коментарі

  1. Подразумевается ли наличие некоего стандартного функционала(если да, то что именно) или же фреймворк только должен предоставлять возможность использования архитектуры

    ВідповістиВидалити
  2. Отличный вопрос! (он мне показал, что этот пост я написал не зря :) ).
    Эта тема очень болезненная. Как показывает история и опыт использования, большинство предпочитает batteries included (Django), а не делай как хочешь, и чем хочешь (Pylons).

    Понятие "стандартного функционала" более как соответствует целям преследуемой здесь задачи, и эта проблема (надеюсь) будет решаться.

    Суть проблемы в том, что в разных областях "стандартный функционал" будет СОВЕРШЕННО разным и даже не пересекатся.

    То есть внедрение такового в код, и даже больше, - ОПРЕДЕЛЕНИЕ данного ПОНЯТИЯ еще будет формироваться и пока у меня нет ответа на этот вопрос.

    ВідповістиВидалити
  3. По поводу вопроса в прологе:

    Майлз Беннетт Дайсон - ведущий программист «Кибердайн Системс» в паралельной/вымышленной вселенной фильмов про Терминатора. :)

    ВідповістиВидалити
  4. Таки да! А на мониторе позади него мы видим призрачные строчки кода будущего фреймврока :)

    ВідповістиВидалити
  5. Я так понял, что идеальный универсальный фреймворк на данный момент состоит из пустого модуля.
    Думаю теперь стоит произвести небольшой анализ существующих фреймворков и архитектур и вывести из них начальный набор аксиом.

    ВідповістиВидалити
  6. >>> Я так понял, что идеальный универсальный фреймворк на данный момент состоит из пустого модуля.

    Совершенно верно :)

    >>> Думаю теперь стоит произвести небольшой анализ существующих фреймворков и архитектур и вывести из них начальный набор аксиом.

    Не совем так. Это то, о чем я писал в первой главе, - никакой жизни не хватит выучить все фреймворки, средства и категории задач", а при такой задачи обязательно знать все :). Задача превращается в полный перебор... =(

    Как я описал в первой главе, подход будет более теоретический, то есть: пишем код и смотрим, применим ли он (удобен ли он) для всего класса задач. Если нет - так не пишем, думаем как сделать по-другому.

    ВідповістиВидалити
  7. >>> никакой жизни не хватит выучить все фреймворки, средства и категории задач
    >>> пишем код и смотрим, применим ли он (удобен ли он) для всего класса задач.

    Здесь начинается путаница... Нужно разобраться со всем самому либо пустить в мир на растерзание.

    ВідповістиВидалити
  8. "Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг - из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле". (с) Александр Степанов

    В данном случае это особенно актуально в связи с полной неясностью задачи

    ВідповістиВидалити
  9. а вообще я люблю написать, посмотреть шевелится ли "оно" и если что кувалдой по голове. Первая итерация. А дальше повторяем :)

    ВідповістиВидалити
  10. Так придумали шаблоны проектирования. На базе опыта реализации многих задач выделили общие приемы и подходы

    ВідповістиВидалити
  11. @theod
    >>> сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы.

    Вот с этим категорически и полностью согласен. И я писал об этом в первом посте, как первый путь создания, - анализировать все практические решения. И даже написал, почему таким путем нельзя пойти.

    ВідповістиВидалити
  12. мне больше нравится первый путь решения.
    обьясню почему:
    как ты будеш смотреть\оценивать применима ли "строчка" для всех классов задач? особенно учитывая что отрицаеш необходимость наличия опыта в различных классах задач

    изначально ты планируеш решать эту задачу один(делаю такой вывод из того что ты откинул первый вариант про пересечение множеств), но даже уже наличие комментариев, ламает все дрова, т.к. начинаем искать решение вместе

    такую задачу нужно решать сообща, и решать её должны люди набившие руку в большом круге задач

    это не значит, что ты должен остановится, твой путь и опыт который ты получиш в поисках решения тоже важен, и возможно он приведёт кого-то к какой то правильной мысли

    ВідповістиВидалити
  13. >>> мне больше нравится первый путь решения.

    Мне тоже. И я полностью принимаю и понимаю все аргументы.

    >>> как ты будеш смотреть\оценивать применима ли "строчка" для всех классов задач?

    Я ждал этого вопроса. Только здравым смыслом =). Я думаю, что в процессе поиска все станет понятно, либо мне станет понятно, что задачу решить не могу (нереально будет звучать слишком громко), и вообще все это фигня =(

    ВідповістиВидалити
  14. Назар
    >>На базе опыта реализации многих задач выделили >>общие приемы и подходы

    В том то и дело, что сначала были попытки, а потом появились шаблоны :)

    ВідповістиВидалити
  15. Блин, как я себе сейчас напоминаю этого товарища - http://python.su/forum/viewtopic.php?id=3996

    ВідповістиВидалити
  16. Я правильно понял, что вы собираетесь выработать общую методологию разработки как под создание игр, так и под создание веб приложений? Попахивает поповщиной...

    ВідповістиВидалити
  17. >>> Я правильно понял, что вы собираетесь выработать общую методологию разработки как под создание игр, так и под создание веб приложений?

    Примерно "в десятку".

    >>> Попахивает поповщиной...

    Главное правильно приготовить :) А чем оно там попахивает - разберемся.

    ВідповістиВидалити
  18. >>> Блин, как я себе сейчас напоминаю этого товарища -
    >>> http://python.su/forum/viewtopic.php?id=3996
    Ууу... Мега чувак. До сих пор не оставил своей идеи. :-)

    А вообще да, я считаю, что в итоге ты придёшь к пустому питоньему модулю, набору стандартных библиотек и pypi. Ведь по сути это и есть твой универсальный фреймвок для решения любых задач.
    Ну да, собаку выгулять пока нельзя, но это, думаю, в разработке. :-)

    ВідповістиВидалити
  19. @ZZZ
    Как сказал мне @theod, разница между мной и тем чуваком в том, что в моем случае нельзя оценить объем работ...

    ВідповістиВидалити

Дописати коментар

Популярні дописи з цього блогу

Регулярні вирази в Python: вивчення та оптимізація

Writing a regular expression is more than a skill -- it's an art. Jeffrey Friedl Що це таке? Рано чи піздно майже кожному програмісту в своєму житті доводиться стикатись з регулярними виразами. Термін "Регулярні вирази" є перекладом з англійської словосполучення "Regular expressions" і не є зовсім точним, а для тих, хто перший раз почув цей термін, мабуть, навіть спантеличуючим (я, наприклад, коли вперше почув, ніяк не міг собі второпати по назві, хоча б приблизно, що це, і для чого використовується). Літературний і більш осмислений переклад звучав би, мабуть, як "шаблонні вирази". Але назва вже прижилась, а скажете "шаблонні вирази" - вас просто не зрозуміють :). Звідси: Регулярний вираз -  це рядок, що задає шаблон пошуку під-рядків в рядку. Регулярні вирази використовуються для аналізу текстів на предмет відповідності текстової інформації деякому шаблону. Наприклад , шаблон, що задає слово, яке містить букву "к". Де застосовують

Python: як програмно перемкнути розкладку клавіатури в Windows

Дослідивши дане питання, я побачив, що Python не має засобів "з коробки" для вирішення цієї задачі. Відвоідно, задача повинна вирішуватись для каждої ОС своїм шляхом. Дане рішення було знайдено мною для ОС Windows XP +. Панацея - Win API Для того, щоб виконати завдання необхідно встановити додатково бібліотеку pywin32 , яка надає доступ до функцій Windows API з Python. З цієї бібліотеки нам знадобиться модуль win32api . >>> import win32api Дослідивши його вміст, можна побачити, що для роботы з розкладкою клавіатури є декілька функцій і одне системне повідомлення Windows - WM_INPUTLANGCHANGE : GetKeyboardLayout GetKeyboardLayoutList LoadKeyboardLayout В даному випадку для нас важлива саме остання функція - LoadKeyboardLayout . Дана функція завантажує нову розкладку (якщо вона ще не завантажена) і виконує після цього ще якісь дії; приймає в якості аргументів два: рядок з ідентифікатором розкладки. дію. Більш детально про їхні можливі значення можна почитати в MSDN . О

Python: PEP-8 чи не PEP-8

Пост - не технічний, кому не цікаво - можете далі не читати... PEP-8, хоча й фактично є пропозицією по розширенню Python під номером 8, серед Python програмістів уже став терміном, що позначає правила стилю оформлення коду. Ні, я не збираюсь зараз описувати його тут - про нього можна почитати в першоджерелі . Питання в тому, слідувати цьому стандарту, чи не слідувати? Ітак, стандарт це в більшості випадків добре, оскільки вносить порядок. Наприклад, стандарт USB 2.0 - просто прекрасний стандарт, уявіть собі, якби флешки були не USB, а кожна мала б свій вихід :)... Жахливо, так, були б у нас USB-порти як card-reader'и - 62 в 1.. Реально 62 в 1 Інша справа з PEP-8. Тут все по іншому, адже програма не змінює свою поведінку, якщо ми будемр робити відступ не в 4 пробіла, а 2 (добре, що більшість, все-таки, робить 4), або будемо ставити пробіл перед другою дужкою, чи не будемо і т.д..  Отже, кожен програміст може редагувати свій код як йому хочеться. Мені, наприклад, подобається