Как я нарушаю свои процедурные навыки кодирования?

Ответ 1

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

Во-вторых, я читал о шаблонах дизайна. Трудно понять ОО без каких-либо примеров реальных проблем, которые это хорошо для решения. Head First Design Patterns хорошо читается, так как он отвечает на многие вопросы "почему" OO.

Ответ 2

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

• Наслаждайтесь композицией над наследованием. Прочитайте и перечитайте первую главу GoF book.
• Послушайте Закон Деметры ( "расскажите, не спрашивайте" )
• Попробуйте использовать наследование только для достижения полиморфизма. Когда вы расширяете один класс от другого, делайте это с идеей, что вы будете вызывать поведение этого класса с помощью ссылки на базовый класс. ВСЕ общедоступные методы базового класса должны иметь смысл для подкласса.
• Не зацикливайтесь на моделировании. Создайте рабочий прототип, чтобы сообщить свой дизайн.
• Реформирование Embrace. Прочитайте первые несколько глав Книга Фаулера.

Ответ 3

принцип единой ответственности помогает мне разбить объекты на управляемые классы, которые имеют смысл.

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

Ответ 4

Класс "менеджер" часто:

• Взаимодействие чего-то состояния
• Принять решение на основе этого состояния

Как антидот или контраст с этим, объектно-ориентированный дизайн будет поощрять вас разрабатывать API классов, в которых вы "не спрашиваете" сам класс, чтобы самому делать (и инкапсулировать его собственное состояние): более подробно "скажите, не спрашивайте", см. например здесь и здесь (и, возможно, у кого-то есть лучшее объяснение "скажите не спрашивайте", но это первые две статьи, которые Google нашел для меня).

Похоже, что основная стратегия, которую мы создаем маленький OO-код, - это разбить проблему на классы, которые легко идентифицируются как дискретные единицы, а затем помещать левые над/обобщенные биты в класс "Менеджер".

Это может быть правдой даже в лучшие времена. Коплиен говорил об этом в конце своей книги "Сложности и идиомы программирования": он сказал, что в системе вы, как правило, имеете:

• Автономные объекты
• И "транзакции", которые действуют на другие объекты

Возьмем, к примеру, самолет (и я сожалею, что дал вам еще один автомобильный пример, я перефразирую его):

• "Объекты" могут включать элероны, руль и тягу.
• "Менеджер" или "Автопилот" будут выполнять различные команды или транзакции.

Например, транзакция "повернуть направо" включает в себя:

• flaps.right.up()
• flaps.left.down()
• rudder.right()
• thrust.increase()

Итак, я считаю, что у вас есть транзакции, которые пересекают или используют различные относительно пассивные "объекты"; в приложении, например, "любая" пользовательская команда в конечном итоге реализуется (и, следовательно, вызывает) различные объекты из каждого уровня (например, пользовательский интерфейс, средний слой и уровень БД).

Итак, я думаю, что правда, что в определенной степени у вас будут "бит, оставшиеся"; это вопрос степени, хотя: возможно, вы должны хотеть, чтобы максимально возможный код был автономным и инкапсулировался, и все... и оставшиеся бит, которые используют (или зависят от) все остальное, должны быть предоставленным/использующим API, который скрывает как можно больше и который делает как можно больше, и поэтому берет на себя как можно большую ответственность (подробности реализации) от так называемого менеджера.

К сожалению, я только прочитал эту концепцию в этой книге (Advanced С++) и не могу связать вас с чем-то онлайн, чтобы получить более четкое объяснение, чем этот парафраз.

Ответ 5

Чтение, а затем практика принципов OO - это то, что работает для меня. Head First Object-Oriented Analysis and Design работает с примерами, чтобы сделать решение, которое является OO а затем способы сделать решение лучше.

Ответ 6

Вы можете изучить хорошие объектно-ориентированные принципы проектирования, изучив шаблоны проектирования. Code Complete 2 - хорошая книга для чтения по этой теме. Естественно, лучший способ внедрить в вас хорошие принципы программирования - постоянно практиковать их, применяя их к своим собственным проектам кодирования.

