Ладно начнем тему истории ООП.
Сразу оговорюсь - я не считаю это чем-то важным для программиста, но и бесполезным тоже не считаю.
Так-как твиттер не то мест, где можно много написать, то пройдусь по важным моментам только.
Начнем с опроса:
Правильный ответ на опрос "ты серьезно?". И опечатку я совершил случайно, но когда увидел решил оставить.
Подвох был в том, что я не уточнил в какое время то нужно считать сколько было принципов.
Удивлен, что кто-то ответил 7 - видимо есть еще люди знающие историю
Как говорится вначале было слово, ну точнее до ООП было :) термин ООП ввел Алан Кей, в 1970х годах, для языка smallTalk. Но многие считают, что первым языком был все-же simula67.
На всякий случай повторим, что же такое ООП, конечно это можно и в интернете найти:
Но на всякий случай повторимся. ООП - это, методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования.
Интересней всего, что думал/говорил Алан Кей в те времена. Да он придумал термин объект. Но его идея ООП была не в этом, а в передаче данных. Вот одни из его слов:
"ООП для меня означает лишь обмен сообщениями, локальное сохранение, и защита, и скрытие состояния, и крайне позднее связывание"
И условно говоря, он говорил, что ООП это: обмен сообщениями и инкапсуляция.
Тут все это подробней: habr.com/ru/company/ruv…
Обмен сообщениями где-то позабыли по дороге, и теперь в ООП такого понятия нет. Алан Кей кстати об этом сильно сожалеет, что его поняли не верно.
Но хоть инкапсуляцию поняли - один из принципов которые и по сей день актуален.
Мне нравится очень такое определение Инкапсуляции - это объединение и сокрытие данных. Просто, лаконично.
Кстати не представляю как можно писать на ООП не используя этот принцип :)
Ладно идем дальше. Тут быстренько разобрались. А теперь Java программисты - вы в курсе что язык Java соответствует 7 принципам ООП? Думаю многие даже не в курсе, что был виток развития ООП где было 7 принципов, и java язык который был сделан по ним.
Но интересно, что в Университете нам преподавали именно эти принципы ООП. Хотя на тот момент уже актуально было другое понимание.
А сами принципы такие:
Абстрагирование, Инкапсуляция, Модульность, Иерархичность + Типизация, Параллелизм, Сохраняемость
Давайте быстро:
Абстрагирование - процесс при котором мы выделяем абстракции. Абстракция фокусируется на существенных с точки зрения наблюдателя характеристиках объекта.
И это одна из самых сложных задач в ООП - правильно выделить абстракции.
Инкапсуляцию уже разбирали.
Модульность: Это свойство системы, которая была разложена на внутренне связанные, но слабо связанные между собой модули.
Модуль сильно связан внутри и слабо связан во вне.
Иерархия: Это упорядочивание абстракций, расположение их по уровням.
Иерархичность - ООП программы должны образовывать иерархию :)
Типизация – это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием
Параллелизм – это свойство, отличающее активные объекты от пассивных
Сохраняемость – способность объекта существовать во времени, переживая порождающий его процесс, и (или) в пространстве, перемещаясь из своего первоначального адресного пространства.
Вот быстро 7 принципов. Они написаны в книжке Гради Буча Объектно Ориентированный Анализ и Дизайн. Можете почитать - интересное чтиво.
Зачем я их тут написал? об этом попозже, давайте посмотрим на современные принципы ООП.
А современных принципов, то ли 4 то ли 3:
Полиморфизм, Наследование, Инкапсуляция. И еще иногда добавляют Абстрагирование.
И тут самое интересное - скок бы я не искал, везде пишут эти принципы, но ни где не пишут откуда и когда они взялись.
Давайте рассмотрим и их. Два мы уже смотрели выше.
Наследование это - свойство системы, позволяющее описать новый класс на основе уже существующего с частично или полностью заимствующейся функциональностью
Полиморфизм это - Свойство системы, позволяющее использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта.
Кстати полиморфизмов бывает много, и разных. Вики в помощь. Короче это не только слово override :)
Так это краткий экскурс в теории. А теперь все-же к истории, и выводам.
Термин ООП ввел Алан Кей имея ввиду smallTalk 1972 год. JS программисты радуйтесь - ваш язык истинный ООП. И там была основа в посыле сообщений.
Кто-то говорит, что язык simula67 тоже был ООП.
Дальше Гради Буч выдвигает своё мнения о ООП, которые записаны в книге ООАД. Это около 90 годов. Скорей всего это мнение он взял из того, что витало тот момент в воздухе.
И пишется язык java под этот ООП.
Потом в приблизительно 2010 годах кто-то создает новое понятие ООП и как-то его вписывает в массы.
Теперь к выводам из всей этой микро истории, которую обычно я рассказываю больше часа :D
1. Скорей всего ООП еще будет меняться. 2. Выражайте свои намерения более четко и ясно - а то будет как с Аланом Кей - имел одно, все поняли другое. 3. Иерархичность - это то, что должно быть присуще вашей ООП программе. А наследование и полиморфизм только частные случаи
4. Когда-то модульность это было что-то новое и крутое, сейчас это наша реальности - не стоит от нее бежать - это лишь еще один уровень в вашей иерархией над классом.
Кстати посмотрите на swift - там убрали слово protected. Apple как-бы намекает - к черту наследование, используйте модульность. Да и бесполезность public + open без модулей, тоже намекает на это.
5. В 90 годах параллелизм тоже был чем-то новым. Сейчас эта наша реальность. Задумайтесь над определением "свойство системы, отличающее активные объекты от пассивных"
Я это определение очень долго не мог понять, но в нем есть какая-то магия :)
6. Никогда не забывайте про инкапсуляцию - делайте ваши классы максимально закрытыми.
Да получилось слегка сумбурно. Но я не планировал это рассказывать - я такое больше люблю устно рассказывать.
Ну и еще одна интересная чтука, которую я люблю рассказывать вместе с абстрагированием:
Принцип наименьшего удивления - абстракция должна охватывать все поведение объекта, но не больше и не меньше, и не привносить сюрпризов или побочных эффектов, лежащих в нее сферы применимости
Это отличное описание к тому, что такое хороший модуль/класс/метод - чем меньше вы удивляетесь при попытке его понять/прочитать, тем лучше этот модуль/класс/метод
• • •
Missing some Tweet in this thread? You can try to
force a refresh
И сразу ответ - идти туда не стоит. Исключение: если вы не способны за собой даже смыть в общественном туалете, то вам стоит 😂
Вот таких личностей там быстро воспитывают.
Так был я в войсках связи. Сейчас я сержант - это три полоски. Являюсь командиром командно штабной машины. В мои задачи входит поддержание связи со штабом для капитанов во время движения и в поле.
Вначале я учился в учебе пол. Года. Там было почти скучно - снег кидали на дорогу, потом с дороги.
Ну пожалуй самое весёлое это люди переболевшие по 3 раза ветрянкой за пол. Года.
Но жили мы на болоте/торфе. Весной стало жарко - ну чтож тушить палками горящий лес возможно 😂
Теперь поговорим про "прогнозы" на 5-10 лет.
Начнём с главного - я не пытаюсь делать прогнозы даже на 2 года, слишком всё меняется.
Поэтому этот поток надо назвать "мои мечты о будущем" чем реальные прогнозы.
Первая моя надежда на ближайшие два года - появление iGlass. И я верю, что apple сделаю то, что нужно рынку.
Возможно захватит мир только 2/3 поколение, но apple не должны накосячить тут.
И они изменять наш UI/UX. И думаю намного больше чем появление часов.
Скорей всего спрос на AR технологии вырастет после не только у apple. И люди чаще начнут взаимодействовать с миром через AR
Первый мини поток - 10 пальцевая печать.
Вначале зачем? Я будучи коммерческими разработчиком писал двумя пальцами вначале, и мне не мешало... Но я решил переучиться всеже.
Мотивация одна: пока я напишу код, я уже забуду, что я писал 😅
Собственно говоря ради этого и нужен 10 пальцевых набор - чтобы максимально быстро и максимально не задумываясь о клавиатуре его записать.
Экономия ресурсов мозга получается значительной.
P.S. тоже самое и к перемещению по коду/проекту
А теперь как я учился. Поскольку начинал я в гипсе (на левой руке) то клавиатуру я сразу освоил криво. И писал около 7 лет по итогу такая двумя пальцами. Быстро тыкая - 180 символов в минуту 😅
Но в какой-то момент понял - надо переучиваться, так дело не пойдет
Возвращаемся к этой теме. Из около 10 проектов где я был в 4 мне понадобилось это знание, и в 3 я правил баг связанный с этим.
Вначале что это такое вообще, а потом одна самая прикольная история на это.
И так bigEndian и littleEndian относиться - о чудо к записи числа. Как всем известно у нас в памяти идут битики 01001011 :) 8 битиков это один байт (но не везде 8) но число обычно занимает не один байт, а 4 или 8.
Внутри одного байта все биты всегда идут в одном порядке - справа младший разряд слева старший. А вот байты можно переставлять - у кого-то справа старший байт у кого-то слева.
Так и появляется два типа записи: bigEndian и littleEndian.
И тут я открываю ещё один поток, связанный с хорошим кодом, и дебагом. Хороший код должно быть легко дебажить - ибо мы точно в наших условиях написания кода допустим баги. И не всегда есть доступ к устройству.
Да тред про логи, но начнём с assert 😅
assert - функция которая нужна для программистов и отсекается в дебаге. Может иметь ещё названия: precondition, postcondition. Но суть у них одна.
С ней стоит быть аккуратней - нельзя в ней писать код, который что-то может изменить.
А то в дебаге работает, в релизе нет :)
Её мы используем, когда мы хотим сообщить себе/другим программистам, что что-то пошло не так - чаще всего какие-то данные отличаются от тех, что планировались.
Но код должен нормально продолжать работать при этом.