Обучение объектно-ориентированного мышления

Ответ 1

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

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

Вот некоторые из его сильных сторон:

• В Часть A: Проблемы, очень хорошее определение качества программного обеспечения.
• В Часть B: Дорога к ориентации объектов, логичный шаг за шагом поиск методов OO таким образом, чтобы читатель считал, что исследование проводится вживую, то есть, как будто все еще не было известных результатов. Вероятно, вы приобретете мышление, которое вы ищете из этой части.
• В Часть C: Объектно-ориентированные методы, техническое ядро ​​книги, вы сделаете свои знания обоснованными и научитесь очень полезным методам проектирования по контракту, наследованию, универсальности и т.д.
• Часть D: методология OO: применение метода хорошо - более практичный подход к дизайну, который также я считаю очень полезным. См. Например Как найти классы (22), которые вы можете найти онлайн.

После этих частей появляются более сложные темы, такие как Concurrency (30) или Базы данных (31).

Поскольку книга использует Eiffel язык (разработанный автором), это поставит вас в правильное мышление и научит вас думать. Эти идеи будут легко применять к другим, более или менее ОО, языкам программирования.

Ответ 2

Объектно-ориентированное

Объектно-ориентированное программирование - это просить объекты что-то сделать: обманчиво сложное понятие, чтобы правильно применить.

Goban

Рассмотрим двумерную игровую панель, например, для воспроизведения Go (называемого гобаном).

Сначала подумайте о поведении, которое требуется для выполнения своей задачи. Это означает перечисление поведения для объекта, а не определение данных, которые манипулируют поведением. Например, базовая плата может иметь следующие типы поведения:

• Поместите камень Года.
• Удалите камень Go.
• Удалите все камни.

Для компьютерной версии Go удобно привлекать внимание к конкретным областям:

• Отметьте пересечение (например, треугольник, число, буква, круг, квадрат).
• Удалите отметку с отмеченного пересечения.
• Удалите все метки.

Обратите внимание, что гобан не должен предоставлять способ предоставления клиентам ссылки на камень на конкретном пересечении. Вместо этого он может отвечать на вопросы о своем состоянии. Например, гобан может ответить на следующие вопросы:

• Есть ли черный камень на данном пересечении?
• Есть ли белый камень на данном пересечении?
• Есть ли отметка на данном пересечении?

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

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

public interface Goban {
  public void place( Stone stone, Point point );

  public void removeStone( Point point );
  public void removeStones();

  public void place( Mark mark, Point point );

  public void removeMark( Point point );
  public void removeMarks();

  public boolean hasWhiteStone( Point point );
  public boolean hasBlackStone( Point point );
  public boolean hasMark( Point point );
}

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

Инкапсуляция

Реализация интерфейса Goban не предоставляет свои внутренние данные. На этом этапе я мог бы попросить вас реализовать этот интерфейс, написать модульные тесты и отправить мне скомпилированный класс, когда вы закончите.

Мне не нужно знать, какие структуры данных вы использовали. Я могу использовать вашу реализацию, чтобы играть (и изображать) Гобан. Это важный момент, когда многие проекты ошибаются. Многие, многие проекты кодируют следующее:

public class Person {
  private HairColour hairColour = new HairColour( Colour.BROWN );

  public Person() {
  }

  public HairColour getHairColour() {
    return hairColour;
  }

  public void setHairColour( HairColour hairColour ) {
    this.hairColour = hairColour;
  }
}

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

public class HairTrickster {
  public static void main( String args[] ) {
    Person bob = new Person();
    HairColour hc = bob.getHairColour();
    hc.dye( Colour.PINK );
  }
}

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

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

public class Person {
  private HairColour hairColour = new HairColour( Colour.BROWN );

  public Person() {
  }

  public HairColour getHairColour() {
    return hairColour.clone();
  }

