и опять MVC... « PHP и ООП

Trej Gun

Сообщения: 5305 Репутация: N Группа: в ухо

4 августа 2008 г. 14:59, спустя 3 минуты 34 секунды

killich, посмотри еще не питон, тоже очень перспективно, и много хороших идей)))

adw0rd

Сообщения: 22959 Репутация: N Группа: в ухо

4 августа 2008 г. 15:06, спустя 7 минут 40 секунд

Да… согласен, нифига не удобно

удобно пока не появляються join, if-then и прочая лабуда
ну вобщем дело вкуса и привычки

Я и имел ввиду это :/

https://smappi.org/ - платформа по созданию API на все случаи жизни

killich

Сообщения: 270 Репутация: N Группа: Адекваты

4 августа 2008 г. 15:15, спустя 8 минут 16 секунд

фсе. флуд прекращаю :)

Рубист с большой буквы Г. Серый кардинал кулинарного блога open-cook.ru

Trej Gun

Сообщения: 5305 Репутация: N Группа: в ухо

4 августа 2008 г. 15:44, спустя 29 минут 16 секунд

killich, я не вижу ответа на мой конкретный ответ про абстрактный класс ж)

killich

Сообщения: 270 Репутация: N Группа: Адекваты

5 августа 2008 г. 9:17, спустя 17 часов 33 минуты 2 секунды

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

Среди моих знакомых есть даже кодеры имеющие чуть ли не филологическое! образование. Бывает разное, но меня все же смущает данный факт. Я вот не берусь же писать критику на поэмы. не мое это дело. И полне естественно, что уровень их представлений об ООП несколько иной чем у меня. НО ИМ ОЧЕНЬ НРАВЯТСЯ стрелочки и точки ОО Программирования. По всей видимости для таких людей эти атрибуты ОО Программирования и само ОО Программирование - есть одно и тоже. Ан нет.

Мое представление о ОО Программировании следующее (это лишь мое виденье, я не прошу с ним соглашаться, а лишь принять во внимание…. возможно, Вы найдете в нем долю правды и для себя):

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

Среди этих принципов есть вполне понятные и родные для программистов - классификация, абстракция, переработка (рефакторинг) и прочее.

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

Абстрактные функции существуют далеко не затем, что бы Вы при написании программы - не забыли эти функции реализовать! Просто потому - что если вы вдруг забыли их реализовать и программа работает - то значит эти функции вам просто не нужны >:0) А.Ф. - это реализация в программировании процесса создания ЭСКИЗА классовой иерархии. Поэтому то, я когда вижу абстракты сразу спрашиваю - вы их создаете что бы обеспечить качество своего приложения с точки зрения ОО Проектирования или как средства "не забыть бы реализовать". Если во втором случае, то, на мой взгляд, повторю еще раз - ___на мой взгляд___ - это не вполне верное использование инструментов ОО Программирования. Не разу не сталкивался с ситуацией, что бы человек ЗАБЫЛ реализовать нужную ему функцию. Если это так случится, то вы просто не получите требуемый результат. вот и все.

Рубист с большой буквы Г. Серый кардинал кулинарного блога open-cook.ru

Trej Gun

Сообщения: 5305 Репутация: N Группа: в ухо

5 августа 2008 г. 10:47, спустя 1 час 29 минут 53 секунды

очень напоминает анекдот

- папа а с кем это ты сейчас говорил?!

я тебе про то что абстрактные классы могут служить для вынесения функционала чтобы не плодить копипаст? а ты мне пто то что я забываю чтото реализовать

это интерфейс служит для того чтобы не забыть чтото реализовать при написании другого драйвера (например) и да действительно этот функционал может и не использоваться но для совместимости он должен быть

а вот то что ты пытался расказывать про животных

обезьян, лошадей, людей, программистов

как они деляться на то ктоо чем питаеться, так ожет тебе почитать чтото толковое про namespace

ЗЫ у меня за плечами незаконченый химфак и институт связи, про поэмы тебе тоже ничего не расскажу

adw0rd

Сообщения: 22959 Репутация: N Группа: в ухо

5 августа 2008 г. 11:33, спустя 46 минут 17 секунд

Делимся откровениями? У меня незаконченный Торгово-Экономический Университет, по профессии Эксперт качества :)

https://smappi.org/ - платформа по созданию API на все случаи жизни

sap

Сообщения: 2701 Репутация: N Группа: Кто попало

5 августа 2008 г. 11:44, спустя 11 минут 18 секунд

А у меня диплом младшего специалиста по специальности «Программирование» :)

я тебе про то что абстрактные классы могут служить для вынесения функционала чтобы не плодить копипаст? а ты мне пто то что я забываю чтото реализовать

