Estrutura Procedural não é melhor para sistemas Empresarias

Programação Arquitetura
#1

Vi alguns tópicos recentemente aqui no GUJ. E vou continuar um assunto polemico. OO X Procedural.

Vejo inúmeros conceitos usados para o desenvolvimento OO e vejo que muitas coisas se contradizem.
Será que para sistemas empresariais não seria melhor adotar uma estrutura “procedural” ?
Porque o que temos realmente não saõ objetos, mas sim casos de uso que pra mim não passam de procedimentos.

ex:
cadastrar funcionário.

fica estranho pensar
funcionario.codigo = 1
funcionario.nome = “Maria”;
funcionario.cadastre-se();

não seria melhor:

cadastrarFuncionario(1,“Maria”)

simboliza a ação (caso de uso) de cadastrar um funcionário.

Não sei se fui bem claro…

#2

E se você precisa exibir os dados na tela?

ResultSet rs = pegarDadosPessoa(1); if( rx.netx() ) { out.println( rs.getString("nome") ); }

Ou seria melhor?

Pessoa p = PessoaDAO.buscar(1); out.println(p.getNome());

Ainda quer pensar proceduralmente?

#3

Concordo plenamente com vc Daniel. Programando de forma procedural vc programa 1 linha para o que vc quer q o programa faça e 30 linhas para o que quer q ele não faça.É +/- assim!

#4

[quote=jprogrammer]Vi alguns tópicos recentemente aqui no GUJ. E vou continuar um assunto polemico. OO X Procedural.
[/quote]

acho que a maioria são meus hehehe

Mas enfim, procedimentos sempre existirão ou tu viu alguma máquina que não leia procedimentos? :wink:

O problema é como são tratados estes procedimentos, se realmente OO, se realemtne PE, ou se realmente OOR(TOO)…
E recentemente ainda tem POA :slight_smile:

Disso nascerá o problema e as discussões, qual melhor? qual usar? porque?

Ao meu ver sempre é uma gambiarra para arrumar outra, assim como um certo SO´s : )

#5

Primeiro:
Será que realmente isso aí é OO ?
Segundo:
Qual a diferença entre ter uma collection de javabens e um resultset ?
Apenas os atributos do javabeans são verificados em complie time e de um resultset (ou outra coisa qualquer) seriam verificados em runtime.
e se eu quisesse apenas alguns campos e pior, se quisesse campos de várias entidades diferentes ?
Outra coisa: eu teria uma coisa qe apenas retornasse valores read-only, pois se trata de uma consulta.

#6

Sobre o read-only, leia um ótimo artigo que colocaram o link aqui no Fórum, sobre encapsulamento de dados. Me clarificou muitas idéias. Além do pattern Memento.

E outra, eu falo de experiência própria. Programei muito em ASP usando ResultSet. É MUITO mais trabalho que usar JavaBeans. Muito código repetido, muito lugar pra dar manutenção, muito pior.

#7

Você quer comparar com aquele RecordSet do ASP. Não tem comparação.
Eu programei muito em ASP também. Se for bem feito não fica tão ruim.
Programava baseado (não orientado) a objetos no ASP.
Tinha classes de acesso a dados que encapsulavam o modo de abertura dos benditos Recordsets.

Quando falo de resultset no java , pode ser qualquer tipo de coleção de registros não necessariamente o resultset do JDBC.

Gosto da estrutura dos bancos relacionais. Será que não ficaria interessante uma estrutura parecida, mais em nível de programa.
Com entidades, procedimentos e consultas. Não é basicamente isso que se resume um sistema.
Não confunda isso com sistemas data-driven. Não tem nada a ver com banco de dados, mas sim a organização das responsabilidades.

Entidades - Definição e Repositorio de dados
Procedimentos - Operações e funções
Consultas - Coleta de dados

Será que fui claro…

#8

e só pra constar mais uma das inúmeras técnicas, tem também a GOO :wink:

#9