  public void setHairColour( HairColour hairColour ) {
    if( !hairColour.equals( Colour.PINK ) {
      this.hairColour = hairColour;
    }
  }
}

Боб может спокойно спать, зная, что он не проснется к розовой работе с краской.

Ответ 3

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

Ответ 4

Начальный объектно-ориентированный анализ и дизайн

Мне нравятся книги "Первая книга", потому что им интересно читать. У них есть упражнения и головоломки, чтобы поцарапать вам голову. Я прочитал эту книгу и нашел ее очень хорошим.

Книга охватывает:

• Использовать принципы OO (инкапсуляция и делегирование)
• Принцип открытого закрывания (OCP)
• Принцип единой ответственности (SRP)
• шаблоны проектирования, UML, примеры использования и т.д.

Ответ 5

В моей голове есть блокада, которая запрещает мне видеть, где я должен использовать класс, и где я не должен.

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

В настоящее время калибратором является целое число в классе Plot.

Должен ли класс быть классом? Каково было бы преимущество превращения его в класс? Это те вещи, которые вам всегда нужно задавать себе.

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

Ответ 6

Там в эссе в книге " ThoughtWorks Anthology" Jeff Bay: "Object Calisthenics", в которой он дает набор правил для проектирование программного обеспечения ООП:

• Используйте только один уровень отступов для каждого метода.
• Не используйте ключевое слово else
• Оберните все примитивы и строки
• Используйте только одну точку на строку
• Не сокращать
• Сохранить все сущности маленькими
• Не используйте классы с более чем двумя переменными экземпляра
• Использовать коллекции первого класса
• Не используйте геттеры/сеттеры/свойства

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

Ответ 7

Просто помните, что никогда не было решения проблемы. Превращение всего в класс также не является решением. Особенно крошечные вещи (например, манометр) вполне могут быть членами int или float внутри класса сюжетов, как и у вас.

Мое предложение состоит в том, что практика - хороший учитель. Просто продолжайте пробовать и продолжайте читать. Со временем вы будете все более и более свободно говорить.

Ответ 8

Я, наверное, больше всего узнал о разработке объектно-ориентированного программного обеспечения от Craig Larman's Применение UML и шаблонов: введение в объектно-ориентированный анализ и дизайн и итерационное развитие.

В своем подходе классы производятся систематически из вариантов использования:

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

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

Ответ 9

Для меня OO не 'click', пока я не прочитал книгу о шаблонах дизайна. Если вам уже нравятся такие понятия, как абстрактные классы, интерфейсы и т.д., То только половина битвы.

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

Я не могу рекомендовать какие-либо конкретные книги о С++, но GOF book является стандартом в Design Patterns (Java). Я предпочитаю книги, которые рассказывают о шаблонах проектирования на определенном языке, чтобы вы могли получить конкретные примеры кода. Шаблоны проектирования в Ruby довольно хороши, а PHP: объекты, Шаблоны и практика.

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

Теперь создайте список всех существительных для хорошей идеи о том, какие классы (= вид объектов) вовлечены в вашу проблему:

• Места для кемпинга
• Гость
• Выход
• Питание

Это не обязательно окончательный список, но это хороший старт.

Ответ 13

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

Например:

а. В ситуациях, когда существует много конструкций if/else, возможно, вы можете думать о наличии иерархии классов для распределения кодов ветвей соответственно, и использовать полиморфизм.

б. Любое использование таких операторов, как (instanceof в Java), указывает на конкретные типы, и вы можете подумать, как избавиться от проверки экземпляра.

с. Используйте "Закон Деметры" в качестве ориентира и посмотрите, существует ли связь между классы высоки

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

Ответ 14

Ха-ха. Я помню этот момент. Целый "как, черт возьми, эта вещь работает?". Просто держись за это, в какой-то момент он просто нажимает. Это действительно похоже на лампочку. В один момент это не имеет смысла, а затем через секунду вы кодируете все в классах.

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

Ответ 15

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

Ответ 16

На мой взгляд, одной из лучших книг, которые я прочитал для изучения объектно-ориентированных концепций, является:

Объектно-ориентированный процесс мышления

Для меня эта книга действительно заставляет вас думать объектно-ориентированным способом (ну, ключ в названии!) Это довольно языковой агностик, содержащий некоторые небольшие примеры кода во всем тексте в VB.NET, С# и Java и часто ссылается на многих "великих" в мире анализа и проектирования ОО, таких как Grady Booch, Martin Fowler и другие.

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