Последние несколько месяцев я изучал ООП в сочетании с реализацией Zend MVC. В общем, я довольно новичок в программировании, но я твердо убежден, что я должен учить вещи «правильным» способом, что для меня означает убедиться, что я понимаю, почему все сделано так, как есть. Т.е. я обнаружил, что при обучении тому, как что-то делать (что-нибудь, скажем, музыке), лучший способ научиться делать что-то - это знать, почему это делается в первую очередь.
В любом случае, я изо всех сил пытался понять, как разрабатывать свои собственные бизнес-модели (например, M из MVC), и я решил, что это не потому, что я не понимаю ООП в целом, потому что я изучал его несколько раз. месяцев, и я не думаю, что концепции очень трудно понять. Я нахожу примеры, которые я изучил, на самом деле очень интуитивно понятными. Проблема для меня, я думаю, заключается в процессе перевода моих собственных проблем в объектно-ориентированные решения. Примеры в книгах (которые я читал до сих пор) слишком очевидны, поэтому процесс перевода проблемы в объекты не очень сложен. То, что я думаю, я мог бы упустить - это абстрагированный процесс высокого уровня. Какой-то список шагов или вопросов, на которые каждое объектно-ориентированное решение должно отвечать на самом высоком уровне.
Если бы вам пришлось описывать такой процесс не более чем за пять шагов, что бы они были и почему? Каков наиболее эффективный процесс перевода любой проблемы в объектно-ориентированное решение?
источник
Ответы:
Найти подходящую модель не всегда просто. Это одна из тех вещей, которые требуют большего опыта, чем простые знания. Однако следующий простой рецепт может помочь вам преодолеть начальный ментальный блок.
Это было первоначально описано в этой статье Эбботтом и часто упоминается как «текстовый анализ Эбботта».
Пример:
Существительные , глаголы и
adjectivesпомечены.Первая итерация анализа даст:
Классы:
С этого момента вы можете подумать, какому классу нужны какие атрибуты и методы для реализации поведения, а затем все больше и больше совершенствовать эту модель.
источник
На мой взгляд, подход TDD является естественным и эффективным:
Благодаря этому процессу вы можете постепенно создавать тестируемый код со звуковым оформлением. Сначала вы можете подумать, что тест написания не нужен, но на самом деле это помогает вам построить архитектуру звука.
источник
Вот шаги, которые я использую в коде C ++:
Причина (1) состоит в том, что он определяет область действия функциональных возможностей класса. Причина (2) состоит в том, что он определяет, как класс общается с внешним миром. Причина (3) состоит в том, что он определяет, как выбрать, какая функциональность класса необходима в каждой ситуации. Причина (4) в том, что он позволяет использовать класс во многих различных ситуациях. Причина (5) заключается в том, что он определяет границу между дизайном и реализацией.
источник