ALGUMAS TÉCNICAS DE ANÁLISE E PROJETO ORIENTADOS A OBJETO

PROBLEMAS BÁSICOS DE ANÁLISE E PROJETO

• ESTA SEÇÃO DESCREVE PROBLEMAS DE ANÁLISE E PROJETO FREQUENTEMENTE ENFRENTADOS POR PROJETISTAS

  • ENFOQUE MAIOR EM PROJETO

• APRESENTAM-SE APENAS PROBLEMAS, NÃO SOLUÇÕES

  • SOLUÇÕES SERÃO COBERTAS NAS DEMAIS SEÇÕES DO CAPÍTULO

ACHAR OBJETOS APROPRIADOS

• A PARTE MAIS DIFÍCIL DE ANÁLISE E PROJETO OO (APOO) É EFETUAR A DECOMPOSIÇÃO DO SISTEMA EM OBJETOS

• A TAREFA É DIFÍCIL PORQUE MUITOS FATORES ENTRAM EM JOGO E ESSES FATORES PODEM SER CONFLITANTES:

  • ENCAPSULAMENTO (O QUE ENCAPSULAR?)

  • GRANULARIDADE (MUITOS OBJETINHOS OU POUCOS OBJETÕES?)

  • DEPENDÊNCIA (QUAL ACOPLAMENTO TER ENTRE CLASSES?)

  • FLEXIBILIDADE (FACILIDADE DE MUDANÇA)

  • SIMPLICIDADE (FACILIDADE DE ENTENDIMENTO)

  • PERFORMANCE

  • EVOLUÇÃO

  • REUSABILIDADE

  • ETC. ETC.

• METODOLOGIAS PARA ACHAR OBJETOS OFERECEM TÉCNICAS VARIADAS, MAS NINGUÉM CONCORDA SOBRE QUAL É A MELHOR:

  • ESCREVA O PROBLEMA SOB CONSIDERAÇÃO: SUBSTANTIVOS VIRAM OBJETOS E VERBOS VIRAM OPERAÇÕES

  • FOCAR NAS COLABORAÇÕES E RESPONSABILIDADES (CRC)

  • MODELAR O MUNDO REAL E USAR NO PROJETO AS CLASSES DESCOBERTAS DURANTE A ANÁLISE

  • ETC., ETC.

• NA FASE DE PROJETO, TEM MUITAS CLASSES QUE NÃO CORRESPONDEM A BUSINESS OBJECTS

  • PARA DEIXAR O PROJETO MAIS FLEXÍVEL

    • EXEMPLO: ABSTRAÇÕES PARA TRATAR OBJETOS DE FORMA UNIFORME (COMPOSITE DESIGN PATTERN)

    • EXEMPLO: ABSTRAÇÕES PARA CRIAR OBJETOS SEM SABER SUA CLASSE (FACTORY)

    • ETC., ETC.

  • O PONTO É QUE MODELAR ESTRITAMENTE O MUNDO REAL LEVA A UM SISTEMA QUE REFLETE O MUNDO DE HOJE MAS TALVEZ NÃO O DE AMANHÃ

    • EVITAR ISSO É A MARCA DO GRANDE ARQUITETO OU PROJETISTA OU PROGRAMADOR

  • AS ABSTRAÇÕES QUE EMERGEM DURANTE A PROJETO SÃO A CHAVE PARA DEIXAR UM PROJETO MAIS FLEXÍVEL

DETERMINAR A GRANULARIDADE DE OBJETOS

• O NÚMERO E TAMANHO DE OBJETOS PODEM VARIAR MUITO

• COMO DETERMINAR O TAMANHO IDEAL DOS OBJETOS?

ESPECIFICAÇÃO DE INTERFACES DE OBJETOS

• SÓ SE PODE "CHEGAR" NUM OBJETO ATRAVÉS DE SUA INTERFACE

  • INTERFACE = CONJUNTO DE ASSINATURAS DE MÉTODOS DO OBJETO

• OBJETOS DIFERENTES PODEM OBEDECER A MESMA INTERFACE

  • OBJETOS DIFERENTES PODEM ATÉ TER VÁRIAS INTERFACES IGUAIS

• POLIMORFISMO PODE SER USADO PARA DESACOPLAR O OBJETO DO SEU CLIENTE

• POLIMORFISMO PERMITE INCLUSIVE MUDAR OS RELACIONAMENTOS EM TEMPO DE EXECUÇÃO

  • UM CLIENTE PASSA A TRATAR UM OBJETO DIFERENTE MAS QUE OBEDECE A MESMA INTERFACE

• QUESTÕES CRUCIAIS: ONDE USAR INTERFACES? COMO DETERMINAR BOAS INTERFACES?

ESPECIFICAÇÃO DE IMPLEMENTAÇÕES DE OBJETOS (DETALHES SOBRE OBJETOS)

• QUE ATRIBUTOS USAR?

• QUE CLASSES DEVEM SER ABSTRATAS? CONCRETAS?

• QUE HIERARQUIA DE CLASSES DEVE EXISTIR?

