Semantic of programming.

Сегодня столкнулся с очередным разрушительным последствием фриланса - мультипрофильность. Казалось бы, что в этом плохого? Проблема в том что человек не получает совсем никакой мотивации к развитию и изучению, природное любопытство исследователя, которое так важно в профессии как програмиста так и инжинера, подавляется меркантильными интересами. Вся система взаимотношений между заказчиком и исполнителем поддалкивает человека к ограниченности и шаблонности. 

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

Со временем человек либо полностью деформируется, либо уйдет из фриланса. Напоминаю, что речь идет о мелком и "регулярном" фрилансе, когда человек работаетт с одним заказчиком который адекватно относится к развитию продукта, а программист имеет за плечами мощный запас технической смекалки, тогда достигается необходимая свобода. Именно техническая свобода. 

Сама по себе свобода крайне опасная вещь, и менеджмент создан для того что бы ее ограничивать.

И это правильно. Свобода должна идти вместе с образованностью, культурой, воспитанием. И все это касается технических вещей тоже.

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

Прототипное программирование используется в динамических языках. В частности в JavaScript.

Особенность данной модели программирования в отстутсвии классов как модификаторов типа. Тип обьекта задается исключительно его прототипом. В конечном итоге все обьекты системы можно представить в виде дерева обьектов.

В классическом обьектно ориентированном тоже можно, но там узлами будут классы, а тут обьекты.

Так чем же может быть полезен такой подход?

Очевидным мне кажется его применение в иерархии UIView.  Существуюющую систему типов менять нет смысла, достаточно ее дополнить. 

Идей следующая:

Обьекты должны порождаться от прототипов. 

У обьекта есть только 1 прототип. 

По умолчанию все свойства обьекта беруться от прототипа.

Наследник может перекрывать свойства прототипа.

Каждый обьект представляется как суперпозиция прототипа и измененных свойств.

Что дают нам эти свойства? Они позволят проще выводить повторяемые елементы, и проще шаблонизировать вид.

Например, Вы создаете объект UILabel задаете ему цвет, шрифт и выравнивание. Далее порождаете от этого обьекта другой обьект. И новый обьект обладает теми же параметрами что и прототип!

Далее веселее, при изменении прототипа все наследники изменятся автоматически! За это надо отдельно сказать спасибо KVO и ReactiveCocoa.

Если наследник изменит какое то свойство, оно перекроет свойство прототипа, и не изменения прототипа не будут влять.

Если вы используете более или менее активный вид вместо вложенных UIViewController’ов, вам прийдется решить проблему передачи данных в вид. Использовать напрямую объекты бизнес логики нежелательно, так как виду от них требуется часть или формат удобный для бизнес процессов будет неудобен для вида. Сегодня мне пришлось решить подобную проблему. 

То что получилось в итоге можно применять в дальнейшем. Набор данных поступает по протоколу, который ограничивает исходную модель. Этот подход имеет несколько ограничений. Например возможен конфликт имен, или возвращаемых типов. В таком случае выглядит логичным класс обертка, который выполнит все преобразования.