ООП, связаные классы и повторное использование кода

hdd

Новичок
ООП, связаные классы и повторное использование кода

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

Простой пример:
---------------
A - класс БД, который использует какой-нить более низкоуровневый класс (B, для ведения логов, например), классы C, D, E используют A для своих нужд. Получается, что при необходимости использовать класс C в другом проекте, придётся обязательно тащить за ним A и B, или же изменять код класса под нужды данного проекта, что не совсем отвечает концепции повторного использования.

Как же тогда быть, чтобы повторное использование наработанного кода проходило с наименьшими затратами, чтобы не нужно было подстраивать код под текущий проект и чтобы, при необходимости использовать один класс, не пришлось тащить за собой кучу других?

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

denver

?>Скриптер
A - класс БД, который использует какой-нить более низкоуровневый класс (B, для ведения логов, например), классы C, D, E используют A для своих нужд. Получается, что при необходимости использовать класс C в другом проекте, придётся обязательно тащить за ним A и B
Если В не обязателен для работы А, то и передавать его в А нужно необязательным параметром. Тогда если он не нужен - не придется его копировать. Если же он всегда нужен, то придется оба копировать. Или смущает что в таком случае оба класса слишком "зависимы"?
 

whirlwind

TDD infected, paranoid
Как же тогда быть, чтобы повторное использование наработанного кода проходило с наименьшими затратами, чтобы не нужно было подстраивать код под текущий проект и чтобы, при необходимости использовать один класс, не пришлось тащить за собой кучу других?
Нужно опираться на взаимодействие интерфейсов, а не классов. Я бы сказал - _обязательно_, если один класс использует экземпляр другого, для первого необходим интерфейс для установки/замены/получения экземпляра второго класса. Это позволит тестировать, декорировать и прочее. Работа первого класса должна опираться _на_интерфейс_. В этом случае не обязательно тащить в другой проект второй класс. Достаточно обеспечить наличие любого другого класса с требуемым интерфейсом.
 

hdd

Новичок
denver
Да, как раз смущает такая зависимость.

whirlwind
Вообще, такой подход здорово облегчит перетаскивание классов отдельно друг от друга, спасибо за наводку :) Есть что-нить ещё почитать полезного по теме, про такие фишки?
 

whirlwind

TDD infected, paranoid
Есть что-нить ещё почитать полезного по теме, про такие фишки?
Банда Четырех - "Примеры ООП, Паттерны проектирования"
например на стр. 32 вопрос рассматривается на очень доступном уровне
 

hdd

Новичок
wIliaM, Alexandre
Спасибо, рефакторинг уже взял, тока начал читать, до того места значит не добрался ещё.
 

Alexandre

PHPПенсионер
Рефакторинг отличная книга, она кардинально изменила мой взгляд на кодинг...
 
Сверху