Dicas e armadilhas da abstração
Ao escrever uma classe, você pode ter problemas, se tentar trabalhar de forma abstrata demais. É impossível escrever uma classe que satisfaça todos os usuários e cada situação. Imagine que você tivesse de escrever um objeto pessoa para um sistema de folha de pagamento de uma empresa. Esse objeto pessoa vai ser muito diferente de um objeto pessoa no simulador de fluxo de tráfego que discutimos anteriormente.
A abstração pode ser perigosa. Mesmo que você tenha abstraído algum elemento, ele poderá não funcionar em todos os casos. É muito difícil escrever uma classe que satisfaça as necessidades de todos os usuários. Não caia na fixação da abstração — resolva seus problemas primeiro!
Tudo se resume a fazer o suficiente para resolver o problema imediato. Incluir todos os detalhes necessários para o objeto pessoa funcionar nos dois contextos seria muito dispendioso. Isso pode provocar todos os problemas que você viu hoje, devido à responsabilidade embaralhada. Embora você possa ligar seu objeto pessoa às duas situações, ele não será mais um objeto pessoa abstrato. Você perde toda a simplificação que a abstração oferece.
Não coloque em uma classe mais do que o necessário para resolver o problema. Não tente resolver todos os problemas; resolva o problema imediato. Somente então você deverá procurar meios de abstrair o que fez.
É claro que existem ocasiões onde um problema é complexo, como um cálculo difícil ou uma simulação complicada. Estamos falando de complexidade do ponto de vista da responsabilidade. Quanto mais responsabilidades um objeto assume, mais complexo ele será e mais difícil será mantê-lo.
Lembre-se de que adicionar uma nova classe em seu sistema é o mesmo que criar um novo tipo. Ter essa noção em mente ajuda a focalizar o que você está realmente fazendo. Ao falar sobre seu problema, você verá que estará falando em termos dos objetos e das interações e não de dados e métodos.
Finalmente, a verdadeira abstração só pode vir com o tempo.
A verdadeira abstração normalmente nasce a partir de usos reais e não do fato de um programador se sentar e decidir criar um objeto reutilizável. Como diz o ditado, a necessidade é a mãe da invenção. Os objetos funcionam da mesma maneira. Normalmente, você não pode sentar-se e escrever um objeto abstrato realmente reutilizável, logo na primeira vez. Em vez disso, os objetos reutilizáveis normalmente são derivados de um código amadurecido, que foi posto à prova e que enfrentou muitas alterações.
A verdadeira abstração também vem com a experiência. É um objetivo a ser buscado no domínio da POO.
A abstração pode ser perigosa. Mesmo que você tenha abstraído algum elemento, ele poderá não funcionar em todos os casos. É muito difícil escrever uma classe que satisfaça as necessidades de todos os usuários. Não caia na fixação da abstração — resolva seus problemas primeiro!
Tudo se resume a fazer o suficiente para resolver o problema imediato. Incluir todos os detalhes necessários para o objeto pessoa funcionar nos dois contextos seria muito dispendioso. Isso pode provocar todos os problemas que você viu hoje, devido à responsabilidade embaralhada. Embora você possa ligar seu objeto pessoa às duas situações, ele não será mais um objeto pessoa abstrato. Você perde toda a simplificação que a abstração oferece.
Não coloque em uma classe mais do que o necessário para resolver o problema. Não tente resolver todos os problemas; resolva o problema imediato. Somente então você deverá procurar meios de abstrair o que fez.
É claro que existem ocasiões onde um problema é complexo, como um cálculo difícil ou uma simulação complicada. Estamos falando de complexidade do ponto de vista da responsabilidade. Quanto mais responsabilidades um objeto assume, mais complexo ele será e mais difícil será mantê-lo.
Lembre-se de que adicionar uma nova classe em seu sistema é o mesmo que criar um novo tipo. Ter essa noção em mente ajuda a focalizar o que você está realmente fazendo. Ao falar sobre seu problema, você verá que estará falando em termos dos objetos e das interações e não de dados e métodos.
Finalmente, a verdadeira abstração só pode vir com o tempo.
A verdadeira abstração normalmente nasce a partir de usos reais e não do fato de um programador se sentar e decidir criar um objeto reutilizável. Como diz o ditado, a necessidade é a mãe da invenção. Os objetos funcionam da mesma maneira. Normalmente, você não pode sentar-se e escrever um objeto abstrato realmente reutilizável, logo na primeira vez. Em vez disso, os objetos reutilizáveis normalmente são derivados de um código amadurecido, que foi posto à prova e que enfrentou muitas alterações.
A verdadeira abstração também vem com a experiência. É um objetivo a ser buscado no domínio da POO.
Comentários
Postar um comentário