Что нужно для того, чтобы стать лучше OO-программистом?

вы, вероятно, обнаружите, что элегантный объектно-ориентированный дизайн, который вам нравится не первая итерация, но является результатом нескольких корректировок, рефакторинга и тонких настроек

попытайтесь понять, почему вы думаете, что их дизайн «лучше», чем ваш, и внесите соответствующие изменения.

разница между писателем-любителем и писателем-профессионалом в том, что профессиональный писатель переписывает; то же самое касается программирования

знание и понимание шаблонов проектирования GoF (Gamma et al.) никогда не ошибается. их можно применять во многих ситуациях. я думаю, они необходимы каждому разработчику!

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

Для начала вам нужно знать некоторые шаблоны GoF, но, что более важно, вы должны понимать принципы, лежащие в основе шаблонов. Поймите различия между старым стилем (используйте наследование для повторного использования кода) и новым стилем (предпочитайте инкапсуляцию наследованию) oo design. Две хорошие книги для чтения: «Шаблоны проектирования, объясненные Шеллоуэем и Троттом» и «Гибкая разработка программного обеспечения», «Принципы, шаблоны и практики» Боба Мартина.

Тогда вам понадобится опыт. Теория в книгах хороша, но вам нужно точно настроить свое чувство того, когда что использовать. Как использовать процесс для точной настройки ваших проектов (Стивен А. Лоу уже назвал итерации). Многие старые-оо-гуру описывали итеративное программирование и оо-программирование в одних и тех же статьях и книгах.

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

[юмор]

Объектно-ориентированные навыки можно получить из книг и других ресурсов. Но если вам повезет, вы унаследуете навыки от своих родителей. В большинстве случаев это вопрос предоставления и использования правильного метода. Будьте осторожны с количеством аргументов. Чем меньше тем лучше.

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

Также важно скрыть неприятные детали. И не забудьте скрыть своих частных участников для широкой публики, иначе произойдет неожиданное поведение. Также будьте внимательны, чтобы правильно уловить свою исключительную ситуацию.

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

[/юмор]

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

Всего понемногу. Что касается любого языка (вербального программирования), чем больше вы познакомитесь с ним, тем больше вы узнаете.

Так что читайте книги, читайте кодекс коллег. И, что не менее важно, изучайте новые языки программирования: они расширят ваше видение, сделают вас более критичным по отношению к собственному коду и позволят переосмыслить свои привычки программирования.

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

Я бы еще добавил:

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

Привет и доброго дня всем

Как сказал Чери: «вы станете лучше объектно-ориентированным программистом, если на мгновение забудете об объектно-ориентированной ориентации и начнете писать более чистые и лучшие программы, одновременно улучшая свои существующие».

Это ключ: подумайте и получите максимально простое решение и напишите похожий код.

Это все Больше ничего .... пока-пока

Хороший ОО дизайн:

• это читается как стихи
• не нуждается в комментариях
• доверять своим объектам (отпустить контроль)
• предпочитать композицию наследованию

Помимо изучения академических материалов, таких как книги и статьи, я высоко рекомендую: изучать более одного языка, особенно если вы из мейнстрима Java / C#. Изучите Ruby, изучайте отличный язык, изучайте smalltalk, выучите шепелявку, изучите разницу между ними как в теории, так и на практике.

Академический, но отличный пример - это одно или несколько отправлений: вы можете проверить запись в Википедии и лично убедиться, как вы будете писать другой код в зависимости от языковых возможностей. Если говорить более фундаментально, это помогает вам понять, как добиться тех же эффектов на языке X, сохраняя при этом надежный дизайн.

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

Что-то, что у меня сработало, - это Чтение. У меня был момент Bulb с этой книгой ... Объект Дэвида Уэста Мыслиng, который уточняет Комментарий Алана Кея: «Объектная революция еще не произошла». OO - это разные вещи для разных людей .. Добавьте к этому тот факт, что ваши инструменты влияют на то, как вы подходите к решению проблемы. Так что учите несколько языков.

Объектное мышление Дэвид Уэст http://ecx.images-amazon.com/images/I/51hnvVxjQtL._SL500_BO2,204,203,200_AA219_PIsitb-sticker-dp-arrow,TopRight,-24,-23_SH20_OU01_.jpg

Лично я считаю, что понимание философии, принципов и ценностей, лежащих в основе практики, а не имитация практики, очень помогает.

Что мне подходит:

• Знайте домен своего приложения и оставайтесь ближе к нему как можно дольше, избегая при этом дублирования кода.

• Не придерживайтесь одного языка, изучите несколько объектно-ориентированных языков. У Smalltalk, Comon Lisp, Python, Javascript есть очень интересные способы реализации ООП. Просмотрите их источник (обозреватель объектов Smalltalk - отличный инструмент для этого).

• Реализуйте библиотеку ООП на языке, который не имеет стандарта ООП, например Lua: это покажет вам, что self/this может быть не чем иным, как неявным первым аргументом, указывающим на состояние и делегирующим свое поведение своему class/vtable/metatable (который, в свою очередь, может делегировать вызов его родительского class).

Ваше здоровье!

TDD у меня сработал. Написание тестов сначала без хорошего oo - настоящая PIA, поэтому мне пришлось стать лучше в этом.

Хорошее наставничество, когда эти люди садятся рядом с вами, когда у вас есть проблема, и решают ее вместе с вами. Вы понимаете, как они думают о вещах объектно-ориентированным способом.

Регулярные проверки кода. Думаю, больше всего я узнал из обзора кода команды, проведенного через PowerPoint, в котором к моему коду вылили некоторое презрение. Сконцентрировал мой разум, да.

