Ana

Olá pessoal! Hoje nós vamos falar sobre os padrões GRASP. Engraçado né? Está no plural. Isso porque GRASP é um acrônomo para General Responsability Assignment Software Patterns ( Padrões Gerais para Atribuição de Responsabilidades). Bom, para esse post nós teremos como base esse minicurso do YouTube sobre   padrões GRASP . Vamos lá! Uma definição feita no minicurso sobre padrões GRASP é que: é um conjunto de princípios fundamentais para modelagem de objetos e atribuição de responsabilidades escrito na forma de padrões. Um padrão do GRASP é um par: problema e solução. Já que é um par problema solução, vamos falar primeiro o problema e depois o padrão mais adequado para a ocasião. 1) Qual princípio básico para se atribuir responsabilidade a objetos ? Ora, vamos atribuir a responsabilidade a quem tem a informação para realizá-la. Qual o padrão que estamos utilizando ? O information expert! Os benefícios ao usar são: Encapsulamento mantido  Comportamento é bem mais distribu

O assunto de hoje é para tirar um o grilo de quem acha que o que está aprendendo na faculdade ou algum curso formal não é o que será usado no mercado de verdade. Essa semana estive pensando nessa distância, do que é ensinado na faculdade e do que é feito no mercado, e concluí que tem sim uma distância considerável (dá uma olhadinha na postagem anterior bem aqui  sobre modelo anêmico e rico, só de exemplo). Isso me deixou um pouco chateada. Se não é isso que usamos no mercado, porque estamos aprendendo? Você deve ter respondido que devemos aprender o correto. Mas, mais importante que isso, não é só saber qual é o certo, é FAZER o certo.  Nesse período da faculdade, em paralelo ao projetar também preciso desenvolver. Esse foi um dos pontos que me deixaram com uma pulga na orelha. Se eu ainda estou projetando o sistema, planejando a melhor maneira de fazê-lo, por que eu já tenho que desenvolver? Numa dessas, perguntei ao meu professor por que a gente não faz da maneira com que é e

E aí, pessoal ? Voltamos com mais uma postagem sobre projeto de sistemas. Dessa vez, o assunto é sobre modelo anêmico e modelo rico. O que será isso, hein ? Para ficar por dentro da discussão sugiro ouvir o Podcast 11: Modelo Anêmico e Rico no qual foi baseado esse post. No podcast, de acordo com o Alexandre Valente, modelo anêmico é basicamente aquele modelo que tem as regras de negócio um pouco isoladas das entidades de domínio.  Já no modelo rico, as regras estão um pouco melhor distribuídas entre as entidades. E por que será que dá tanto pano para a manga falar desse assunto ? Porque, como a maioria das decisões de projeto, cada modelo há seu pró e contra. Vamos discutir um pouco sobre isso. No podcast, o Alexandre Valente defendeu bastante o modelo anêmico, por ter tido boas experiências com ele e não tão boas assim com o outro. Para ele, a principal vantagem desse modelo é a produtividade. No entanto, para o Giovanni Bassi, esse modelo é um prob

Olá pessoal! Já falamos sobre arquiteto, qualidade  e agora vamos falar sobre Arquitetura de Software! Para começar, o que é uma arquitetura de software ? A arquitetura de software de um sistema computacional refere-se à sua estrutura, consistindo de elementos de software, propriedades externamente visíveis desses elementos e os relacionamentos entre eles. Ela define elementos de software (ou módulos) e envolve informações sobre como eles se relacionam uns com os outros. Uma arquitetura é antes de tudo uma abstração de um sistema que suprime detalhes dos elementos que não afetam como eles são usados, como eles se relacionam, como interagem e como usam outros elementos. Na maioria das vezes, a arquitetura é usada para descrever aspectos estruturais de um sistema. Agora que já sabemos, de modo geral, o que é uma arquitetura; como definimos uma ? quais os fatores que devemos considerar ao escolher uma arquitetura ? Normalmente o projeto da arquitetura é discutido à luz dos requi