Qual a vantagem em usar OOP ?

[mmarcondes]

ja vou avisando que faz pouco tempo que estou estudando sobre isso no harbour, eu vi muitos exemplos em outras linguagens pra comparar, entender, e mesmo vendo os exemplos feitos em harbour, não consegui enxergar vantagem, alguem poderia me explicar onde OOP vai ser vantagem.

[JoséQuintas]

não consegui enxergar vantagem, alguem poderia me explicar onde OOP vai ser vantagem.

É um caminho natural.
Na prática, todos gostam de usar pronto, e não de criar.
Acabam atribuindo vantagens à LIB e não ao objeto existir.

Usa TBROWSE ?
Gosta dele trazer tudo pronto ?
Então, é um objeto, com tudo que precisa pra fazer o "browse" dentro do objeto tbrowse.

Evita ficar copiando código de um fonte pra outro, pra fazer a mesma coisa, sendo que já está tudo pronto.

Tem vantagens e desvantagens, não é porque existe que precisa colocar tudo em objeto.

Dá pra ir até mais longe:

A programação está cada vez mais usando a linguagem humana, o modo humano de ser.
VOCÊ, NA SUA CASA, não é normal lidar com objetos ?
E porque não na programação ?
tem o controle remoto da tv, o controle remoto do som, o controle remoto de DVD.....
TV:Remoto, Som:Remoto, DVD:Remoto
E tem o botão power em todos: aperta o power do remoto da TV
TV:Remoto:Power:Click()
No controle remoto, criado por outros, você aperta o botão e tem uma ação definida pra ligar.
No computador, mesma coisa, e o evento Click(), com a diferença de que você vai criar seus buttons, suas rotinas click, etc.
O controle remoto é um objeto da sua casa, e tem os objetos do computador, que são virtuais, não dá pra pegar na mão.

Resumindo: a OOP acaba sendo mais humana, mais natural, menos máquina, não só OOP, mas muitos outros recursos. Veio pra facilitar e não pra complicar.

[mmarcondes]

Entendi, já tinha lido exemplos parecidos, usando essa forma de ensinar pra quem não sabe, mas o que eu queria saber, e acho que não soube me expressar direito, é por exemplo, eu tenho um sistema que tem uns 15 cadastros, fornecedores, clientes, produtos, contas pagar, contas receber, caixa, estoque, etc, então eu teria várias tabelas e várias telas com vários campos para incluir/alterar, etc, e pelos exemplos que eu já vi, a OOP não te poupa o trabalho de ter que ficar escrevendo código, fica a mesma coisa, a única diferença é que vai ter uns prg com um monte de código (as classes), e alguns prg mais bonitinhos usando as classes, mas no final da história, não muda muito.

[JoséQuintas]

pelos exemplos que eu já vi, a OOP não te poupa o trabalho de ter que ficar escrevendo código, fica a mesma coisa, a única diferença é que vai ter uns prg com um monte de código (as classes), e alguns prg mais bonitinhos usando as classes, mas no final da história, não muda muito.

Então andou vendo exemplos muito ruins, ou apenas exempos de como criar classes.
Uma coisa é mostrar como usar, e outra coisa é usar pra valer.
Muda muito sim, poupa trabalho de escrever código fonte sim.

Na prática, a maioria do fórum não usa nenhuma vantagem de classe.
Só seguem exemplos das LIBs bost.as, e só enchem cada vez mais de código fonte, o que é justamente o contrário das vantagens de OOP.

HWGUI e OOHG são os maiores exemplos de merd.a com OOP.
Sim, porque sendo totalmente OOP, praticamente obrigam programação NÃO-OOP.
É igual comprar um computador pra usar onde não tem energia elétrica, não faz sentido algum.
Se tomar elas como base, aí OOP é só desperdício de tempo e fonte.

Mas a culpa maior é dos usuários.
Um mesmo usuário que condena USE no harbour, e diz pra usar dbUse(), em hwgui condena usar a classe diretamente.