Ответ 7

Как я могу нарушить свои процедурные привычки (например, класс Manager)?

Создайте класс для управления менеджером (например, если у вас есть класс ConnectionManager, создайте класс для подключения). Переместите все в этот класс.

Причина "менеджер" - плохое имя в ООП, так это то, что одна из основных идей в ООП заключается в том, что объекты должны управлять собой.

Не бойтесь делать небольшие занятия. Исходя из процессуального фона, вы можете подумать, что не стоит прилагать усилий для создания класса, если это не тысяча строк кода и не является основной концепцией в вашем домене. Думайте меньше. Класс десяти строк полностью действителен. Создавайте небольшие классы, где вы видите, что они имеют смысл (дата, почтовый адрес), а затем работают с ними, составляя классы из них.

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

Ответ 8

Сколько программистов ООП требуется, чтобы изменить лампочку?

Нет, лампочка сама меняет.

;)

Ответ 9

Вы можете играть с языком OO, который имеет очень плохую процедурную поддержку, например Smalltalk. Парадигма отправки сообщения заставит вас думать ОО.

Ответ 10

Я думаю, вы должны начать с хорошего плана. планирование с использованием диаграмм Класса было бы хорошим началом.

вы должны идентифицировать ВСЕСТИ, необходимые в аппликации, затем определите каждый атрибут АТРИБУТЫ и МЕТОДЫ. если есть повторяющиеся, теперь вы можете переопределить свои сущности чтобы можно было наследовать, чтобы избежать избыточности. .: D

Ответ 11

Мое время эврики для понимания объектно-ориентированного дизайна было, когда я прочитал книгу Эрика Эванса "Разработка, управляемая доменами: борьба с сложностью в сердце программного обеспечения" . Или "Быстрое создание домена" ) мини-книгу (которая доступна онлайн как бесплатный PDF), если вы дешевы или нетерпеливы.:)

Каждый раз, когда у вас есть класс "Менеджер" или какие-либо статические экземпляры singleton, вы, вероятно, создаете процедурный дизайн.

Ответ 12

У меня есть трехэтапный процесс, это тот, который я успешно прошел сам. Позже я познакомился с бывшим учителем, превратившимся программистом (теперь очень опытным), который объяснил мне, почему именно этот метод работал так хорошо, там есть какая-то психология, но по сути это все о поддержании контроля и уверенности, когда вы учитесь. Вот он:

• Узнайте, что такое тестовая разработка (TDD). Вы можете с комфортом сделать это с помощью процедурного кода, поэтому вам не нужно начинать работу с объектами, если вы этого не хотите. Второй шаг зависит от этого.

• Подберите копию Рефакторинга: Улучшение дизайна существующего кода Мартина Фаулера. Это, по сути, каталог небольших изменений, которые вы можете внести в существующий код. Однако вы не можете правильно реорганизовать без тестов. То, что это позволяет вам делать, - это возиться с кодом, не беспокоясь о том, что все сломается. Тесты и рефакторинг забирают паранойю и ощущение, что вы не знаете, что произойдет, что невероятно освобождает. Вы ушли, чтобы в основном поиграть. По мере того, как вы становитесь более уверенными в том, что начинаете изучать макеты для тестирования взаимодействия между объектами.

• Теперь наступило большое, что большинство людей, с самого начала ошибочно, это хороший материал, но на самом деле это должно стать третьим. На этом этапе вы можете прочитать о шаблонах проектирования, запахах кода (что хорошо для Google) и объектно-ориентированных принципов дизайна. Также ознакомьтесь с рассказами пользователей или примерами использования, поскольку они дают вам хорошие начальные классы-кандидаты при написании новых приложений, что является хорошим решением для "с чего начать?". проблема при написании приложений.

И это! Доказанная доброта! Дайте мне знать, как это происходит.