что угодно. как в любом другом классе.

да. и?

Придет с опытом. Так же, как и понимание паттернов.

Это ты еще не читал про всякие декораторы с обсерверами.

Программирование вообще скучаня штука.

Да я не про то! Не интересно, потому что хочется знать все и сразу! Но так не бывает! Ладно! Спасибо что попытались разъяснить!?

да, тут я видимо ошибся в значениях. Абстрация это не гараж, в аналогии, абстракция - это въезд в гараж! Так?

да чего то сам запутался немножко! Но вроже суть уловил! Спасибо за аналогии

Абстрактные методы НЕОБХОДИМО переопределить иначе компилятор не пропустит

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

Пример:
классы геометрических фигур могут иметь например метод установки цвета и онг может быть вынесен в базовый классю, но метод отрисовывающий фигуру будет у каждой свой
следловательно можно создать базовый абстрактный клас с методом setcolor и абстрактным метоlом draw()

Тогда зачем нам создавать абстрактный метод общий, если мы все равно его переопределяем (по сути пишем заново) в наследниках. Я вот чего не могу понять. Зачем создавать, если придется перезаписать его?[quote]

Ты как чукча - писатель но не читатель
Переопределяются ЧАСТЬ методов а часть остаются с базового класса что бы плодить одиноковый код

Не все а только абстрактные
пойди в педивикию и посмотри чем клас отличается от интерфейса

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

Хотя есть подозрение что тебе надо начать ч того что авообще такое наследование классов

Его не надо объявлять... Его просто наследуют

include 'Cars.php';
class Car extends Cars
{
    protected function wheels()  // переопределяем/реализуем обязательный метод, который в родительском классе является абстрактным
    {
        // куча кода
    }

    private functions properies() // Собственный метод класса Car в котором характеристики хранятся
    {
        return parent :: Speed($x, $y); // Обращаемся к родительскому классу не создавая объект
        // return Cars :: Speeds($x, $y); // Еще один способ как добраться до абстрактного класса
     }
}

Если вне класса ты хочешь обратиться к какому-то методу абстр. класса, то пишешь
Имя_класса :: метод
И не надо создавать никаких объектов...

это статическое обращение при чем тут абстрактный или нет

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

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

многолетний опыт программирования и работы в IT конторах

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

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

MVC (предполагаю речь идет о паттерне а-ля Zend) это отдельная песня и не единственных способ отделить логику от представления

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

Дык я так и сделал! Отдельно классы - отдельно вид. И файл кот включает в себя первый и второй файлы по необходимости.

controller.php - вызываются в нем методы.
view.tpl - вид и представление

и show.php

объединяет все в себя

P.S. на название файлов внимание не обращать

Я имел ввиду без всяких умняков - вид контроллер и все такое


просто файл с неким классом к примеру users.php где функции работы с юзерами с БД и пр

и просто в старом добром стиле userlist.php с разметкой
куда либо инклудом users.php либо подключить через autoload (так грамотнее)
это такое же разделение логики

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

Точно так! работа с тектом из БД - класс для него. в классе методы.... и так далее.

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

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

ничего не сказано - просто программер с опытом работы больше чем ты на свете живешь

Наукоподобный набор слов из учебника PHP для домохозяек.

C Вами всё понятно
Дальнейшая дискуссия, переходящая на личности, для меня теряет всякий интерес.
Желаю Вам потешаться над своим опытом и далее. Удачи!

В чём мы даём? Человек, не сомневаюсь много работал программистом, и знает своё дело со своей стороны. Только если не знает как лучше выявить абстракции и естественно выделять интерфейсы (может он из своего опыта и применяет это подсознательно) не следует переносить лже клеймо на другие подходы, которые куда "древнее" и зарекомендовавшие себя, чем его опыт, которым он так хвалится. :)

Абстрактные классы - это классы выявленные в результате анализа требований и предметной области, в которой требуется создать "систему" с определённой архитектурой. Эти классы сродни интерфейсам interface и отличаются только тем что в них можно не только свойства и методы декларировать но и задавать реализацию, которая общая для всех дочерних классов (соответственно дочерние классы их могут перегружать). Чем отличается декларированный метод от уже реализованного, только тем что он "говорит" всем "дочерям" что они обязаны его реализовать в себе, то есть определить какой то алгоритм и описывает сигнатуру (имя метода, количество параметров, типы параметров и т.д.) в формате abstract function name(...). Кстати, да, это называется объявление интерфейсов (если конечно методы открыты).
Что ещё даёт абстрактный класс. В проектировании архитектуры и особенно в паттернах проектирования нацеленных на интерфейсы используют типы. Так вот абстрактный класс задаёт тип иерархии допустим продуктов но сам запрещает "инстанцировать себя" а только создаёт заготовку будущих классов (объектов) с определённой группой интерфейсов (открытые методы для пользования "себя" "клиентом" ).
Пример:
Имеем абстрактный продукт (класс) AbstractProduct допустим после рассмотра требований и предметной области магазина (ведь там много разнообразных продуктов)
, который реализует в себе интерфейс addProduct и декларирует интерфейс deleteProduct и этим обязывает последующие классы - объекты реализовать этот интерфейс - метод.
Конкретный продукт ConcreteProduct соответственно его реализовывает.
Фактически любой из этих классов будет не конкретным продуктом!!! (вот здесь философия, как сказал коллега, для домохозяек а контейнером - композицией, которая содержит другие продукты (агрегация), и эта композиция является ни чем иным как абстракцией и являет собой часть паттерна Composition). В паттерне Bridge допустим все "клиенты" работают с конкретными продуктами только через такую абстракцию.

