Só devem existir barras finas e barras grosas. Me parece que esse código de barras foi mal plotado.

Existe quatro entradas por ano.
Uma em março, outra em maio, a terceira em agosto e a última em outubro.

Olá Bruno

Não temos planos para oferecer o curso em modalidade EAD. Acreditamos que as dinâmicas realizadas neste curso devem ser essencialmente presenciais

Se você chamar a função "fazQualquerCoisa" passando um funcionario como parâmetro, a função não será mais polivalente e neste caso só aceitará receber objeto do tipo funcionario.

Obrigado.

Recomendo leitura dos livros do Martin Fowler, Robert Martin e Bertram Mayer e bertrand meyer.
Aqui no blog brevemente irei postar um videos sobre esse assunto.

Olá Farnetani

O Flex é bastante flexível quanto a utilização de backend. Se você implementar no backend um webservice, "teoricamente", você poderá fazer um frontend em flex para acessá-lo. Em java e .net eu tenho certeza que funcionará. Contudo em Delphi já tive problemas nesse tipo de comunicação. Mas isso já tem algum tempo e penso que já devem ter corrido. Entretanto, com certeza o acesso via webservices ficará mais lento, mas isso também dependerá do seu caso, da quantidade de dados para transmitir e dos seus condutores arquiteturais.

Olá Rodrigo.
Obrigado por mais um comentário aqui no blog.

Realmente, esses temas são bastante delicados, mas não são visões minhas, é a visão do autor do livro Management 3.0. Inclusive no livro também tem esse exemplo do hidrogênio e oxigênio.

Esses assuntos são densos e geram muitas discussões filosóficas.

Olá André
Na verdade fiquei sabendo do livro Management 3.0 através desse seu post no seu blog. Ele faz parte de um dos referenciais teóricos da minha dissertação de mestrado. Entre outras coisas estou estudando também: learn organization, complexity systems, system thinking, Lean, knowledge management, Storytelling, como base para propor um modelo ágil para criar, registar, transmitir e usar conhecimento em equipes que utilizam desenvolvimento de software agil.

A medida que eu for progredindo, irei compartilhando meus "relatórios técnicos" aqui no blog.
Value!

Priscila.
O código fonte está no final do post, em appServidor e appCliente

Olá Acaz

Como sabemos, herança é um excelente mecanismo para obter reuso em código OO. Herança é um mecanismo para estender as classes existentes para aprimorar classes já existentes. No entanto ela deve ser utilizada com cautela. Em um post anteiro meu, falo sobre as "Condições pra uso de herança". http://edgarddavidson.com/?p=30. Condições que devem ser atendidas para justificar o uso de herança.

Substituir herança por delegação, é uma das técnicas de refatoração apresentadas no livro de Refactoring do Martin fowler, também a citada com boa prática de programação no livro de design patterns Erich Gamma, além de atender aos princípios de projetos Orientados a Objetos. Você verá isso também no livro também Head First Design Patterns.

No exemplo que apresentei no #devday, utilizo "substituir herança por delegação" porque MyStack anula o contrato da classe Vector. Outro motivo é que MyStack não é um tipo especial de Vector. Vector possui métodos em seu contrato como "removeElementAt" e "insertElementAt" que quando são herdados por MyStack passas a ser acessíveis para objetos do tipo MyStack. No entanto, apesar que estendido, os métodos "removeElementAt" e "insertElementAt" não fazem parte do contrato de MyStack, portanto MyStack anulo o contrato da superclasse.

Nesse caso, o melhor a se fazer é refatorar o código, para atender a princípios de projeto aplicando "substituir herança por delegação" e fazendo com que MyStack encapsule o Vector e não mais utilizando o contrato de maneira indevida.