POO

Why should I use constructors?

1

Hello people,

Today I had a talk with a friend of mine, we were having class at college and we were making some classes files in Java and I don’t know why but he asked me if I had created the constructor for these class, at the same time I asked him: “Why should I create constructors?”, He answered me what I was hope, he said me that using constructors we can put the complexity of object’s creation in a specific place, So I suggest him why not use the Factory pattern for this? He answered me that sometimes there is no reason to increase the complexity using patterns, so I agree because it is related to KISS principle.
After this little discussion I said that we can use constructor when an object must have some properties with correct values, so using constructor we have a way to create valid objects. I think that it is related with some patterns that and composition principle. Anyway when I read about Object oriented principles I never see any good explanations and tips about constructors. So, if you have more reasons or tips let me know.

O poder das Interfaces

0

Fala galera, vocês certamente conhecem os conceitos de interfaces e classes abstratas em poo.Este post vem falar um pouco destes conceitos muitos famosos mas pouco usados com sabedoria.Bem, esta informação surge da minha experiência com livros e o ensino de oo.Quando perguntava as pessoas qual era a finalidade do uso de interfaces ela me respondiam:
 - Interfaces são usadas para definir um contrato de uso com os objetos que a utilizam

Nunca me disseram alguma coisa mais interessante sobre interfaces. A grande parte dos livros de poo que eu li abordavam muito mal o uso dessa estrutura, é importante ressaltar que não me refiro aos tradicionais e excelentes livros de oo existentes. Estou me referindo a livros brasileiros e outros alguns exemplares estrangeiros.
Há muito tempo eu li um livro de php+padrões de projetos e li um principio de design de software que achei muito interessante:

“Programe para uma interface”


Mesmo tendo lido isso há algum tempo, só hoje começo a reconhecer a importância e o poder desta estrutura. Este conhecimento é devido à leitura que estou realizando, lendo Padrões de projeto use a cabeça reparei no constante uso desta estrutura para permitir flexibilidade.Acredito que muitos de vocês conheçam padrões de projeto, logo sabem do que estou falando.
A lição de moral deste post é procure aprofundar-se na real aplicação da programação orienta a objetos.Desta maneira vocês podem fugir das definições pobres e insuficientes.

Herança usando LINQTOSQL

1

O linq oferece suporte ao programador para que o mesmo trabalhe com orientação a objetos.Sendo a herança um dos pilares da poo cabe ao linq também suporta – lá. Bem, eu criei um projeto simplório, com o objetivo de mostrar que realmente podemos usar herança.
Foram criadas três tabelas, Animal, mamífero e ovíparo (não pensei em uma herança mais inteligente para ser implementada).Segue o script de geração das tabelas.