Bom, não sou eu que to falando. Até acho que não tenho muito crédito. Mas as literaturas e os “especialistas” estão ai para dizer e “provar” as arquiteturas usadas, suas vantagens e desvantagens.

Sinceramente acho que esse modelo gera muita repetição de código e difícil manutenção (mexe em 30 mil pontos do programa)…

Quanto à sua última sugestão, acho que isso é muito feito com VO (TO), DAO,Bizz Delegates e blablablás…

#10

[quote=jprogrammer]
Gosto da estrutura dos bancos relacionais. Será que não ficaria interessante uma estrutura parecida, mais em nível de programa.
Com entidades, procedimentos e consultas. Não é basicamente isso que se resume um sistema.
Não confunda isso com sistemas data-driven. Não tem nada a ver com banco de dados, mas sim a organização das responsabilidades.[/quote]

E por que não ter uma porção de objetos que colaboram entre si? Aproximar a modelagem do sistema de como as coisas acontecem realmente, ao invés de espalhar funções e procedimentos pra todo lado. Na hora de dar manutenção ou até mesmo extender o sistema, o que fica mais fácil: Sair ‘caçando’ toda a trilha de procedimentos e funções que determinada regra de negócio executa, ou partir dos objetos e suas responsabilidades?

#11

PE

Dados independentes manipulados por funções independentes em locais independentes…

POO

Dados independentes manipulados por métodos dependentes e responsáveis obtendo independência…

hummm, com qual ficar?

#12

Programação procedural sofre do problema de separar dados de comportamento. Então voce acaba com uma pilha de structs e uma pilha de funções. Com OO dados e comportamento ficam no mesmo lugar, é mais facil de modificar e atualizar.

#13

Realmente um grande trunfo do OO é a herança.
Isso é um ponto muito favorável realmente.

Mas quando falamos em procedimentos as pessoas já pensam em coisas separadas sem conexão entre si.
Mas eu acredito que não precisa ser assim.

Acho que temos que partir do caso de uso. O que ele faz. Qual a sequencia de operações.
Não é preciso repetir. Pode-se aproveitar também.
ex:

consistirFuncionario()
{

}

atualizarCadastroFuncionario()
{
consistirFuncionario();
// codigo
}

cadastrarFuncionario()
{
consistirFuncionario();
// codigo
}

E deve ser centralizado. Existir um unico ponto para o caso de uso, ou seja, apenas uma função para realizar esse procedimento.
Não criar redundancias ou repetições.

Outra coisa:
O que estão usando por aí não é um monte de structs(javabens) sendo passados para uma função (session façade sessionbean…).

#14

[quote=louds]Programação procedural sofre do problema de separar dados de comportamento. Então voce acaba com uma pilha de structs e uma pilha de funções. Com OO dados e comportamento ficam no mesmo lugar, é mais facil de modificar e atualizar.
[/quote]

e get/set seriam responsáveis pelo seu comportamento? :stuck_out_tongue: cheirando GOO

#15

jprogrammer, eu nao entendi o seu problema (e aparentemente ninguem entendeu, pq cada um foi pra um lado na conversa). Voce nao quer dar uma explicada melhor sobre o que voce esta querendo dizer, exatamente, pra evitar mais uma Discussao Sem Fim?

#16

Me fale mais sobre esse GOO…

#17

Quem falou em getters e setters? Quanto mais deles uma classe tiver, menos OO ela costuma ser.

#18

O ponto que eu quero chegar é:

Será que estamos programando em OO ?
Ou é um procedural com recursos OO ?
Será que realmente o OO é útil na vida real ?

#19

[quote=jprogrammer]Realmente um grande trunfo do OO é a herança.
Isso é um ponto muito favorável realmente.
[/quote]

:shock: seráaaaaaaaaa?

herança é ruim :smiley:
dependendo da profundidade :wink:

Acho que os grandes trufos são: polimorfismo, decomposição, delegação… :roll:

#20

Gambiarra Orientada a Objetos :lol: