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

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

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

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

• Camping Site
• Гость
• Выход
• Питание

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

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

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

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

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

Процесс объектно-ориентированного мышления

Для меня эта книга действительно дает вы мыслите объектно-ориентированным способом (ну, подсказка в названии! :) Это довольно языковой фактор, содержащий несколько небольших примеров кода по всему тексту на VB.NET, C # и Java и часто ссылающийся на многих "великих" в мире ОО-анализ и дизайн, такие как Грэди Буч , Мартин Фаулер и другие.

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

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

Например:

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

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

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

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

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

Для меня объектно-ориентированный подход не «щелкал», пока я не прочитал книгу о шаблонах проектирования. Если вы уже знакомы с такими понятиями, как абстрактные классы, интерфейсы и т. Д., Это только полдела.

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

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

У меня такое ощущение, что ваш инструктор не особо разбирается в том, о чем говорит. Совет «Больше уроков» сам по себе бесполезен.

У меня такое ощущение, что ваш инструктор не особо разбирается в том, о чем говорит. Совет «Больше уроков» сам по себе бесполезен.

У меня такое ощущение, что ваш инструктор не особо разбирается в том, о чем говорит. Совет «Больше уроков» сам по себе бесполезен.

В книге « Антология ThoughtWorks » Джеффа Бэя есть эссе «Художественная гимнастика объектов», в котором он дает набор правил для разработки программного обеспечения ООП:

1. Используйте только один уровень отступа для каждого метода
2. Не используйте ключевое слово else
3. Оберните все примитивы и строки
4. Используйте только одну точку в строке
5. Не сокращайте
6. Сохраняйте все объекты маленькими
7. Не используйте никакие классы с более чем двумя переменными экземпляра
8. Используйте первоклассные коллекции
9. Не используйте никакие геттеры / сеттеры / свойства

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

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

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

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

Head First Object -Oriented Analysis and Design

Я люблю книги Head First, потому что их интересно читать. У них есть упражнения и головоломки, чтобы почесать голову. Я прочитал эту книгу, и она мне понравилась.

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

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

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

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

Прямо сейчас датчик был целым числом в классе Plot.

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

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

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

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

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

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

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

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

Goban

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

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

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

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

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

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

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

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

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

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 теперь затрудняет изменение цвета волос на розовый.

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;
    }
  }
}

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

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

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

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

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;
    }
  }
}

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

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

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

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

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;
    }
  }
}

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

http://books.google.co.in/books?id=0f9oLxovqIMC&pg=PA352&lpg=PA352&dq=How+do+you+handle+%E2%80%9Cspecial-case%E2% 80% 9D + данные + при + моделировании + + база данных% 3F & source = bl & ots = KxN9eRgO9q & sig = NqWPvxceNJPoyZzVS4AUtE-FF5c & hl = en & ei = V3RlSpDtI4bVkAWkzbHNDg = 114 & sa; и Эд Юрдон написал об этом книгу пару лет назад. Хотя эта книга и не наполнена новыми чрезмерно раздумываемыми методологиями, она дает хорошую основу для мышления объектным стилем.