USE [Animal]
GO
/****** Object: Table [dbo].[Animal] Script Date: 08/24/2008 20:03:28 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[Animal](
[AnimalId] [int] NOT NULL,
[Name] [varchar](200) COLLATE Latin1_General_CI_AS NULL,
[weight] [int] NULL,
[Type] [char](1) COLLATE Latin1_General_CI_AS NULL,
[mammalId] [int] NULL,
[oviparousId] [int] NULL,
CONSTRAINT [PK_Animal] PRIMARY KEY CLUSTERED
(
[AnimalId] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

GO
SET ANSI_PADDING OFF

USE [Animal]
GO
/****** Object: Table [dbo].[Mammal] Script Date: 08/24/2008 20:05:03 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Mammal](
[mammalId] [int] NOT NULL,
[cubPerGrowth] [int] NULL
) ON [PRIMARY]

USE [Animal]
GO
/****** Object: Table [dbo].[Oviparous] Script Date: 08/24/2008 20:05:21 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[Oviparous](
[oviparousId] [int] NOT NULL,
[eggPerGrowth] [int] NULL
) ON [PRIMARY]


Imagens das tabelas:

Agora já possuímos a estrutura de dados necessária.O próximo passo é criar um projeto DataClasses(Add->new Item->LINQTOSQL Classes).Selecione as tabelas e arraste-as para a superfície exibida quando selecionamos o projeto DataClasses

Agora vamos configurar a herança.Clicar na superfície do priojeto dataclasses e selecionar a opção(add->inheritance). Irá aparecer uma opção de confiração, pedindo que sejam selecionadas a classe base e a classe derivada. Como classe base selecionaremos a classe animal e como base a classe ovíparo.Devemos fazer o mesmo para a classe mamífero. Agora a herança existe mas não está configurada, vamos começar pelo relacionamento entre a classe animal e mamífero.clicar no relacionamento e selecionar a opção propriedades.

Base class Discriminator value: qual valor será usado para discriminar a classe base(animal) no nosso caso usaremos a letra ‘a’ animal.
Derived class Discriminator Value: relativo ao valor usado para discriminar a classe derivada. No nosso caso usaremos ‘m’ de mamífero.
Discriminator property: relativo ao campo que será usado para discriminar a herança. No nosso caso será o campo ‘type’
Inheritance default: identifica qual será a herança padrão. No nosso caso selecionaremos animal.

O mesmo processo deve ser realizado para o outro relacionamento entre animal e ovíparo.lembrando que o único valor alterado será a propriedade derived class discrimator value.

Agora já podemos usar nossos objetos com herança.

Qual modificador de acesso usar?

0
Fala Galera, neste post trarei à tona um assunto de suma importância na POO, vamos falar de modificadores de acesso.Acredito que todos conheçam o conceito de modificador de acesso, estou falando daquelas palavrinhas reservadas(public,private,protected,internal entre outras..) que são fundamentais no conceito de encapsulamento disponibilizado pela orientação a objeto. há algum tempo durante o desenvolvimento na empresa onde trabalho me deparei com um erro simples, originado na dúvida de um conceito importante. me ocorreu o seguinte: criei uma função em uma das classes de négocio e não estava conseguindo acessá-la.Fui instruido pelo meu colega de trabalho a verificar o modificador de acesso da determinada função. E ai estava…havia esquecido de defini-lo.A explicação era simples, sempre que eu não defino um modificador de acesso é como se eu tivesse definido o modificador privado, logo nunca conseguiria acessar meu método.Desde este fato fiquei na dúvida sobre qual era a vantagem do padrão de acesso ser privado.Então durante a leitura do livro de refatoração do M.Fowler verifiquei que quando um método está definido com o modificador mais “privado” possivel fica mais facil alterá-lo. Exemplo: se você deseja renomear um método e seu modificador de acesso for publico provavelmente você deverá procurar referências em todo seu código.Entretanto se você modificar um método que está definido como privado certamente seu trabalho de alteração das referências será menor concorda?Você pode estar pensando que tal alteração não é de grande importancia, porém se você ou sua equipe tem o costume de refatorar ou modificar o código estas atividades serão muito mais fáceis se grande parte dos métodos estiverem definidos de acordo com sua real necessidade. É isso galera, boa semana!!

Criando interfaces de Métodos

0

Fala Galera, neste post irei tratar de um fato corriqueiro na vida dos desenvolvedores, A criação de Métodos.Muito escutei sobre a criação de métodos, mas pouco me foi explicado o Porquê de criar métodos com boa interface.bem, influenciado pela empresa onde trabalho e por alguns livros sobre “como programar” venho por meio deste postar algumas dicas e fatos que acho interessantes.Lembro de ter lido em algum livro um comentário que achei muito interessante.

“Devemos programar para uma interface.” Martin Fowler
Hoje compreendo o que ele quis dizer com tal afirmação, então vamos lá.Quando olhamos um método seja para compreendê-lo ou para altera-lo nosso primeiro contato com o mesmo se faz por meio de seu nome correto? então posso presumir que se tenho dois métodos:
public String GetCustomerName()…
public String GetCName()…

É extremamente mais facil compreender o primeiro método correto?! Logo não preciso análisar o corpo do método para saber seu retorno, não posso dizer o mesmo para o segundo método.Todavia existe outro problema muito comum, quando analisamos um método como o primeiro método e vemos que seu código faz inumeras coisas e retorna o nome do cliente concatenado com o cpf. Isto significa que este método faz mais que seu nome indica.Com a orientação a objetos temos a fantástica possibilidade de encapsular determinados comportamentos, entretanto olhando a assinatura do método esperamos um resultado e recebemos outro, Logo alguma coisa está estranha.Ai comecei a entender o real significado de programar para uma interface, na interface definimos o objetivo do método e durante a programação devemos programar de acordo com o objetivo(assinatura do método).

Este é um tipo de post que rende muito assunto e demanda tempo, poderiamos ainda falar de visibilidade de métodos, lista de parâmetros entre outros.. É isso galera, espero que tenham gostado e espero em breve postar mais sobre a construção de Métodos

Go to Top