• QUANDO USAR HERANÇA DE INTERFACE (HERANÇA DE TIPO) E HERANÇA DE IMPLEMENTAÇÃO?

MECANISMOS DE REUTILIZAÇÃO

• TEM DUAS FORMAS DE REUTILIZAR FUNCIONALIDADE: HERANÇA E COMPOSIÇÃO

  • COM HERANÇA, UM OBJETO "É UMA" OUTRA COISA

  • COM COMPOSIÇÃO, O OBJETO "TEM UMA" OUTRA COISA

• QUANDO É O MOMENTO ADEQUADO DE USAR CADA FORMA DE REUTILIZAÇÃO?

RELAÇÃO ENTRE ESTRUTURAS DE TEMPO DE EXECUÇÃO E ESTRUTURAS DE TEMPO DE COMPILAÇÃO

• AS DUAS ESTRUTURAS SÃO COMPLETAMENTE DIFERENTES

  • A ESTRUTURA DO CÓDIGO É CONGELADA EM TEMPO DE COMPILAÇÃO

    • SÃO CLASSES COM RELACIONAMENTOS ESTÁTICOS DE HERANÇA

  • A ESTRUTURA DE TEMPO DE EXECUÇÃO (RUN TIME STRUCTURE) É UMA TEIA EXTREMAMANETE DINÂMICA E MUTÁVEL DE OBJETOS COMUNICANTES

• COMO ENTENDER UMA A PARTIR DA OUTRA?

PROJETAR VISANDO A MUDANÇA

• A CHAVE DA MAXIMIZAÇÃO DA REUTILIZAÇÃO (ISTO É, A MINIMIZAÇÃO DA MUDANÇA) É DE ANTECIPAR NOVOS REQUISITOS E MUDANÇAS A REQUISITOS EXISTENTES E PROJETAR OS SISTEMAS DE ACORDO COM AS ANTECIPAÇÕES

  • NÃO ANTECIPAR CORRETAMENTE E NÃO PROJETAR PARA A MUDANÇA IMPLICA EM ATIVIDADES DE RE-PROJETO NORMALMENTE CARAS

• SEGUE UMA LISTA DE CAUSAS DE RE-PROJETO DE SOFTWARE

  • CRIAR UM OBJETO ESPECIFICANDO SUA CLASSE EXPLICITAMENTE

    • ASSIM, VOCÊ ESTÁ SE COMPROMETENDO A USAR UMA IMPLEMENTAÇÃO PARTICULAR (LEMBRE QUE UMA CLASSE É UMA IMPLEMENTAÇÃO)

  • DEPENDÊNCIA DE OPERAÇÕES ESPECÍFICAS

    • AO USAR UMA OPERAÇÃO PARTICULAR, VOCÊ SE COMPROMETE A USAR UMA DETERMINADA FORMA DE SATISFAZER UM PEDIDO

  • DEPENDÊNCIA DE PLATAFORMAS PARTICULARES DE HARDWARE E SOFTWARE

    • DEPENDER DE UMA API DE SISTEMA OPERACIONAL DIFICULTA MUITO A PORTABILIDADE

  • DEPENDÊNCIA DE REPRESENTAÇÕES OU IMPLEMENTAÇÕES DE OBJETOS

    • CLIENTES QUE SABEM COMO UM OBJETO É REPRESENTADO, ARMAZENADO, LOCALIZADO OU IMPLEMENTADO PODERÃO SOFRER ALTERAÇÕES SE O OBJETO MUDAR

  • DEPENDÊNCIAS DE ALGORITMOS

    • ALGORITMOS SÃO FREQUENTEMENTE ESTENDIDOS, OTIMIZADOS E TROCADOS. OBJETOS QUE DEPENDEM DE UM CERTO ALGORITMO TERÃO QUE MUDAR QUANDO O ALGORITMO MUDA

  • ACOPLAMENTO FORTE

    • CLASSES QUE SÃO FORTEMENTE ACOPLADAS SÃO DIFÍCEIS DE REUTILIZAR ISALODAMENTE, JÁ QUE DEPENDEM UMAS DAS OUTRAS.

    • ACOPLAMENTO FORTE LEVA A SISTEMAS MONOLÍTICOS ONDE UMA MUDANÇA EM UM LUGAR SE ESPALHA RAPIDAMENTE E FORÇA MUDANÇAS NO RESTO DO SISTEMA

    • TAIS SISTEMAS SÃO DIFÍCEIS DE ENTENDER, TRANSPORTAR E MANTER

  • EXTENSÃO DE FUNCIONALIDADE ATRAVÉS DA HERANÇA

    • A HERANÇA PROMOVE UM ACOPLAMENTO FORTE ENTRE CLASSES

  • INABILIDADE DE ALTERAR UMA CLASSE CONVENIENTEMENTE

    • AS VEZES, A DIFICULDADE É QUE A CLASSE NÃO PODE SER ALTERADA CONVENIENTEMENTE

      • PODE NÃO TER CÓDIGO FONTE

      • PODE IMPLICAR EM MUDAR MUITAS OUTRAS CLASSES

tecnicas1.htm programa próxima