Em OOHG foi pior: acho que pediram compatibilidade com minigui extended
OOHG é OOP REAL, mas acrescentaram a OOP estilo gambiarra da extended.
É uma mingui, criada só pra OOP real, que não usa OOP real, passou a usar OOP gambiarra.

LIBs boas, com muitos usuários, funcionam bem, mas que escondem OOP real, e não dão nenhuma vantagem visível de OOP.

[mmarcondes]

Bom, eu não tenho o conhecimento que você tem sobre OOP, nem vou falar nada, até porque não tenho argumento pra isso.
O que eu queria entender mesmo, é justamente isso que você falou, que OOP ajuda a escrever menos código, que tem sentido usar OOP.
Tem alguma forma de mostrar para alguém que está querendo começar a usar OOP, em harbour claro, como fazer as coisas do jeito certo !

[JoséQuintas]

Considero um caminho natural.
Se está costumado a evitar duplicar rotinas, vai encontrar o uso.
Vou tentar criar algo.
Até tinha um exemplo de cadastro simples pronto, mas apaguei há muito tempo.

[JoséQuintas]

Código: Selecionar todos

PROCEDURE RELCLI

   LOCAL nPag := 0, nLin := 99, cTitulo := "RELATORIO CLI"
   
   USE ( "CLI" )
   SET DEVICE TO PRINT
   DO WHILE ! Eof()
      IF nLin > 66
         nPag += 1
         @ 0, Int( ( 132 - Len( cTitulo ) ) / 2 ) SAY cTitulo
         @ 0, "FOLHA " + StrZero( nPag, 6 )
         @ 1, 0 SAY Replicate( "-", 132 )
         nRow := 2
      ENDIF
      @ nRow, 0 SAY cli->Codigo PICTURE "999999"
      @ nRow, 0 SAY cli->nome 
      nRow += 1
   ENDDO
   CLOSE DATABASES
   SET DEVICE TO SCREEN

   RETURN

Um relatório simples.
Quantos relatórios desse tipo são usados?
O mais comum é ficar copiando fonte.

[JoséQuintas]

Transformado em classe

Código: Selecionar todos

CREATE CLASS RelClass

   VAR nLin INIT 99
   VAR nPag INIT 0
   VAR cTitulo INIT ""
   VAR bDetalhe INIT { || Nil }
   METHOD Imprime()

   ENDCLASS

METHOD Imprime()

   SET DEVICE TO PRINT
   DO WHILE ! Eof()
      IF ::nLin > 66
         ::nPag += 1
         @ 0, Int( ( 132 - Len( ::cTitulo ) ) / 2 ) SAY ::cTitulo
         @ 0, "FOLHA " + StrZero( ::nPag, 6 )
         @ 1, 0 SAY Replicate( "-", 132 )
         nRow := 2
      ENDIF
      Eval( ::bDetalhe )
      nRow += 1
   ENDDO
   SET DEVICE TO SCREEN

   RETURN Nil

novo relatório

Código: Selecionar todos

PROCEDURE RELCLI

   LOCAL oList := RelClass():New()
   
   USE ( "CLI" )
   oList:cTitulo := "REL.CLIENTES"
   oList:bDetalhe := { || Detalhe( oList ) }
   oList:Imprime()
   CLOSE DATABASES
   
   RETURN
   
STATIC FUNCTION Detalhe( oList )   
   
   @ oList:nRow, 0 SAY cli->Codigo PICTURE "999999"
   @ oList:nRow, 0 SAY cli->nome 
      
   RETURN Nil

Vai dizer.... tem mais fonte que antes....
Depende, se for só esse relatório sim, se forem centenas, reduziu foi muito.

[JoséQuintas]

Complicando um pouco mais, com método detalhe()

Código: Selecionar todos

CREATE CLASS RelClass

   VAR nLin INIT 99
   VAR nPag INIT 0
   VAR cTitulo INIT ""
   METHOD Detalhe() INLINE Nil
   METHOD Imprime()

   ENDCLASS

