Теоретичні питання програмування.
1. Загальні теорії будування програм.
Iснує безліч теорій, автори яких вважають, що користування їх теоріями може зробити процесс програмування більш легким та зрозумілим для інших програмістів. Про цьому кожний філософ-теоретик вважає свою теорію найважливішою і вважає що самє його теорія покращує код програми та полегшує роботу програмістів, особливо коли програмістів занадто багато та у проєкті величезна текучість кадрів.
Але існує і протилежна теорія, що всі ці загальні теорії для нібито поліпшення коду і кращого його порозуміння - це лише засіб ціх теоретиків продавати себе особисто і заробляти на продажу нам своїх книжок та теорій.
1.1. Загальні теорії.
- Abstraction principle (computer programming)
- Acceptance test–driven development
- After the Software Wars
- Agile Manifesto
- Agile software development
- Behavior-driven development
- Best practice
- Big Design Up Front (BDUF)
- Black box engineering
- Brooks's law
- Cathedral and the Bazaar (see also Release early, release often (RERO))
- Chief programmer team
- CMMI
- Code and fix
- Code reuse
- Cohesion (computer science)
- Command–query separation
- Comment programming
- Composition filters
- Cone of Uncertainty
- Continuous integration
- Continuous test-driven development
- Control tables
- Convention over configuration
- Conway's law
- Cowboy coding
- Defensive programming
- Dependency injection
- Dependency inversion principle
- Design by contract (DbC)
- Design for test (DFT)
- Design-driven development
- Deutsch limit
- Discoverability
- Domain-driven design
- Don't repeat yourself (DRY) or Duplication is Evil (DIE) or Once and Only Once (OAOO), Single Point of Truth (SPoT), Single Source Of Truth (SSOT)
- Easier to Ask Forgiveness than Permission (EAFP)
- Encapsulation (computer science)
- Evolutionary prototyping
- Extreme programming
- Fail-fast
- Formal methods
- Free software license
- General Responsibility Assignment Software Patterns (GRASP)
- GRASP (object-oriented design)
- Hofstadter's law
- Hollywood principle
- Homesteading the Noosphere
- If it ain't broke, don't fix it
- Information hiding
- Integration competency center
- Interface (computer science)
- Interface (object-oriented programming)
- Interface segregation principle
- Inversion of control
- Iterative and incremental development
- Joint application design, also known as JAD or "joint application development"
- Kaizen
- Kanban (development)
- KISS principle
- Law of Demeter
- Lean integration
- Lean software development
- Lightweight methodology
- Liskov substitution principle
- Literate programming
- Loose coupling
- Mayo-Smith pyramid
- Micro-innovation
- Microsoft Solutions Framework (MSF)
- Minimalism (computing)
- Model-driven architecture (MDA)
- MoSCoW method
- Naked objects
- Ninety-ninety rule
- Open source
- Open/closed principle
- Planning poker
- PM Declaration of Interdependence
- Principle of good enough (POGE)
- Principle of least astonishment (POLA/PLA)
- Pristine Sources
- Program optimization
- Project triangle
- Protocol (object-oriented programming)
- Pull-based agile coaching
- Rapid prototyping
- Refactoring
- Release early, release often (RERO) – see also The Cathedral and the Bazaar
- Responsibility-driven design (RDD)
- Retrenchment (computing)
- Rule of least power
- Scaled Agile Framework
- Secure by design
- Separation of concerns (SoC)
- Separation of mechanism and policy
- Service-oriented modeling
- Single responsibility principle
- Software craftsmanship
- Software system safety
- SOLID (object-oriented design)
- Specification by example
- Spiral model
- Stepwise refinement
- Team software process (TSP)
- Test double
- Test-Driven Development by Example
- Test-driven development
- The Cathedral and the Bazaar
- The Magic Cauldron (essay)
- the Right thing, or the MIT approach, as contrasted with the New Jersey style, Worse is better.
- There's more than one way to do it
- Transformation Priority Premise
- Type-Generic-Profile (TGP)
- Uniform access principle
- Unix philosophy
- User:Jlovisa/sandbox/Code Valley
- V-Model
- Waterfall model
- Wheel and spoke model
- Worse is better
- You aren't gonna need it
- Zen of Python
- Zero one infinity rule
1.2. Programming paradigm.
- Agent-oriented programming
- Aspect-oriented programming (AOP)
- Modular programming
- Component-based software engineering
- Object-oriented programming (OOP)
- Functional programming (FP)
1.3. Software development methodology.
- Agile Unified Process (AUP)
- Dynamic systems development method (DSDM)
- Constructionist design methodology (CDM)
- Crystal Clear
- Extreme programming (XP)
- Iterative and incremental development
- Kanban
- Lean software development
- Open Unified Process
- Pair programming
- Rapid application development (RAD)
- Rational Unified Process (RUP)
- Scrum
- Structured systems analysis and design method (SSADM)
- Unified Process (UP)
1.4. Software development processes.
- Behavior-driven development (BDD)
- Design-driven development (D3)
- Domain-driven design (DDD)
- Feature-driven development (FDD)
- Test-driven development (TDD)
- User-centered design (UCD)
- Value-driven design (VDD)
- Configuration-driven development (CDD)
1.5. Software design.
2. Шаблони будування GUI.
GUI-патерні, чи шаблони, як ми їх називаємо - це достатньо корисна концепція стандартних єлементів сайту чи окремих десктопних програм, до яких юзера звикли і відразу розуміють, як користуватися програмою чи сайтом. Мені подобається ось цей сайт з переліком GUI-патернів - http://ui-patterns.com/patterns. А взагалі існує величезна кількість комерційних компаній, таких наприклад як https://www.devexpress.com/, або OpenSource команд, таких наприклад, як https://jqueryui.com/ - які мають повні комплекти стандартних GUI-патернів.
Чомусь прі розмовах про GUI часто забувають про FLEX, який просто у сто разів перевершує вся інші технології GUI разом, при чому FLEX присутній на значно більшому проценті стаціонарних кампутерів, ніж навіть JavaScript. Тільки мобільні платформи намагаються витісніти FLASH та замінити його на якийсь свій власній софт.
3. Абстрактні шаблони OOP.
OOP (Object Orientired Prgraming) - це специфічна нетрадіційна теорія будування програм, яка поширилася за декілька останніх років. Перший комп'ютер був побудований Аланом Тьрингом у 1936-му році, тобто 80-ть років тому. Це був достатньо сучасній і складний комп'ютер, на якому наприклад можна було розшифрувати шифри німецького генштабу. Через 60 років, у 1996-му році, тобто 20 років тому - на платформі X86 з'явився VB6 (на якому я працював багато років, ось наприклад), який вже мав достатньо функцій для підтримки OOP. А з 2002-го року, коли з'явився VB.NET, ця нетрадіційна теорія поширилася ще більше. Але, як і раніше більшість програм у цьому світі працює взагалі без будь-яких принціпів OOP - це перше що потрібно розуміти, коли ви розмовляєте про OOP. Наприклад будь-який SQL-сервер працює як і раніше, не враховуючи наявність у світі ідей OOP. Також JSON, XML, Reqular expressing - це взагалі протилежний напрямок думок. Найбільш поширений процессор у нашому світі, який розташований у SIM-карті, теж працює без будь якого OOP, як і процессор aрхітектури X86 нічого не знає про концепції OOP. Значна кількість сучасних мов написання програм взагалі ніяк не підтримує OOP - і це не заважає добре працювати цим программам та сайтам, наприклад PERL. А найбільш сучасні та поширені комерційні платформи програмування, побудовані вже після 2005-го руку - взагалі лише частково підтримують OOP, наприклад той же FLEX не підтримує перегрузку методів. А ще більш старіші модіфікації цієї технології, наприклад FLASH-player, мають ще більш обмежену підтримку OOP, однак Flash-player встаовлений на будь-якому стаціонарному ком'пьютері і чудово працює! Взагалі, я працював у национальному космічному агенстві України саме тоді, коли там все добре працювало, навіть усі супутники виходили у космос своєчасно. Тут можна додати трошки гумору - але коли з'явилося OOP - то все перестало нормально працювати, навіть усі супутники впали та затонули у океані.
Навіть у листі вище - Programming paradigm, OOP - це лише одна із шесті сучасних конкурентних теорій будування програм - по яким у своєму мозоку можна дивитися на архітектуру своїх програм. Тобто, OOP - це спеціфічне обмеження точки зору на будівництво програм. Але теорія OOP пішла ще далі, тобто побудовани стандартні шаблони-патерни OOP. Тобто теорія OOP передбачає що можна будувати будь-які програми саме з цих шаблонів і взагалі їх потрібно використовівати якомога частише.
Ще одна сумнівна концепція OOP полягає в тому, що усі попередні роки вважалося, що код програми повинен бути максимально лінейним, тобто найбільшої проблемою коду вважалося GOTO. Goto назад по коду вважалося взагалі неприпустимим, наприклад якщо в інстітуті у період мого навчання хтось намагався сдати програму, в якої була GOTO назад, вище по коду, то студенту ставили двійку і відправляли на повторну спробу сдати єкзамен. З цієї точки зору OOP - це взагалі один суцільний GOTO, тобто один спочатку NEW в базовому классі, потім інші методи у класах, які успадковані від базового, інтерфейси визначени десь у третьомі місці, воні керують (наприклад за допомогою поліморфізму) який саме метод буде насправді відпрацьовувати - це все один суцільний комок GOTO - ніякого якісного FLAT-коду тут немає. І якщо самому автору цей код ще хоч якось зрозумілий, то побачити концепції автора OOP-кода іншому програмісту майже неможливо.
Використання OOP часто передбачає, що архітектор компанії чи team lead компанії може намалювати якісь UML діаграми, а всі програмісти компанії подивилися на них і почнуть по ним писати код. Тобто заздалегідь передбачається, що проєктуваня софта ведеться зверху додолу, а не навпаки, спочатку невеличкі потрібні фунції, з яких потім збирається увесь софт. Але, як кажуть у статті https://en.wikipedia.org/wiki/Software_design_pattern, взагалі уся концепция OOP та особливо стандартних патернів OOP дуже сумнівна - "The concept of design patterns has been criticized in several ways".
Одне с перших пояснень концепції використання OOP-патернів у ASP.NET можна подивитися у книжці Роберта Мартіна від 2000-го року Design Principles and Design Patterns. Більш сучасний та тверезий погляд на принціпи OOP можна подивитись ось тут - .NET Design Patterns, але людина, що розповідає про сучасні патерни OOP дуже обмежена у своєму кругозорі - вона навіть ніколи не бачила головної специфічної мови, яка була спеціально розроблена для мікрософтовської платформи - Visual Basic .NET. Але в цілому цей сайт непоганий, тому я вирішив доповнити цю статтю на цієї сторінці описом шаблонів OOP для головної мови мікрософтовскої платформи - VB.NET. Описи патернів на російской мові звідси.
Creational Patterns
- Abstract Factory in VB.NET - Creates an instance of several families of classes. Цей патерн можливо замінити одним IF: If GetType(X)="..." then ... else ...., що робить код набагато простішим до порозуміння і модіфікації.
- Builder in VB.NET - Separates object construction from its representation. У більшості випадків будування об'єктів окремими частками непотрібно - у головному об'єкті можно зберігати лише link на додаткові дочерні об'єкти.
- Factory Method in VB.NET - Creates an instance of several derived classes. Це корисний патерн, наприклад різні провайдери доступу до даних робляться таким чином, тобто декілька класів мають однакові методи. У мене було декілька віпадків, коли цей патерн був би дуже корисним, щкодую, що я тоді його не використав. Наприклад у проєкті FlySeason у мене були класи авіа-тікетів на день раніше та на день піздніше, ніж на необхідну дату, ці класи були дуже схожі, мали майже однакові методи, наприклад калькуляція кінцевої цени, але я тоді вирішив пітання інакше, через інтерфейси та параметри.
- Prototype in VB.NET - A fully initialized instance to be copied or cloned. Здається це найпоширеный прототіп у JavaScript.
- Singleton in VB.NET - A class of which only a single instance can exist. У випадку повного Windows application цей патерн замінюється одним атрибутом <STAThread>, у інших випадках заміни цьому патерну не існує.
- Microsoft. Exploring the Factory Design Pattern
- Adapter in VB.NET - Match interfaces of different classes
- Bridge in VB.NET - Separates an object’s interface from its implementation
- Composite in VB.NET - A tree structure of simple and composite objects
- Decorator in VB.NET - Add responsibilities to objects dynamically
- Facade in VB.NET - A single class that represents an entire subsystem
- Flyweight in VB.NET - A fine-grained instance used for efficient sharing
- Proxy in VB.NET - An object representing another object
- Chain of Resp. in VB.NET - A way of passing a request between a chain of objects
- Command in VB.NET - Encapsulate a command request as an object
- Interpreter in VB.NET - A way to include language elements in a program
- Iterator in VB.NET - Sequentially access the elements of a collection
- Mediator in VB.NET - Defines simplified communication between classes
- Memento in VB.NET - Capture and restore an object's internal state
- Observer in VB.NET - A way of notifying change to a number of classes
- State in VB.NET - Alter an object's behavior when its state changes
- Strategy in VB.NET - Encapsulates an algorithm inside a class
- Template Method in VB.NET - Defer the exact steps of an algorithm to a subclass
- Visitor in VB.NET - Defines a new operation to a class without change
- Microsoft. Exploring the Observer Design Pattern
Нажаль, не всі прототіпи та шаблони OOP корисні. У мене було безліч книжок про шаблони OOP, більшість яких я вже давно викинув на смітник, бо люди ніби-то навмисне знущаються над читачем своїми патернами, які нібито повинні полегчити життя. Але ось ці дві перші книжки у мене зберіглися і досі. Я так і не зміг їх уважно дочитати до кінця.