Писал(и пишу) на процедурном программировании. Начал знакомится с ОО парадигмой программирования/проектирования. Тут откуда не возьмись и появился проект, который писать будут 2 человека и в будущем функционал будет расширятся ! Было принято решение писать на ООП, потому что: Я считаю проще будет распределить обязанности за написания отдельных участков кода. Также проще будет объединить наши участки кода. Проще будет расширить возможности, т.е. более гибкая к изменениям система(При условии что "правильно" с проектируется система, вот в чем собственно и загвоздка). Только в этом я пока что вижу преимущество ООП перед процедурным. Практики с использованием ООП нет. (Базовые понятия с книжек как бы ферштейн, проблем с синтаксисом в пхп нет) Наибольший дискомфорт в ООП почувствовал, когда дело дошло до проектировании системы. Вроде все определилось логика, сделаны хтмл макеты, спроектирована БД, даже uml диаграму перцедентов нарисовал. Но ни как не могу спроектировать классы, даже не знаю как правильно это делается.(По этому и решил задать вопрос) Хочу сделать согласно шаблону проектирования MVC. Теорическое прредставления про этот патерн имееться, но на практике все гораздо сложней. Хотелось бы услышать мысли тех кто использует ООП, какие преимущества Вы видите в ООП ? С чего начинали ? Посоветуйте. нужен совет как капля воды
Горбунов Олег Спасибо конечно за ссылку. Хорошо поставлю свой вопрос иначе: Как "правильно" спроектировать систему ? (с чего начать) т.е. я не хочу сделать свалку объектов и скудные взаимосвязи с ними(пусть даже я абстрагирую данные + будет присутствовать инкапсуляция), нужно спроектировать гибкую к изменениям систему, чтобы соединения подсистем были понятными и лёгкими в сопровождении. Это я к чему, т.е. интересует мнения профессионалов как начинали ? на какие подводные камни предстоит наткнутся ? Как направиться в нужное русло ?
1. Напиши обработчик событий 2. Выдели обработчик внешних данных в отдельный класс 3. Особое внимание удели decoupling 4. Забудь про UML и унифицированную методологию разработки и почитай про extreem programming. 5. Почитай про refactoring 6. Забудь про использование глобальных и суперглобальных переменных внутри классов, это делает систему менее прозрачной. 7. Отделяй бизнес логику приложения от UI. 8. Всегда используй default constructors, сделай все поля классов private и используй setters & getters 9. Напиши класс для конструирования всех actions и внутренних ссылок в зависимости от внешних данных.
Amian Очень интересует сабж по пункту 1,2,9 ? (примерами, если можно) Все остальные пункты были приняты во внимания и поняты, за что большое спасибо !!
Экстремальное программирование рождает проекты, которым нужна экстремальная техподдержка... Я могу лишь посоветовать изучить возможности ООП, которые предоставляет PHP 5.3 (самая свежая версия языка). Имхо, нормальный синглтон нельзя написать даже в 5.2, приходится извращаться
Я работаю над коммерчискими проектами под NDA, так что конкретных примеров кода не будет 1. В моём случае модулярная система так что для каждого модуля свой обработчик. Он представляет из себя класс "Manager" с 1м методом для каждого отдельного события. Когда какой метод тригерится и какого модуля зависит от внешних данных. Параметрами методов служат все необходимые внешние данные для осуществления операции. Внутри методов создаются все необходимые объекты, некоторые из которых затем сеттерами загоняются в те классы, которые в них нуждаются - для decoupling, хоть интерфейсов не использую, но "держу в уме".Тоесть, внутри классов типа MODEL НИКОГДА не создаются объекты, а загоняются внутрь сеттерами. 2. Обработчик внешних данных представляет из себя 2 класса - UniversalController и его Helper. Helper с 3-мя сеттерами на перевод объекта, value и произвольное значение integer. UniversalController - сеттер на редирект в случае возниктовения ошибки и на перевод. В универсал контроллере есть куча методов на проверку соответствия внешних данных, полностью удовлетворяющих нуждам. Параметром всех методов служит массив объектов класса Helper. Можно производить сразу несколько проверок для одних и тех же данных - все несоответствия в конечном счёте суммируются, загоняются в $_SESSION['statusReport'] и редиректится по указанному адрессу где они выводятся в статус баре. 9. Чтобы сделать модули системы более гибкими и не привязанными к конкретному ядру никогда не надо использовать внутренние ссылки и actions в явно заданном виде + что же делать если есть желание включать/отключать в инсталле Mod Rewrite или быстро менять его separator? Для этого и нужен класс по созданию подобных ссылок. Загоняешь сеттерами hashMap исходных данных, статус для Mod Rewrite и rewrite separator и он тебе генерирует ссулку.
Чьорт, а по русски? Ты прости, может ты и хороший специалист, но твое «объяснение» похоже на бред кокаинового наркомана.
Эх. Товарищи, Спасибо! Все же, испытал мини шок от количества возможных вариантов, примирении на практике ООПроектирование, и решил возвратится к привычным не объектно-ориентированным методикам. Да, возможно это шаг назад, но нужно время что бы "переварить" и приспособиться к ООП. Был бы очень рад за предложеную литературу по ООП (только ту что вы считаете действительною достойную внимания), с удовольствием почитаю на досуге Еще раз благодарен Вам!
Следуйщий проект (приблизительно через месяц) все еще раз попытаюсь спрокетировать и реализовать на ООП. (хотелось бы и самому верить, но как то даже сам не могу себя убедить эх)