METHOD Imprime() CLASS RelClass

   SET DEVICE TO PRINT
   DO WHILE ! Eof()
      IF ::nLin > 66
         ::nPag += 1
         @ 0, Int( ( 132 - Len( ::cTitulo ) ) / 2 ) SAY ::cTitulo
         @ 0, "FOLHA " + StrZero( ::nPag, 6 )
         @ 1, 0 SAY Replicate( "-", 132 )
         nRow := 2
      ENDIF
      ::Detalhe()
      nRow += 1
   ENDDO
   SET DEVICE TO SCREEN

   RETURN Nil

Uma nova classe, pegando a anterior e alterando (HERANÇA)

Código: Selecionar todos

CREATE CLASS RelCliClass INHERIT RelClass
   VAR cTitulo INIT "REL.CLIENTES"
   METHOD Detalhe()   
   ENDCLASS
   
METHOD Detalhe() CLASS RelCliClass
   
   @ ::nRow, 0 SAY cli->Codigo PICTURE "999999"
   @ ::nRow, 0 SAY cli->nome 
      
   RETURN Nil

Fonte

Código: Selecionar todos

PROCEDURE RELCLI

   LOCAL oList := RelCliClass():New()
   
   USE ( "CLI" )
   oList:Imprime()
   CLOSE DATABASES
   
   RETURN

É o antigo método de ficar copiando fonte, sem precisar copiar.
A parte do fonte que está na classe vai sempre funcionar.
Você só precisa se preocupar com o detalhe.
Pode fazer pra clientes, fornecedores, produtos, financeiro, etc. muito fonte economizado.

Então, ESSE é o detalhe: não é economizar código fonte em UM FONTE, é economizar em vários fontes de uma vez, todos os que existem agora, e todos os que poderão existir depois.

E não se trata só de economizar fonte, tá economizando tempo de criação, tempo de teste, etc. porque já sabe a classe funciona.

Nota:
Essa é simples, não mostra uma grande economia de fonte/tempo/trabalho.
Mas mostra que por herança, pode modificar a classe original.
Se a classe não atende determinada situação, ou modifica a classe original, ou cria uma nova modificando a parte diferente, depende de cada situação.
Vai de cada um tirar proveito dos recursos de classe.

[mmarcondes]

Agora eu consegui enxergar, obrigado Quintas, agora ficou claro !
Olhei bem o exemplo e não vi nada de estranho, só uma coisa que não entendi, naquela parte onde você coloca :
::nRow
porque tem os dois pontos repetidos ? qual a utilidade ?

[JoséQuintas]

::nRow indica a variável que existe dentro da classe, seria a abreviação de Self:nRow

Existe parecido no WITH OBJECT, mas nele é um só:

Código: Selecionar todos

WITH OBJECT oRel
   :cTitulo := "teste"
   :bSelf := { || Detalhe() }
ENDWITH

Tem outra coisa importante também: classe é apenas a definição, objeto só existe no uso.

Código: Selecionar todos

oRelCli := RelClass():New()
oRelFor := RelClass():New()

Acima são duas variáveis diferentes com um objeto criado com a estrutura da classe.
CADA objeto relatorio tem seu próprio conjunto de row, lin, ctitulo, etc.
Pode até criar vários relatórios ao mesmo tempo, um não mexeria com o outro - mas se fossem impressoras diferentes ou arquivo txt.
As possibilidades vão se multiplicando, a gente pode acabar achando uso pra isso kkkk

[JoséQuintas]

CADA objeto relatorio tem seu próprio conjunto de row, lin, ctitulo, etc.

Por isso aquele uso de :: é importante.
Dentro de oRelCli, ::nRow indica oRelCli:nRow, não se sabe qual será o nome na criação da classe, só quando usa o objeto criado.
Além disso, a classe pode ter suas variáveis locais normais, nRow indicaria uma variável comum.
Essas variáveis dentro da classe só ficam visíveis dentro da classe e não fora.

É uma espécie de isolamento, de empacotamento, o fonte normal não mexe com o que tem dentro da classe, a não ser que a gente queira, e vice-versa.

Código: Selecionar todos

oRelCli:Imprime()
Imprime()

O Imprime() da classe é dela, vai fazer o que está na classe.
Se tiver outro Imprime() no fonte é do fonte, e não da classe.