Разное

Не получает проектировать системы где используется концепция ООП. Может что почитать посоветуете. Нифига не могу думать объектами, пишу херню, понимаю что и половины возможностей не использую которые дает ООП. Интересует тема проектирование приложений с возможность расширения . Желательно чтобы не было упора в конкретный язык программирования. Хочу НАУЧИТЬСЯ мыслить более абстрактно в маштабе интерфейса а не реализации. Кто чем поможет.

Просто надо думать более абстрактно и иметь развитое воображение

где этому можно научится? побыстрей желательно)
сенсея нету рядом)

Вот например наш материальный(предметный) мир состоит из самых разнообразных объектов(предметов). Вот например есть наше Солнце к какому классу объектов его можно отнести? - Звезда. Т.е. есть класс Звезда, его конкретный экземпляр(объект) - это наше Солнце. Тут сложного ничего нет просто ты никогда не задумывался над этим и всё. Что такое свойство объяснять не стоит, там цвет цвет, размер и т.д., методы это действия которые можно совершить над объектом, либо какие может совершить он(в случае со звездой можго назвать например образование и взрыв ну и т.д.) т.е. понятно в мире мало вещей которые вообще не поддаются восприятию, а если таковые и есть, то на то промысел Божий. Если непонятно что-то можно скачать из интернета книжку по логике(предмет такой даже в гуманитарных учебных заведениях преподают).

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

Приведи пример того что тебе не понятно и назови язык на примере которого ты изучаешь ООП?

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

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

Преимущества объектного подхода - это наследование, полиморфизм, интерфейсы и тому подобное. Вот откуда надо плясать.

можно еще инкапсуляцию добавить

ей делать то особо и нечего. Вообщем это просто слова за которыми спрятаны определённые приёмы программирования. А плясать начинать надо с определения понятий класс, объект, свойство и метод

а она разве не является преимуществом?

нет

почему?

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

>Всю жизнь считал интерфейсы заплатками, а не преимуществами никакими. ))

И на чём Ваши выводы основываются? На php-интерфейсах?
Есть и другие языки, где у интрефейсов есть достойное применение.

Ну тут не другие вообще то языки обычно обсуждаются.
А в php - заплатка и есть.

>Ну тут не другие вообще то языки обычно обсуждаются.

Ну мы вообще то не в "PHP", а в "Разном" :)

>Ну тут не другие вообще то языки обычно обсуждаются.
>А в php - заплатка и есть.

Почему заплатка?
Разве не удобный инструмент?

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

Вы пишите интерфейсы всех объектов, и раздаёте на их основе задания:
кто-то пишет объекты, кто-то их взаимодействие - работа кипит как только вы закончили с интерфейсами.

Без них бы всё буксовало, бы пытаясь сдвинуться в неопределённом направлении.
Разве не так?

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

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

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

>Толку от него в готовом к бою коде нет. А знать это заплатка, которой прикрыто отсутствие множественного наследования.

думаете у них возникли проблемы с реализацией множественного наследования в языке?

вот например

Как известно, язык Java не поддерживает множественное наследование реализаций (классов). Это объясняется тем, что такое наследование порождает некоторые проблемы. Чаще всего указываются неоднозначности, возникающие при так называемом «ромбовидном» наследовании, когда один класс “A” является наследником двух других классов “B” и ”C”, причем и тот и другой наследуют класс “D”.


http://www.javaportal.ru/java/articles/mnj.html

Николай2357 привильно понял, что явление интерфейса в php особого толку не приносит, вот только из-за отсутствия общих знаний об интерфейсах и общие выводы он делает неправильные. C# и Java тоже не имеют множественного наследвания, отчего интерфейсы в них заплатками не становятся.

кстати вот еще про ООП на php. по сути, мне кажется то, что его называют убогим по сравнению с другими языками, это уже скорее стереотип начиная еще с php4. если вспомнить тот же C++, в отличии от php там есть это самое множественно наследование, виртуальный функции, конструктор копирования...и вроде бы всё из того что я могу припомнить...все остальное по-моему в php присутствует.

А чем вас обычная область видимости объектов не устраивает? Разве обязательно обращаться по ссылке и вообще использовать полностью объектную модель? Если работать с классами через двойное двоеточие - область видимости заключается лишь в своевременном включении этих классов. И больше на это не заморачиваться.

М. Зандстра "PHP объекты, шаблоны и методики программирования" 2 издание

М. Зандстра "PHP объекты, шаблоны и методики программирования" - дома лежит. Прочитал половину. начал читать про шаблоны вроде все ясно но не понимаю как реализовать некоторые .
Не понимаю UML. Вникаю в код.Чуствую что нехватает чего для более ясного понимания.

про uml можно Г.Буча почитать

Прикрепила файл - там несколько статей по UML, самое основное, я читала их, когда в свое время сама разбиралась. Возьмите, может, вам поможет.

спасибо за материал

>нехватает чего для более ясного понимания

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

Все эти навороты с инкапсуляцией - только для предотвращения конфликтов имён (ну и немного разделение пространства имён).
наследование и полиморфизм это только некая реализация передачи данных/функций из обьекта в объект.
интерфейсы похожи на макросы для работы с этим типом данных , объекты.
Всё это вместе организовано местами кустарно, и не настолько больше гибкости насколько нужно лишних букв скармливаемых парсеру.
(На мой взгляд, как тоже очень не понявшего это ООП)

ООП конечно удобно, но редко всё сделано так что-бы всё устраивало в этих готовых запечатанных консервных банках. А разбираться там никакого удовольствия.
Но может я изменил-бы своё мнение, если-бы почаще разбирался-бы во всех таких классах до полного просветления, и прозрения :) ато заглядываю в эти классы, и вижу только горы лишних длинных слов, а у меня ненасторено макросов для того чтобы вставлять их такими пачками :)

Лучший способ научиться правильно проектировать классы - писать их. Кэп, да? :)

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

Чем больше классов вы напишите, тем лучше будете понимать, как их писать.

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

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

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

мне кажется это один из самых хороших и дельных советов. спасибо.
Буквально вчера понял что стадию "говнокод" не миновать. ))
Вообщем чтобы научится нужно учится) Just do it )