В первую очередь для вынесения функционала, как по мне.

killich

Сообщения: 270 Репутация: N Группа: Адекваты

5 августа 2008 г. 12:00, спустя 15 минут 48 секунд

- папа а с кем это ты сейчас говорил?!

… и тут Остапа понесло….. (эт я про себя)
Прошу прощения просто "прелести" изучения ООП на физ мат факультете дают о себе знать, ибо физики сами по себе люди слегка чокнутые, а когда они начинают разрабатывать физические модели с ООП тут дело доходит до невероятной степени углубления в теоретические основы. Просто 3 года изучения ооп с такими преподами как у нас (я в хорошем тоне о них щас говорю) не могли не повлиять и без того мое больное сознание (хуже на меня повлияла только квантовая механика :D).
Мавр, респект разработчикам и Вам в том числе. Так или иначе главное - результат, а это большое кол-во труда. Средства выбирает каждый на свой вкус. Не мне учить разработчиков и не мне давать советы. Просто мозг мой воспален ООП до такой степени, что первое что приходит в голову при встречи классов и прочего - зачем оно тут? что классифицируют? и т.д. и т.п. …. потому я и не программист, что задаю слишком много ненужных порою вопросов - не обращайте внимания. я скорее исследователь. мне интересно - я копаюсь. Если говорить о том, что я бы хотел услышать в ответ о наличии абстрактов и классов, то это наверное что то вроде - я долго думал о том какие объекты есть в моем приложении, определил границы допустимости моей будущей модели, задумался о том, что можно разработать классовую иерархию, в вершине иерархии находится базовый тип Бла Бла, наделенный тем то тем то. вторым уровнем идете то-то потому-то и вот в качестве результата - мы получаем класс Контроллер экземпляры которого мы реализуем. …. и в конце концов получаем ПОЛНОСТЬЮ НЕ РАБОТОСПОСОБНОЕ ПРИЛОЖЕНИЕ, но с оценкой в дневник 5+ и чувством восхищения самим собой от того что соблюли все догмы ОО Проектирования. :) Эт все бред - больше не поддавайтесь на такие провокации с моей стороны >:0)

Много обосновано не только ООП, но и программным обеспечением используемым в разработке. Так если это редактор с подстановкой свойств и методов объекта, то использование оператора -> существенно упрощает работу. Я лично пишу все в блокноте и мой путь в сторону сокращения текста потому да и при написании -> никто и ничего не подставит.
Если я могу писать без классов - я пишу без них. Я не нашел в своих web приложениях те объекты которые требуют классификации. Классифицировать страницы - а зачем? Контроллеры? тот же вопрос…. слишком много я вижу различий в каждой из страниц в действительно большом проекте.
Контроллер у меня - всего лишь набор обработчиков событий. мне вполне комфортно классов, да и скорость нахождения фрагментов для модификации при построении на MVC довольно высокая. Приложение в достаточной степени структурировано самой MVC, классы мне лично там пока не помогают.

PEAR по-моему я как то смотрел или где то в другом месте, не помню. Там вызовы создания форм примерно такие (без наезда на PEAR, просто пример):

$form->begin();
$form->input();
$form->input();
$form->submit();
$form->end();

Там конечно наверняка в классе есть какие то функции работы с формами , не знаю, судить не могу. Мне вот вполне достаточно конструкции:

form_start();
input();
input();
submit();
form_end();

соответственно, при написании кода пару символов и часть времени я выигрываю. И классы мне совсем здесь не нужны.

Рубист с большой буквы Г. Серый кардинал кулинарного блога open-cook.ru

killich

Сообщения: 270 Репутация: N Группа: Адекваты

5 августа 2008 г. 12:11, спустя 10 минут 55 секунд

я тебе про то что абстрактные классы могут служить для вынесения функционала чтобы не плодить копипаст

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

Рубист с большой буквы Г. Серый кардинал кулинарного блога open-cook.ru

sap

Сообщения: 2701 Репутация: N Группа: Кто попало

5 августа 2008 г. 12:35, спустя 24 минуты 9 секунд

PEAR по-моему я как то смотрел или где то в другом месте, не помню. Там вызовы создания форм примерно такие (без наезда на PEAR, просто пример):

$form->begin();
$form->input();
$form->input();
$form->submit();
$form->end();

Там конечно наверняка в классе есть какие то функции работы с формами , не знаю, судить не могу. Мне вот вполне достаточно конструкции:

form_start();
input();
input();
submit();
form_end();

соответственно, при написании кода пару символов и часть времени я выигрываю. И классы мне совсем здесь не нужны.

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

