Quando falamos sobre design em orientação a objetos, estamos basicamente falando sobre responsabilidade e relacionamento. Com responsabilidade quero dizer algo que alguma coisa faz e com relacionamento quero dizer como alguma coisa utiliza aquilo que outra coisa faz. O Design de Software Orientado a Objetos trata especificamente da forma com que os objetos se relacionam, ou seja, como expor a responsabilidade dos objetos de forma que outros objetos possam se relacionar.
Do ponto de vista do Design de Software Orientado a Objetos, não importa, exatamente, como alguma coisa é feita. Pelo contrário, o objetivo é justamente evitar esse conhecimento sobre a implementação, encapsulando o que é específico para permitir que trabalhemos com a definição conceitual daquilo que precisamos utilizar. Por exemplo, é comum uma aplicação precisar trabalhar com um SGBD. Se nossos objetos tiverem conhecimento específico de que estamos, na verdade, trabalhando com MySQL, então é provável que os comportamentos relacionados a esse SGBD influenciem o comportamento de nossos objetos - Isso, do ponto de vista de design, é ruim.
Grande parte do design orientado a objetos envolve API, ou seja, a forma com que expomos as responsabilidades. API significa interface que, por sua vez, significa aquilo que vemos e podemos trabalhar com. O grande porém, é podemos ter APIs públicas e APIs privadas do ponto de vista do objeto referencial. Voltando ao exemplo do SGBD, as questões específicas referentes à conexão, são irrelevantes para objetos de alto nível, que vão apenas consumir a base. Porém, questões como essas podem ser altamente relevantes para objetos de baixo nível, se estivermos desenvolvendo algo como a PDO, do PHP, que abstrai a comunicação com vários SGBDs relacionais.
Algumas tecnologias permitem a elaboração dessas APIs de forma diferente, como friend class em C++, protected class em Java, etc. Mas independentemente da forma como é construída, existem três tipos de APIs:
Objetos de alto nível não devem ter conhecimentos sobre as responsabilidades dos objetos de baixo nível. Quanto mais conhecimento os objetos de alto nível tiverem sobre os de baixo nível, mais complexo será manutenção desse código. A API pública deve ser a mais refinada e abstrata possível. Ao definir essa API, devemos pensar no conceito que o objeto representa.
Como exemplo de refinamento conceitual, a PDO do PHP é um excelente exemplo, pois permite que utilizemos os mesmos métodos de interface, independentemente do SGBD que estamos trabalhando.
A API protegida é, ao mesmo tempo, pública e privada, dependendo do referencial. Internamente, para os objetos que fazem parte da hierarquia, essa API é pública. Assim, métodos com responsabilidade de baixo nível são acessíveis, permitindo que reutilizemos código comum para aquela responsabilidade. Por exemplo, se mais do que um SGBD possuir uma forma comum para estabelecer conexão, então o método de conexão pode ser protegido.
A API privada é visível apenas para o objeto que a define. Isso significa que a responsabilidade dos métodos que compõem essa API são tão específicos para aquela implementação, que não devem ser expostos. Isso chama-se encapsulamento e é extremamente para garantir a abstração.
A exposição de uma API privada para um participante que não deveria ter conhecimento sobre ela, viola o encapsulamento, que viola a abstração ao permitir conhecimento específico sobre a implementação. É claro que você, como um desenvolvedor responsável, dirá que tomará cuidado com esse conhecimento. Mas o fato é que muito provavelmente o conhecimento específico afetará seu código e, se isso ocorrer, você terá problemas se precisar variar o participante que detém determinada responsabilidade.
Por isso, sempre que estiver trabalhando no design de objetos, procure expor para os objetos de alto nível, apenas o que for de alto nível. Deixe para os objetos internos, trabalharem com a API interna. Não viole o encapsulamento, pois ao fazer isso, você provavelmente colocará conhecimento específico no seu código e provavelmente se arrependerá dessa decisão no futuro.
João,
Primeiramente, vou falar como eu penso (atualmente) quando planejo uma nova app ou refactoring.
Como você falou, o "segredo" é que programemos para uma interface, não para uma implementação, ou seja: Não é correto saber como um problema será resolvido e sim que ele será resolvido. Partindo disto pensei o seguinte:
Vou tentar ilustrar ao máximo um cenário real, onde minha aplicação tenha que ser manutenível, testável, com alta performance e disponibilidade e que consoma poucos recursos. Quando eu digo "com alta performance e disponibilidade e que consoma poucos recursos", isso não tem nada a ver com design oo, masssssss, minha app realmente precisa disso.
(vou dar um tempo aqui pq não posso responder agora. hehehehe)