<?php
abstract class AbstractProduct
{
    protected $id = null;

    protected $stack = array();

    public function addProduct(Product $product)
    {
        array_push($stack, $name);
    }

    abstract public function deleteProduct(Product $product);
}

class ConcreteProduct extends AbstractProduct
{
    public function deleteProduct($name)
    {
        // Алгоритм удаления продукта из стека
    }
}
?>

Я наверное увлёкся философией :) ближе к телу. Нам нужно теперь при построении архитектуры что бы клиент работал только с абстракцией, то есть типом.

<?php
$composition = new ConcreteProduct();
// Если объект не является типом AbstractProduct значит возможен в дальнейшем сбой 
// потому что только этот тип может обеспечить то, что есть интерфейс addProduct
if(!($composition instanceof AbstractProduct))
{
    throw new SystemException('Системная ошибка не правильное определение класса');
}
$composition->addProduct(new Product());
?>

Вот как то так :) и философия, и техническая часть, и реализация :)
Можно ещё посмотреть паттерн абстрактная фабрика там хорошо видно использование клиентом типа.

процедурный -> функциональный -> модульный -> ооп

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

Перечитайте еще раз пост от EvilDev на первой странице (жаль что здесь нет нумерации постов.) ,я думаю чувак с гитарой тему говорит.

ЗЫ Тут конечно много чего могут умного наговорить,но пока вы на своей шкуре не испытаете
необходимоть в этих фичах - толку будет мало.
А писать только потому что так модно- ну незнаю... это на любителя гемора.

Да ну! А обычные классы не результат анализа? Зачем тупо цитировать лекции преподавателей не написавших в жизни строки кода а тупо зазубрившие паттерны проектирования.

Любой класс понятие абстрактное и не только в программировании.

abstract в программировании - просто ключевое слово не имеющее никакого прикладного смысла. С таким же успехом вместо abstract class разработчик языка мог употребить fucking class - компилятору было бы пофиг.

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

Их везде используют. А если язык не скриптовый а типизированный то по другому никак. Зачем писать бессмысленный набор слов.

Лучше бы программированием - было бы ближе к тематике форума.

А что, неабстрактный класс - не есть тип?

Каким клиентом?

Паттерны проектирования - просто мода. Это уже неоднократно проходили, была мода на UML - все пытались проектировать на UML с нулевым результатом разумеется, потом была мода на XML - "за XML будущее - все будет на XML" Ага - теперь глядишь там вместо XML JSON сям вместо SOAP сервисов RESTful. Потом мода на AJAX и т.д.

Перестаньте копипастить учебники и попробуйте сами хоть один проект написать. Увидите разницу между теорией и реальностью. Новичкам надо помогать чтобы перестали писать "китайский" (или по другому -"спагетти") код. А не учить их "индийскому" коду где на каждый чих создаются куча интерфейсов и абстрактных фабрик которые потом невозможно отладить даже самому горе-архитектору.

Это разные парадигмы программирования никак друг к другу не относящиеся.

Сожалею о Вашей неграмотности (сразу задаюсь вопросом, точно ли конторы IT).
Статья моя и потрудился над ней я без применения учебников "на прямую". Ну в принципе это всё. Ах да, если Вы UML не применяете это не означает что его нет. Он очень активно у нас в проекте применяется, теперь всё Оривидерчи caballero

bodja

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

Я не писал что его нет. Я писал что мода на него слава Б-гу прошла.
Удивительно неудобная для описания архитектуры нотация.

Что конкретно неграмотно? Кроме бла-бла-бла что нибудь можешь сказать?

Не знал что общаюсь с автором паттернов проектирования

Ну так яж не спорю,просто обозначил некую эволюцию в смене понятий.

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

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

Дело в том что человек задал конкретный вопрос о конкретной структуре синтаксиса в языке программирования. Философия и очевидные вещи о необходимости сначала думать потом кодировать несколько не к месту.

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

Форум о некоем языке программирования PHP или о девочках?

Не имеет смыла обсуждение что такое абстрактный клас вне синтаксиса языка программирования предусматривающем ключевое слово abstract

caballero

Хоть определись.

в чем?

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

Ну начнем с того,что на ПХП можно применять разные парадигмы,сответственно и сваливать все в кучу тоже можно.
То,что нельзя или тяжело реализовать разные парадигмы на других языках,это уже отдельный вопрос и проблемы этого языка.
Еще могу предположить,что под словом парадигма ,вы имеете понимание отличное напрмер от этого
соответственно мы разговариваем про разные вещи.

Что к месту,решать модераторам,
ответ был не вам и не ТС-у.

Можете но ваше предположение, по обыкновению, будет неверным.

А кто утверждал что нельзя?
Капитан Очевидность согласен - если язык позволяет то можно не тпозволяет - нельзя


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

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

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

На функциональном то языке, угу ню ню ...

ДЛЯ функционального языка. В первую очередь для реализации распараллеливания в чем и смысл. Особенно в свете новомодных облачных вычисленний.
Вы вообще читаете что вам пишут? Или смысл выхватить фразу с контекста чтобы придраться не вникая в суть дела.