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

Имею почти 6-летний опыт разработки приложений с использованием технологий .net. На протяжении многих лет я улучшался как лучший программист OO, но когда я вижу код, написанный другими ребятами (особенно Джеффри Рихтером, Питером Голде, Айенде Рахиеном, Джереми Миллером и т.д.), Я чувствую, что между моим и их конструкций. Я обычно разрабатываю свои классы "на лету" с некоторой помощью таких инструментов, как ReSharper для рефакторинга и организации кода.

Итак, мой вопрос: "Что нужно, чтобы стать лучшим программистом OO". Это

a) Опыт

b) Книги (обратитесь пожалуйста)

c) Процесс (tdd или uml)

d) шаблоны

e) что-нибудь еще?

И как следует утверждать, что дизайн хорош, прост в понимании и обслуживании. Поскольку в промышленности так много ключевых слов, как инъекция зависимостей, IoC, MVC, MVP и т.д., Где нужно сконцентрироваться больше на дизайне. Я чувствую, что абстракция - это ключ. Что еще?

Ответ 1

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

попытайтесь определить, почему вы думаете, что их проекты "лучше", чем ваши, и соответственно корректируйте

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

Ответ 2

[юмор]

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

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

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

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

[/юмор]

Ответ 3

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

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

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

Я бы добавил:

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

Помимо обучения в академических материалах, таких как книги и документы, я рекомендую высоко: изучать более одного языка, особенно если вы используете Java/С# mainstream. Изучите рубин, изучите groovy, изучите smalltalk, изучите lisp, изучите различия между ними как в теории, так и на практике.

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

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

Ответ 9

Привет и хороший день для всех

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

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

Это все С не более.... bye bye

Ответ 10

Что-то, что сработало для меня, - Чтение. У меня просто был момент с этой книгой... David West Object Thinki 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

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

Ответ 11

Что работает для меня:

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

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

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

Ура!

Ответ 12

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

Регулярное чтение книг/статей, таких как Эрик Эван Model Driven Design или изучение новых языков (Smalltalk, Self, Scala) которые используют различный подход к OO, помогут вам понять.

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

Ответ 13

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

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

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

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

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

Помог, конечно, что я узнал OO с Smalltalk (каждый должен быть вынужден, чтобы сделать это IMHO). Язык всегда поощрял концепцию "отправки сообщений". То есть, не вставляйте сюда материал, пишите новый метод и вызываете его (т.е. Отправляете сообщение и получаете ответ **) результат? Простота, низкое сцепление, высокая степень сцепления.

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

Ответ 17

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

Ответ 18

Для лучшего программиста OO требуется лучший программист.

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

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

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

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

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

Ответ 19

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

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

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

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

interface i { getObject($o); }

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

Абстракция второго шага - это управление вашей системой.

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

// o must be a digit
// o must be between 0 and 120
// ... etc
}
}
  • С точки зрения веб-страницы это проверка требований, таких как User logged in, подключенная база данных и т.д.
  • В терминах MVC это Контроллер.
  • В терминах Tree это родительский элемент.

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

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

}

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

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

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

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

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