Процедурный: Каждая строка кода представляет собой инструкцию, инструкцию для компьютера. Компьютер выполняет линии сверху вниз
Когда он добирается до ‘go to’, он меняет свою точку выполнения — идёт в другую линию.
Это было нормально, но затем было введено структурированное программирование, мы избавляемся от «идти к»,
Это то же процедурное программирование — перемещение сверху вниз, но немного структурировано.
У нас есть «if», «else», «while», но больше не «GOTO», удобнее читать.
Хотя Java предположительно объектно-ориентированная, Мы всё ещё двигаемся сверху вниз.
У нас все еще есть такие структуры: «если», «while», «else»,
Мы даже используем объекты где-то. У нас есть класс утилиты, некоторые элементы объектно-ориентированного программирования
Но это всё ещё процедурное программирование.
В чём проблема процедурного программирования?
Ремонтопригодность. Мы должны сделать этот код дольше, если мы хотим его изменить или улучшить. Он будет неизбежно расти.
Будет больше структур «if then then else».
Java-программисты попали в эту ситуацию много лет назад
Им нужно было улучшить этот недостижимый код, перейти на более удобную модель.
Так что их легче поддерживать удаленно от остальной части кода
Вот почему были введены процедуры
Многие проблемы решаются с помощью служебных классов
Создаются огромные классы, Различные процедуры передаются в них и используются.
Проблема в том, что она не имеет ничего общего с объектно-ориентированным программированием
Это то же самое процедурное программирование
Основная проблема здесь
Эти статические методы не имеют состояния
Процедуры
Некоторые данные поступают к ним, они что-то делают с ним и возвращают данные обратно
Ничто не инкапсулировано.
У них нет состояния между вызовами
Принимая статические блоки, откладывая процедуры и помещая их в служебные классы
Приводит к тому, что мы должны передавать данные между этими служебными классами
Мы должны отдать данные и вернуть новые данные
Иногда мы не выдаем никаких данных и просто получаем что-то от них
В других случаях мы отдаем данные, обрабатываем их
Тем не менее, они ничего не сохраняют между этими двумя вызовами
У них нет состояния
Они не инкапсулируют состояние
Объектно-ориентированное программирование — всё об инкапсуляции
Вот как выглядела наша программа без ООП:
Существуют три переменные
Алгоритм работает с ними
Мы все еще должны держать эти данные и помнить об этом
Нет инкапсуляции
Поддержание работоспособности не улучшается
Мы по-прежнему фокусируемся на данных
Нам еще нужно помнить, что означает n, t, x
Мы всегда наблюдаем алгоритм
Алгоритм работы всегда впереди нас
Мы не уменьшаем сложность проблемы
Задача, которую мы решаем, и алгоритм, который мы реализуем, все еще сложны
Мы всегда смотрим на данные
Но объектно-ориентированное программирование отличается
Мы должны инкапсулировать данные внутри объекта.
Больше нет алгоритма Мы больше не видим данных. У нас нет контроллера.
Мы переносим объект на другой объект, он называется композицией объекта.
В результате у нас есть один большой объект.
Мы не можем этого сделать, если у нас есть статические методы.
Нет ничего, чтобы инкапсулировать.
Мы не можем переносить статический метод в другой статический метод
У нас есть объект, инкапсулирующий.
И более крупный, и еще больший.
Они не расположены горизонтально, они не на одном уровне
Некоторые из них меньше, некоторые из них больше.
Мы всегда инкапсулируем во что-то.
Класс мал и понятен.
Легче расширять и дополнять этот код
Добавление новых функций — это просто добавление новых классов.
Они будут украшать или обертывать существующие классы.
Да, это действительно необычно.
Мы больше привыкли к что у нас есть «начало» наверху и «остановка» внизу.
Но это мышление ориентировано на компьютер.
Мы помним, что перед нами компьютер.
Мы должны дать ему указания следовать
Это необходимо и процедурно.
Императив — даём указания, и они выполняются.
Декларатив — мы объявляем результат.
Независимый блок кода = независимый человек.
Моё мышление теперь кажется перевёрнутым.
Я не думаю с точки зрения того, что я должен извлечь из этого блока памяти в этот (возьмите эту переменную, сохраните ее …).
Я всегда думаю о результате.
Я всегда придерживаюсь результата, а не логики.
Это может быть противоречивым для большинства.
Если мы усложним этот алгоритм, будут добавлены новые классы. Эта матрёшка будет расти вправо.
Идея в том, что композиция всегда будет в одном файле.
Сложность программы всегда будет в одном месте.
Все классы будут небольшими.
Если я нажму на любой из них, я попаду в маленький и понятный блок кода.
Там есть нулевая сложность.
Сложность кода очень низкая.
Каждый из них выполняет свою задачу.
Легко проверить.
Легко написать для него единичный тест.
Всё для этого легко.
Всегда есть центральный файл, называемый «вход» или «основной»,
Он может содержать 500 или 1000 строк кода
Там нет инструкций.
Просто построение объекта. Большой объект.
Если вы посмотрите на нее логически, объектно-ориентированный код — это огромная матрешка, Она собирается и живёт.
Мы должны уметь видеть, как это происходит
Мы должны увидеть, как собирается наше программное обеспечение.
Это самый важный блок кода, программный элемент.
Работаем с кусками, но мы не понимаем, как они связаны — именно здесь не понимаются методы программирования.
Создание объекта должно быть видимым.
Этот блок является самым важным и священным, мы должны хорошо его видеть.
Вот почему я против контейнеров для инъекций зависимости.
Серверы дешевле людей — компьютеры дешевле, чем вы и я.
Время программистов для разработки и улучшения кодовых затрат больше, чем новый сервер Amazon за 25 долларов США в месяц.
У вас будут фреймворки = Это главная проблема.
У вас будут рамки, с которыми вы должны работать.
Статические методы и классы полезности будут там.
Создание объектов всегда будет сложным
Часто бывает проще вызвать статический метод и сделать его снова.
Но мышление может постоянно изменяться
Я предлагаю начать думать в этом направлении
Компактный и понятный.
Нет сеттеров, геттеров или статических методов.
У них нет состояния, поэтому мы не можем построить основную структуру.
Я не могу обернуть статический метод во что угодно.
Невозможно положить что-то внутри статического класса.
Они ввели эти статические классы, чтобы сделать его несложны, но наш код стал более сложным.
Они упростили код, не создавали объекты или не думали о именах классов или о повышении производительности, просто дали нам несколько процедур, которые они взяли у C. Они не понимали этого хорошо. Они дали нам служебные классы, чтобы им было легче = Нам стало тяжелее.
Наш код становится сложным.
Мы пишем огромные контроллеры.
Этим приходится манипулировать вызовами для этих статических классов.
Нам будет легче, если у нас есть инкапсуляция.
Это идея ООП.
ООП лучше, чем ПП, поскольку он упрощает код.
Я считаю, что статика — это осложнение.
Что касается библиотек:
Очень сложно разработать код, чтобы не было статических методов и процедур.
Вы должны думать о своих объектах, их именах и интерфейсах.
Попытайтесь избавиться от библиотеки и создать вместо него 50 объектов.
Утилитные методы действительно быстрее. Но код не имеет ничего общего с композицией объекта. Здесь нет композиции.
Объектно-ориентированное программирование — о том, как сделать код более мощным
Добавляя более сложные объекты вокруг меньших.
Мы разворачиваем его снизу вверх.
Важно показать иерархию, чтобы получить литературный стиль.
Иерархия является центральной и самой важной вещью, которую я хотел показать
Эта матрешка, меньшая часть в большем.
Это самое важное в объектно-ориентированном программировании.
Если ваш код не имеет его, это не ООП
Если ваши объекты не собираются друг в друга, а расположены друг к другу и каждый из них выполняет одну задачу, Вы даете ему что-то, оно работает и возвращает результат Это не ООП !
Даже если вы избавитесь от служебных классов и замените их на объекты утилиты.
Если у нас есть объекты по сторонам и код в центре с переменными. Это ничего не изменит.
У нас должна быть композиция.
Мы должны собрать нашу программу из объектов.
У нас не должно быть объектов по сторонам, программа в центре.
Объекты должны собираться как матрешка
Когда матрешка собрана, мы даем ей контроль и она начинает жить.
Мы описываем результат, мы описываем «что мы достигаем», а не «как»,
Действительно, IDE создается, чтобы нам легко работать с классами утилитными.
Вся IDE написана для этого стиля программирования.
Как мне собрать матрешку?
Как найти эти объекты в библиотеке?
По их именам.
Наверное, если я напишу «угадай», я пойму, что это что-то вставленное.
Я стараюсь дать им правильные имена, которые легко запомнить
Обратите внимание: каждое слово здесь является существительным.
Каждое имя класса должно быть существительным.
Нет классов, заканчивающихся на ‘-er’.
Если ваше имя класса заканчивается на ‘-er’ или ‘-or’ — это не класс и объект, а часть процедуры.
Нет контроллеров, менеджеров, валидаторов, принтеров, кодеров, декодеров.
Эти имена неверны.
Все имена должны быть существительными.
Лестница.
если мы думаем как объекты Мы думаем от самого большого до наименьшего
Или от наименее до величайшего
Программирование не должно быть вертикальным.
Если мы будем думать вертикально, Это компьютерное мышление.
Если мы думаем с точки зрения композиции
И построение чего-то большего из чего-то меньшего.
Эта «лестница» является естественной.
Это наш образ мышления Мы создаем «лестницу» специально.
На нашем языке, EO, все будет лестницей.
Абсолютно.
Мы постараемся сделать как можно меньше пробелов, но это должно выглядеть как лестница.
Вы не будете бороться с вертикальным расширением кода?
Мы ничего не выполняем, мы строим
Мы продолжаем строить.
«if else» должны быть объекты.
В идеале мы должны избавиться от всех утверждений, которые были получены от Basic
И просто оставить состав объекта
Аннотации плохи
Если нам нужно прокомментировать код, у кода проблемы.
Код должен быть понятным, его не читают секретари, он читается программистами.
Если я пишу это, и мой коллега-программист не может его прочитать, означает, что я написал что-то неправильно.
Я поддерживаю документацию, но я против аннотаций.
В чем разница между ними?
Аннотации объясняют, что непонятно.
Документация берет некоторое представление из кода.
Так что я не хожу в исходный код все время.
Я должен читать Java.doc снаружи и понимать его
Классы и методы должны быть задокументированы.
Блоки Java.doc, которые мы создаем вне, очень важны. Не должно быть никакой документации метода внутри
Есть инструмент, который мы используем во всем нашем проекте, анализатор кода статистики для Java, называемое Qulice
Он запрещает любую аннотацию внутри метода.
Если вы помещаете аннотацию внутри тела метода
Он покажет ошибку, код не будет запущен
Аннотирование или пустая строка.
Это две ошибки кода
Если вы используете пустые строки в теле метода — Это проблема с кодом.
Если вы используете аннотации, это также проблема.
Метод должен быть малым и целым, 5-7-10 строк кода.
Они должны стоять вместе, делая одно, и быть полностью понятными.
Если это не так, разделите его на более мелкие методы.
Не оставляйте пустые строки, это типично и глупо.
Написание аннотаций с тем, что происходит, является еще одной ошибкой
Если не ясно, что происходит, сделайте его отдельным методом и напишите Java.doc
Были бородатые парни, говорящие, что в ООП не очень хорошо, когда объекты притягиваются друг к другу методами.
Фактический ООП — это генерация событий и реакций на них. Они не тянут друг друга, но прислушиваются к событиям и реагируют.
В этой парадигме, игра выглядит не как одна огромная матрешка, но как мир, населенный некоторыми объектами, связанными друг с другом.
Это вместе реагирует на события, происходящие снаружи и друг с другом.
Это неправильная идея. Как они помогут нам устранить проблемы ремонтопригодности?
Код не станет проще.
У нас просто будет много объектов, Данные останутся открытыми, Данные будут перемещаться между объектами в виде сообщений. Будет много данных,
Мы по-прежнему будем программировать на основе данных, Мы по-прежнему будем в одном процедуре Basic.
Мы должны скрыть данные!
Объекты должны передавать данные только в направлении от большего объекта к меньшему или наоборот.
Передача данных в горизонтальной модели,
когда есть объекты, которые вызывают методы друг друга.
Это не правильно
Они должны сначала инкапсулировать друг друга. Затем они должны обмениваться данными.
Горизонтальное позиционирование объектов — это процедурное программирование
У меня есть объекты ‘x’ и ‘t’
Я прошу ‘t’ дать мне что-то, а затем дать ему ‘x’
Или скажите ‘t’ взять что-то в одно место, ‘x’ другому
Эта передача данных делает данные открытыми
Данные летают в свободном пространстве
Мы теряем идею инкапсуляции
Клиент был недоволен
Идея заключалась в том, что она должна работать в шесть раз быстрее
Мы начали профилировать, где он работал медленнее
Сбор мусора действительно был одной из самых больших проблем в производительности.
Мы заменили наши объекты статическими методами в 4 или 5 местах благодаря профилированию
У нас было 120 объектов Они были уменьшены до 115
Но мы изменили объекты на статические методы в 5 местах
Он работал в шесть раз быстрее
Но у нас все еще было 125 объектов в таком формате
Производительность имеет значение для телефона.
Но не 100% вашего кода будет соответствовать производительности
Производительность не имеет значения для большей части кода.
Однако, если вы читаете документацию на Android, Google превращают программистов в процедурных обезьян благодаря Android.
Я написал в нем полгода, это был кошмар.
И в документации объясняется, почему так хорошо
ООП не является панацеей.
ООП — не единственный способ.
Там функциональное программирование, это также отличный подход.
Я просто не эксперт в этом.
Есть логическое программирование, Prolog, другие подходы.
Но нам нужен подход, который логичен.
Я вижу логику в ООП.
Я не вижу логики в старом, неподъемном, глупом, тяжелом процедурном подходе
Поэтому я предлагаю заменить его на ООП.
Такой подход стал для меня решением.
Я работаю над ним несколько лет,
мне нравится.
Если мы будем использовать объекты, мы будем в пять раз медленнее.
Производительность менее важный вопрос, чем удобство и понимание кода.
Мало кто нуждается в хакерах, которые пишут супер быстрый код.
Код должен быть понятным.
Проектирование, разработка и поддержка программного обеспечения 