A team of programmers is reviewing a proposed API for a new utility class. After some discussion, they realize that they can reduce the number of methods in the API without losing any functionality. If they implement the new design, which two OO principles will they be promoting?
A) Looser coupling
B) Tighter coupling
C) Lower cohesion
D) Higher Cohesion
E) Weaker encapsulation
F) Stronger encapsulation
Eu ia de B e C. O que vocês acham?
bem, eu iria de D e F…
pq?
pela minha definição informal:
acoplamento: grau de dependência com outras classes
coesão: grau de “especialidade” de uma classe
encapsulamento: esconder implementação
se a api vai manter a mesma funcionalidade e ter menos métodos imagino que:
ela vai deixar de exibir métodos “auxiliares” e ser mais direta na funcionalidade proposta (aumento da coesão)
ela tá ocultando métodos que não precisavam ser exibidos (melhor encapsulamento)
imagino que seja isso…
Essa é uma das perguntas mais mal formuladas que já vi em toda história do GUJ.
[quote=TiagoTC]A team of programmers is reviewing a proposed API for a new utility class. After some discussion, they realize that they can reduce the number of methods in the API without losing any functionality. If they implement the new design, which two OO principles will they be promoting?
A) Looser coupling
B) Tighter coupling
C) Lower cohesion
D) Higher Cohesion
E) Weaker encapsulation
F) Stronger encapsulation
Eu ia de B e C. O que vocês acham?[/quote]
Apenas D é correto.
Coupling (acoplamento ) só existe entre duas classes. nada é dito de uma segunda classe, portanto nada podemos inferir sobre o acoplamento.
Encapsulamento tem que ver com a diferença entre o modelo interno e o externo. é dito que diminuiram os métodos na API. Isso singnifica que mudaram os métodos externos, nada é falando sobre a estrutura interna. Logo tb nada podemos inferir sobre o encapsulamento.
So sobra a coesão. A classe é tão mais coesa quanto mais ela tiver apenas uma responsabilidade (Coesão = 1/ Numero de responsabilidades)
Se diminuiram os métodos, obviamente a classe faz menos coisas, logo o numero de responsabilidades diminui, logo a coesão aumentou.
A resposta é D : Higher Cohesion (maior coesão)
Engraçado que ele pergunte “which two”, por isso achei que a pergunta estava mal formulada.
Também pensei no mesmo que o Sergio, Higher Coesion. Entretanto, é difícil afirmar isso, pois a coesão geralmente está relacionada a distribuição de responsabilidades, e podemos apenas inferir, mas não afirmar, que essa classe faz menos coisas.
[quote=ViniGodoy]Engraçado que ele pergunte “which two”, por isso achei que a pergunta estava mal formulada.
Também pensei no mesmo que o Sergio, Higher Coesion. Entretanto, é difícil afirmar isso, pois a coesão geralmente está relacionada a distribuição de responsabilidades, e podemos apenas inferir, mas não afirmar, que essa classe faz menos coisas. [/quote]
Se tem menos métodos tem menos responsabilidades (menor contrato). O numero de métodos é razão direta com a responsabilidade.
Vc deve estar pensando que se a classe tem 10 métodos mas são todos sobrecargas um dos outros, só existe uma responsabilidade. Isso não é verdade.
A responsabilidade é definida pelo que as outras classes (o “mundo”) esperam dela, logo se tem 10 metodos o “mundo” espera 10 coisas.
Isto pode ir além e mesmo com um só método é possivel ter mais do que uma responsabilidade. Basta que algum(s) parametro(s) do método sejam “flags” que mudar o comportamento do método. Isso equivale na realidade a ter N métodos onde N é a combinação possivel de flags, logo tb é uma forma de ter várias responsabilidades.
A pergunta realmente está muito mal formulada, mas baseado no enunciado e sem assumir nada apenas uma resposta é possível.
Se vc quiser sair assumindo coisas qualquer escolha de dois entre A, D e F funciona.
Tlv seja uma daqules em que não ha resposta certa, apenas respostas erradas :lol: :lol: :lol:
Não se você trocou métodos na filosofia do Java, por métodos na filosofia da Microsoft (como vc ressaltou ali)… Reduzir o número de métodos só é vantagem se os métodos restantes não sofreram modificação. O texto fala em “nova API”, mas estamos inferindo que isso não ocorreu, ou seja, que a “nova API” simplesmente reduziu métodos, sem alterar a assinatura dos já existentes.
No Java:
public List<Aluno> getAlunosPorTurma(int turma);
public List<Aluno> getAlunosPorEscola(int escola);
public Aluno getAlunoPorMatricula(int matricula);
Microsoft:
Onde se tipo = 0, retorna uma list com um aluno, e o valor representa a matrícula.
Se tipo = 1, retorna um list com vários alunos, e o valor representa a turma
Se tipo = 2, retorna um list com vários alunos, e o valor representa uma escola.
O parâmetro reservado é para uso futuro, passe 0 nele.
Mas, como o Sergio falou, se não assumirmos nada (ou assumirmos que isso não ocorreu), a resposta certa também parece ser D. Fiquei curioso e procurei esse enunciado na net e achei 3 sites citando a resposta A. Mas não consigo acreditar neles.
[quote]A team of programmers is reviewing a proposed API for a new utility class. After some discussion, they realize that they can reduce the number of methods in the API without losing any functionality. If they implement the new design, which two OO principles will they be promoting?
A) Looser coupling
B) Tighter coupling
C) Lower cohesion
D) Higher Cohesion
E) Weaker encapsulation
F) Stronger encapsulation
Eu ia de B e C. O que vocês acham? [/quote]
Bom, eu pensei e tenho lógica para várias respostas … mas a que eu voto é B e E.
E - Porque a classe, com encapsulamento fraco, necessita de menos métodos para cuidar das variáveis
B - Por consequência de E, partes da classe que não pertencem à API ficarão a mostra possibilitando o alto acoplamento com outras classes.
estranho é ele perguntar “which two” e a alegada resposta correta ser apenas A ( o que também não faz sentido para mim)