Где я могу найти примеры процессуального кодекса преобразованными в объектный код
При использовании Eclipse PDT это сделано путем открытия представления проводника PHP, то нажатие на перевернутый треугольник в верхнем правом из того окна. Окно контекста появляется, и опция фильтров доступна там. Нажатие на пункт меню Filters открывает новое окно, где.* файлы могут быть неконтролируемы, таким образом позволив редактирование .htaccess файлов.
я искал навсегда это, таким образом, я - вид ответа на мой собственный вопрос здесь. Я уверен, что у кого-то еще будет та же проблема также, таким образом, я буду надеяться, что это помогает кому-то еще также.
4 ответа
Реальность такова, что такие преобразования обычно не будут хорошим объектно-ориентированным кодом. Почему? Поскольку объектно-ориентированный код не просто перемещает функции в методы и данные в члены.
Вместо этого хороший объект должен нести ответственность за все свои данные и принимать только параметры метода, где эти параметры определяют данные, с которыми будут работать .
Это означает, что не существует 1: 1 сопоставления процедурных функций и процедурных структур данных с объектно-ориентированными.
Осмотревшись, я не нашел ни одного интересного мне примера в сети, поэтому я просто приведу свои правила рефакторинга для преобразования процедурного кода в ООП.
Первый шаг - просто упаковать каждый модуль как объект . Другими словами, просто создайте объект, содержащий данные и функции. Это ужасно для пуриста, но с чего-то нужно начинать. Например, если у вас был модуль BankAccount, теперь у вас будет объект BankAccount.
Очевидно, что в функции передавались данные из внешних вызовов. Здесь вы ищете, как усвоить эти данные и сделать их максимально конфиденциальными. Цель должна состоять в том, чтобы вы получили свои данные в своем конструкторе (по крайней мере, в начальной точке) и удалили параметры, которые использовались для получения данных вручную, и заменили их ссылками на эти теперь личные данные. Используя объект BankAccount, весь доступ к учетной записи теперь осуществляется через методы объекта, а фактические данные учетной записи были интернализованы.
Многие из ваших функций, вероятно, вернули измененные версии структур данных: прекратить возвращать эти данные напрямую и оставить эти изменения в частных структурах. Создайте свойства средства доступа, которые возвращают ваши теперь личные данные, где это необходимо, и пометьте их как «устаревшие» (ваша цель - сделать объект хозяином своих данных и возвращать только результатов , а не внутренние данные). С помощью объекта BankAccount мы больше не возвращаем фактические данные учетной записи, но у нас есть свойства для CurrentBalance и такие методы, как AverageBalance (int days) для просмотра учетной записи.
В конечном итоге вы получите набор автономных объектов, которые все еще несут мало похоже на то, что вы сделали бы, если бы начали с объектов в своем дизайне, но, по крайней мере, вы можете продолжить рефакторинг с новыми объектами. Мой следующий шаг обычно заключается в том, чтобы обнаружить, что объекты, созданные в результате такого рефакторинга, имеют множество функций. На этом этапе, вероятно, были обнаружены некоторые общие потоки, и вам следует создать объекты, чтобы преобразовать эти общие идеи. Если у нас есть BankAccount, у нас, вероятно, есть другие типы учетных записей, и если мы согласовываем методы всех этих типов учетных записей, мы можем сделать Account как базовый класс, который реализует все общие функции, в то время как BackAccount, SavingsAccount и другие реализуют детали.
Как только структура классов начинает формироваться, пора лучше подумать о преобразовании. Рефакторинг - это процесс, а не конечная точка, поэтому я обычно считаю, что структура моего класса продолжает развиваться. Одна из приятных особенностей того, что вы зашли так далеко, - это то, что ваши данные являются конфиденциальными и ими можно управлять с помощью методов, так что вы можете все более и более свободно реорганизовывать внутренние компоненты по мере вашего продвижения.
Одна вещь, которая делает это правдоподобным, - это наличие хороших модульных тестов. При выполнении процедурных преобразований в ООП я часто использую старый код в качестве «базового», чтобы проверить его. То есть тест может сверяться с результатами старой процедурной системы. Если вы не совпадаете, неплохо выяснить, почему. Я обнаружил, что часто возникает ошибка ... но иногда ваш новый код очистки на самом деле делает что-то правильное, что было неправильно в прошлом.
Что касается создания "слишком глубоких" деревьев объектов: это может быть результатом слишком одержимы наследством. Я считаю, что композиты часто бывают лучше, где вы реализовали интерфейсы для нескольких объектов, а не пытались получить все эти функции в одном родительском объекте. Если вы обнаруживаете, что создаете родительские объекты, которые просто представляют собой смесь наборов функций, подумайте об упрощении, создав интерфейс для каждого набора функций и реализовав эти интерфейсы.
Проблема, с которой процедурные программисты часто сталкиваются при запуске объектно-ориентированного программирования, заключается в том, что они продолжают проектировать процедуры и пытаются организовать их как объекты . Это не работает.
Объектно-ориентированное программирование - это другая методология проектирования ; другой способ мышления о ролях и обязанностях , которые вы распределяете по всему коду, а не просто другую методологию кодирования.
Когда вы отказываетесь от метафор «собака - это млекопитающее» (которые никогда не переводятся на реальных приложений), я бы порекомендовал эту книгу: Дизайн объектов: роли, обязанности и взаимодействие . Это была первая книга, которую я прочитал, где я , наконец, понял, почему мне пришлось перестать рассматривать (в моем случае) C ++ как "
One very intuitive transition from a C API to a C++ API happens a lot in databases; so for this example, we'll take a quick look at the difference in using the MySQL APIs.
I'm not sure if I can copy the code from these sites (no idea what license it is), but look at the section labeled "Creating a Database" for a C demonstration, and Sample #1 for a C++ demonstration; both of these step through creating a MySQL database programmatically.
In the C API, the first argument to every function is a "handle" to the database. In the C++ API, we work with a database connection object which implicitly calls the C API with its private handle.
To look at one very specific example, to execute the query once it's been generated we have in C:
mysql_query(conn, "create database testdb")
and in C++:
query.execute();
The big difference here is that the C++ binding only shows you as much as you need to see, while in C you have to be very explicit about every little detail.
I think the database APIs are a good way to pick up some OOP principles by example, so hopefully they can help you out too.
Я знаю, что это помечено .net, но хороший пример - PHP. До PHP5 PHP был лишь частично объектно-ориентированным. Многие разработчики PHP сталкивались с той же проблемой понимания ООП.
У Zend есть довольно хорошая статья здесь . Это должно быть довольно легко усвоить.
Если вы чувствуете, что вам нужно лучшее направление в процессе объектно-ориентированного проектирования, вы можете проверить MIT Open CourseWare, в частности Основы разработки программного обеспечения (Лекционные заметки # 2) или что-то подобное.