Ладно начнем тему истории ООП.
Сразу оговорюсь - я не считаю это чем-то важным для программиста, но и бесполезным тоже не считаю.

Так-как твиттер не то мест, где можно много написать, то пройдусь по важным моментам только.

Начнем с опроса:
Правильный ответ на опрос "ты серьезно?". И опечатку я совершил случайно, но когда увидел решил оставить.
Подвох был в том, что я не уточнил в какое время то нужно считать сколько было принципов.
Удивлен, что кто-то ответил 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
 

Keep Current with Мобильный разработчик

Мобильный разработчик Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @mobileunderhood

7 Feb
Поток, про потоки :) Ну точнее просто тут будет собрано, что я интересного писал за неделю.
Поток про мою финансовую безграмотность, и про то, что не стоит идти против своих принципов:
10 задачек на "алгоритмы" которые мне приходилось решать:
Read 14 tweets
7 Feb
Потихоньку переходим к армии.

И сразу ответ - идти туда не стоит. Исключение: если вы не способны за собой даже смыть в общественном туалете, то вам стоит 😂

Вот таких личностей там быстро воспитывают.
Так был я в войсках связи. Сейчас я сержант - это три полоски. Являюсь командиром командно штабной машины. В мои задачи входит поддержание связи со штабом для капитанов во время движения и в поле.
Вначале я учился в учебе пол. Года. Там было почти скучно - снег кидали на дорогу, потом с дороги.
Ну пожалуй самое весёлое это люди переболевшие по 3 раза ветрянкой за пол. Года.

Но жили мы на болоте/торфе. Весной стало жарко - ну чтож тушить палками горящий лес возможно 😂
Read 18 tweets
7 Feb
Теперь поговорим про "прогнозы" на 5-10 лет.
Начнём с главного - я не пытаюсь делать прогнозы даже на 2 года, слишком всё меняется.
Поэтому этот поток надо назвать "мои мечты о будущем" чем реальные прогнозы.
Первая моя надежда на ближайшие два года - появление iGlass. И я верю, что apple сделаю то, что нужно рынку.
Возможно захватит мир только 2/3 поколение, но apple не должны накосячить тут.
И они изменять наш UI/UX. И думаю намного больше чем появление часов.

Скорей всего спрос на AR технологии вырастет после не только у apple. И люди чаще начнут взаимодействовать с миром через AR
Read 12 tweets
7 Feb
Первый мини поток - 10 пальцевая печать.
Вначале зачем? Я будучи коммерческими разработчиком писал двумя пальцами вначале, и мне не мешало... Но я решил переучиться всеже.

Мотивация одна: пока я напишу код, я уже забуду, что я писал 😅
Собственно говоря ради этого и нужен 10 пальцевых набор - чтобы максимально быстро и максимально не задумываясь о клавиатуре его записать.

Экономия ресурсов мозга получается значительной.

P.S. тоже самое и к перемещению по коду/проекту
А теперь как я учился. Поскольку начинал я в гипсе (на левой руке) то клавиатуру я сразу освоил криво. И писал около 7 лет по итогу такая двумя пальцами. Быстро тыкая - 180 символов в минуту 😅

Но в какой-то момент понял - надо переучиваться, так дело не пойдет
Read 11 tweets
6 Feb
Возвращаемся к этой теме. Из около 10 проектов где я был в 4 мне понадобилось это знание, и в 3 я правил баг связанный с этим.
Вначале что это такое вообще, а потом одна самая прикольная история на это.
И так bigEndian и littleEndian относиться - о чудо к записи числа. Как всем известно у нас в памяти идут битики 01001011 :) 8 битиков это один байт (но не везде 8) но число обычно занимает не один байт, а 4 или 8.
Внутри одного байта все биты всегда идут в одном порядке - справа младший разряд слева старший. А вот байты можно переставлять - у кого-то справа старший байт у кого-то слева.
Так и появляется два типа записи: bigEndian и littleEndian.
Read 13 tweets
6 Feb
И тут я открываю ещё один поток, связанный с хорошим кодом, и дебагом. Хороший код должно быть легко дебажить - ибо мы точно в наших условиях написания кода допустим баги. И не всегда есть доступ к устройству.
Да тред про логи, но начнём с assert 😅
assert - функция которая нужна для программистов и отсекается в дебаге. Может иметь ещё названия: precondition, postcondition. Но суть у них одна.
С ней стоит быть аккуратней - нельзя в ней писать код, который что-то может изменить.
А то в дебаге работает, в релизе нет :)
Её мы используем, когда мы хотим сообщить себе/другим программистам, что что-то пошло не так - чаще всего какие-то данные отличаются от тех, что планировались.
Но код должен нормально продолжать работать при этом.
Read 15 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!