Например, есть класс news для новостей и класс db для работы с базой данных. При грамотной реализации, код добавления новости в БД может выглядеть так:

$db = new db (DB_HOST, DB_USER, DB_PASS, DB_NAME);
$news = new news ();
$news->add ($title, $date, $text);

Разве можно с функциональным подходом написать что-то более удобное?

adw0rd

Сообщения: 22959 Репутация: N Группа: в ухо

5 августа 2008 г. 12:41, спустя 5 минут 44 секунды

PEAR по-моему я как то смотрел или где то в другом месте, не помню. Там вызовы создания форм примерно такие (без наезда на PEAR, просто пример):

$form->begin();
$form->input();
$form->input();
$form->submit();
$form->end();

Там конечно наверняка в классе есть какие то функции работы с формами , не знаю, судить не могу. Мне вот вполне достаточно конструкции:

form_start();
input();
input();
submit();
form_end();

соответственно, при написании кода пару символов и часть времени я выигрываю. И классы мне совсем здесь не нужны.


$form::begin();
$form::input();
$form::input();
$form::submit();
$form::end();

а можно еще и вот так, я понимаю что ты говоришь про класс пира… я так, между прочим…
данный пример про формы говорит только о том что ООП ради ООП

UPD: я не юзал данный класс от пира, все свои знания о нем унаследовал от killich.

но давай разберем другой пример: работа с изображением, делаем аву.
открываем_фото->проверяем_размер->ресайзим->конвертим->добавляем_водный_знак->и_т.д.

в этом случае удобно работать с объектом!

https://smappi.org/ - платформа по созданию API на все случаи жизни

Trej Gun

Сообщения: 5305 Репутация: N Группа: в ухо

5 августа 2008 г. 13:45, спустя 1 час 4 минуты 2 секунды

по профессии Эксперт качества :)

тестер, ёпт!

$form->input(); vs input();

смотри у тебя есть оъбект input у которого ты потом можешь вызывать методы например так

$form->input()->hide();

или

$form->input()->filter("/a-z/");

а твоим способом придеться передавать все эти параметры в функцию а потом еще и отменить их нельзя будет или переназначить если чтото поменяеться в логике

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

я на самом деле работаю с уже готовыми системами где за меня уже все решили НО если бы я решал (как на моем сайте)
1 модульность (все можно заменить, тоесть если чтото заменяем пишем для этого новый адаптор? если заменяем бд то у adodb куча драйверов, если заменяем адодб на пиар то пишем адаптор)
2 фреймворк (везде есть места для подключения новой функциональности, hook на котрый навешаны плагины)
3 пространства имен (все структурировано, классы по папкам, шаблоны по месту использования)
4 иерархия (наследование класса например цепочка пользователей забаненый-гость-пользователь-модер-админ все время расширяет функционал но имплементирует один интерфейс)

кроме всего этого используються всевозможные паттерны чтобы это все работало быстро и легко менялось
например паттерн serviceLocator или registry (они очень похожи) используеться для доступа ко всем классам

но это все только со стороны пхп есть еще сторона БД - от ее архитектуры тоже многое зависит, я например использую вложеные множества со списками смежности

не забываем о СЕО, на хорошое сео тоже уходят ресурсы пхп

$form::input();

этож реальная хрень

killich

Сообщения: 270 Репутация: N Группа: Адекваты

5 августа 2008 г. 14:20, спустя 34 минуты 38 секунд

$db = new db (DB_HOST, DB_USER, DB_PASS, DB_NAME);
$news = new news ();
$news->add ($title, $date, $text);

Если я правильно понял - новость добавляет себя в БД. Возможно, это удобно, но…. первое что меня бы спросили мои наставники:
Вам не кажется что новость это скорее набор данных? Зачем ей знать как добавлять себя в БД? Или отрисовывать себя в X окнах или консольных терминалах. Это должны делать другие объекты. Новости сами не попадают в БД информационных агенств из заносят туда люди. Т.е. другие объекты мира. Они обрабатывают данные, формируют их правильный вид и т.д. Я вижу в этом несоответствие реального и программного мира, что по-моему не есть хорошо.

Рубист с большой буквы Г. Серый кардинал кулинарного блога open-cook.ru

adw0rd

Сообщения: 22959 Репутация: N Группа: в ухо

5 августа 2008 г. 15:04, спустя 44 минуты 31 секунду

$form::input();
этож реальная хрень

блин, забыл убрать $, но не суть, я этим хотел сказать товарисчу "killich", что не обязательно полностью отказываться от ООП, достаточно юзать интерфейс статических методов, если ему так больше нравится.

https://smappi.org/ - платформа по созданию API на все случаи жизни

и опять MVC...

Войти