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



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

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

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



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



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

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

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

Степанов об ООП
кроме того, такое впечатление, как будто есть только ООП и все (object happiness - не с самого начала, execution in the kingdom of nouns)