Помогло, конечно, то, что я изучил объектно-ориентированный подход с помощью Smalltalk (каждый должен быть принужденный, чтобы делать это ИМХО). Язык всегда поощрял концепцию «отправки сообщения». То есть не вставлять здесь материал, написать новый метод и вызвать его (т.е. отправить сообщение и получить ответ **) результат? Простота, низкое сцепление, высокое сцепление.

** Когда я пишу свой JavaDoc для метода доступа, я все еще пишу «ответьте на [бла], который представляет [вещь]». Люди могут подумать, что я странный, но до сих пор никто не звонил в полицию ...

Очень важно, чтобы ваш дизайн кто-то рассмотрел. Обзор и поддержка устаревшего кода поможет вам понять, что делает программное обеспечение гнилым. Мышление тоже очень важно; Одной рукой не торопитесь воплощать в жизнь первую идею. С другой стороны, не думайте обо всем сразу. Делайте это итеративно.

Регулярное чтение книг / статей, таких как Модельный дизайн Эрика Эвана, или изучение новых языков (Smalltalk, Self, Scala), использующих другой подход к объектно-ориентированному программированию, поможет вам по-настоящему понять.

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

Это внезапно начало обретать смысл, когда я пытался уменьшить зависимости между классами, (java) пакетами и модулями, указать четкие границы модулей и удалить циклы в зависимостях. Особенно это удаление циклов принесло мне много идей. В идеале зависимости ваших классов / пакетов / модулей должны образовывать дерево.

Чтобы стать лучшим объектно-ориентированным программистом, нужно быть лучшим программистом.

ОО развивалось на протяжении многих лет, и это во многом связано с изменением парадигм и технологий, таких как многоуровневая архитектура, сборка мусора, веб-службы и т. д., Которые вы уже видели. Существуют фундаментальные принципы, такие как ремонтопригодность, возможность повторного использования, слабая связь, KISS, DRY, закон Амдала и т. д., Которые вы должны изучить, прочитать, испытать и применить самостоятельно.

ОО - это не самоцель, а скорее средство для достижения программных решений. Подобно играм, спорту и искусству, практики нельзя понять без принципов; и принципы не могут быть поняты без практики.

Чтобы быть более конкретным, вот некоторые из навыков, которые могут сделать человека лучшим программистом. Слушайте экспертов в предметной области. Умею писать тесты. Знайте, как разработать программное обеспечение для настольных ПК с графическим интерфейсом. Знайте, как сохранить данные в базе данных. Отдельный уровень пользовательского интерфейса и логический уровень. Знайте, как написать класс, который действует как встроенный класс. Знайте, как написать графический компонент, который действует как встроенный компонент. Знайте, как разрабатывать программное обеспечение клиент / сервер. Знайте сети, безопасность, параллелизм и надежность.

Шаблоны проектирования, MVC, UML, Рефакторинг, TDD и т. д. Решают многие проблемы, часто творчески расширяя OO. Например, чтобы отделить зависимости уровня пользовательского интерфейса от логического уровня, может быть введен интерфейс для обертывания класса пользовательского интерфейса. С чисто объектно-ориентированной точки зрения это может не иметь большого смысла, но имеет смысл с точки зрения разделения уровня пользовательского интерфейса и уровня логики.

Наконец, также важно осознавать ограничения объектно-ориентированного подхода. В современной архитектуре приложений пуристский взгляд на данные + логику объектно-ориентированного подхода не всегда очень хорошо сочетается. Например, объект передачи данных (Ява, РС, Фаулер) намеренно удаляет логическую часть объекта, чтобы он переносил только данные. Таким образом объект может превратиться в поток двоичных данных или XML / JSON. Логическая часть может каким-либо образом обрабатываться как на стороне клиента, так и на стороне сервера.

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

Я не уверен, что послужило причиной того, что человек понизил ответы, относящиеся к Smalltalk, но Smalltalk определенно имеет к этому какое-то отношение. Ключевое слово - метафоры. Для большинства программистов, а это фактически применяется в большинстве образовательных программ по информатике, центральные метафоры механические: часовой механизм или паровые двигатели.

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

То, как все эти объекты в Smalltalk работают вместе, следует этой метафоре. Мне также показалась интересной в этом контексте книга Кевина Келли: Out of Control, потому что в книге есть много примеров реальных решений, основанных на этой метафоре.

3 - магическое число; ни меньше, ни больше, и это везде.

Менее возможное наследование за счет минимизации подклассов.
Возможна слабая связь из-за наличия независимых объектов. Наклейте на него.

Объяснение по образцу.

Интерфейс первого шага - это определение доступа к вашей системе.

interface i { getObject($o); }

• С точки зрения веб-страницы это уникальный URL-адрес или параметр.
• С точки зрения MVC это Модель.
• С точки зрения Дерева это связь (ветвь) от родителя к потомку.

Второй шаг абстракции - это контроль над вашей системой.

abstract class Controller { 
     function getObject(){} 
     function validateObject(){

// o must be a digit
// o must be between 0 and 120
// ... etc
}
}

• С точки зрения веб-страницы это проверка требований, таких как пользователь вошел в систему, подключена база данных и т. д.
• С точки зрения MVC это Контроллер.
• С точки зрения Дерева это родитель.

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

class View extends Controller (InputObject $in, OutputObject $out) {

}

Доступные данные в этом конкретном классе также поступают с трех направлений.

• расширяет контроллер
• InputObject $ в
• OutputObject $ out

Этот объект презентации будет - С точки зрения веб-страницы вывод результата, содержание страницы. - С точки зрения MVC представление. - В плане Дерева лист.

Я рекомендую вам больше подумать об этих наборах Треугольника. Например, попробуйте

• устройство планет и их поведение на орбите в нашей солнечной системе.
• структура Автомобиля и его поведение, когда он будет ездить.
• причина и результат в разных статусах.