Muito bom. Implementação exemplo em 00:02:18. Críticas em 00:07:35. Monostate em 00:08:50 Singleton : "A ideia por trás do singleton é que a própria classe carregue a sua instância".
Video excelente mais uma vez, sério, super parabéns pelo conteúdo, massa demais!!! Pra quem ta começando agora ou até mesmo pra quem ja programa a algum tempo eu diria uma coisa: Não precisa estudar todos os Design Patterns existentes e sair aplicando por ai em todo projeto que vcs veem, estudem antes de mais nada sobre lógica, programem bastante, façam projetos, evitem usar libs (especialmente quando vc ta começando, entra no código fonte, tem mt lib que é literalmente um arquivo só, tem mt lib que nem precisaria ser usada) , ai vc eventualmente vai dar de cara com um caso de uso que vc precisa implementar um design pattern. Vcs vão saber quando vcs vão ter que implementar um Design Pattern específico naquele contexto que vcs estão trabalhando. E sinceramente também nem liguem tanto pro Clean Code assim, sei que todo mundo fala dele, mas esqueçam a existência dele pra quando de fato vcs precisarem dele. Tem um video do Programador BR que ele literalmente diz "F###-se o clean code" e é justamente isso. Antes de aprender algo pq alguém disse que tem que ser feito assim, foquem em desenvolver a lógica e especialmente o senso crítico em cima das coisas, aprendam a quando dizer NÃO pra algo. Tem vários momentos que aplicar o Clean Code não faz o menor sentido. Posso dar um exemplo pessoal: Eu tava no meu projeto implementando um websocket (utilizando a API de WebSockets do Browser e não libs como o socket.io) percebi que enquanto eu desenvolvia quando eu tinha duas conexões abertas no browser com o mesmo websocket a conexão antiga se perdia e só se mantinha a última. Além disso tinha outro problema, quando eu fazia um fast refresh ou do server ou do front a conexão se perdia e eu precisava me reconectar novamente automaticamente. Fui atras de como resolver isso na internet e então dei de cara com o Singleton. Com ele eu consigo manter só uma instância do meu websocket ativa no browser e também fica fácil de me reconectar quando eu perco a conexão ou com o back ou com o front. Para aquele caso de uso o Singleton era a melhor opção. E era a melhor opção pq eu sabia que de fato teria que usar ele pra resolver meu problema. Então voltando, meu processo foi: Encontrei um problema no meu código e preciso resolve-lo ---> Encontro um design pattern capaz de resolver meu problema ---> uso o Design Pattern para resolver o problema. Vejo muito dev fazendo esse caminho: Não existe um problema ainda e usei um design pattern pq aprendi que é importante usar ---> uso um design pattern para resolver um problema que nem existe e talvez nunca exista TL:DR: Aprendam lógica antes de aprender Design Patterns, Clean Code e qualquer coisa e USEM QUANDO VCS DE FATO PRECISEM. Vcs precisam ter um problema antes de sair implementado algo que foi criado justamente pra resolver um problema
Concordo plenamente xará, só complemento sugerindo o uso em projetos de testes pelo fato de que se for precisar usar e/ou trabalhar em uma empresa /projeto que necessite é bom ter pelo menos o básico para não ficar muito perdido.
Nicolasmelo12 eu vi esse vídeo do "f###-se o clean code" mas a pouco tempo atrás , tive minha primeira entrevista para Dev Mobile Jr e a coisa que me "reprovou" foi não ter tido contado com Cean Code e SOLID. Entrevista pra Jr e os recruiter/empresas estão exigindo clean code mano. é foda, mas infelizmente quem que entrar numa vaga precisa dançar conforme a música. . A regua pra entrar no mercado parece estár ficando cada vez mais alta.
Foi citado (8:18) que um dos problemas de usar o Singleton é que uma chamada a um método da classe pode alterar um estado da classe e um outro lugar que esteja consumindo esses dados pode ter problemas, por não detectar ou não tratar essa alteração. O MonoState também não teria esse problema, uma vez que mesmo sendo instâncias diferentes elas compartilham o mesmo estado?
Eu levantei esse mesmo questionamento. Creio que essa restrição de "estado compartilhado" ainda seja verdadeira. O monorepo soluciona o princípio de responsabilidade única e faz o código mais "limpo". Porém de fato não vi solução para o estado compartilhado.
Para mim os dois padrões implementam a mesma funcionalidade com abordagens diferentes, pois os dois se utilizam de atributos estáticos para suas implementações. Os mesmo problemas de notificação de mudanças de estado dos atributos existentes no Singleton se apresentam no MonoState.
Concordo, em ambos os patterns você trabalha com algo muito próximo de variáveis globais, na prática eu procuro evitar ambos e utilizar Dependency Injection, mas quando não é possível, o principal ponto que pra mim pesa mais contra o Silgeton e a favor do Monostate é a utilização de interfaces, facilita bastante os testes. Porém em ambos eu utilizaria propriedades readonly, sem setters, ou com setters utilizando regras bem restritas, algo nessa linha, buscando ao menos minimizar os possíveis problemas.
Muito bom! Eu particularmente não conhecia o Monostate e já utilizei singletons algumas vezes, principalmente quando precisava implementar algum tipo de "Service". Achei a abordagem do monostate tão simples quando a do singleton, porém, nos permite usar melhor o poder da OO. Como sugestão de design pattern acho que vale a pena mencionar o DELEGATE. Parabéns e muito obrigado pelo vídeo. ❤👨💻
Eu passei por uma fase de paixão por laços de repetição, mas como paixão é doença eu comecei a trabalhar com chamada de funções e classes como vocês fazem e vi o código ter saltos de performance. Minha paixão por laços tem relação com a checagem de dados de saída de comandos sem escrever arquivos de saída. Ainda quero conseguir fazer isso sem for. Mas creio que se performance fir exigida será necessário fazer arquivos temporários. E também estou vendo que limpar arquivos temporários de modo inconsequente também traz dir de cabeça. O certo é remover somente o que o código cria, mesmo que estenda um pouco o código isso é eficiente, eficaz e deixa de causar problemas em aplicações que rodam em paralelo. Essa observação é valida apenas no uso da pasta temporária do sistema ou com o uso de processos assíncronos da aplicação. Só digo que essa nova fase está complicada de aprender, mas é graças a vocês que passei a ver a importância de se saber utilizar as chamadas de classes e funções. Um grande abraço!
Eu já conhecia os dois, porém não precisei implementar nenhum deles ainda. Ultimamente tenho até usado o singleton, mas através da injeção de dependência (o contêiner injeta sempre a mesma instância quando preciso dela)
Uso o singleton para criar "managers" dentro da aplicação e ele tem funcionado muito bem para isso. Não conhecia o mono state. Vou implementar para ver se é aplicável a minha solução. Minha dúvida fica com a alocação de memória e recursos, o mono state não usaria mais? Obrigado pelo tutorial!
Vídeo bem legal, trabalho em um projeto bem grande em Java que usaram singleton, eu não usaria mas tudo bem! Só faltou um detalhe, proteger a getInstance() contra multiplas execuções simultâneas, resultando em instâncias perdidas. Em Java usamos Synchronized na declaração da função.
Já usei muito o Singleton, mas só o usava com atributos somente leitura, que carregados basicamente na inicialização do sistema: dados da conexão com o banco de dados, dados da conexão com um outro servidor de algum outro serviço e outros do tipo. E usando dessa forma ainda vejo problema.
Penso que o Singleton não seja um antipatern, mas carece de muito cuidado em sua aplicação. Particularmente costumo usar, principalmente em sistemas embarcados e depois de um tempo desenvolvi certa prática para identificar as situações onde ele se aplica.
Interessante. Mas como isso resolve o problema da geração de bugs? O fato de ter um atributo compartilhado entre todas as instâncias ainda permite que um determinado trecho de código faça alterações nós dados de forma transparente e que podem impactar em outros locais
Seria legal vídeos explicando, para quais exemplos de projetos ou trechos de código, utilizar os padrões, eu fico muito perdido nisso ainda, acredito que muitos devs Jr também. Há e muito obrigado pela dedicação em trazer conteúdo de qualidade 😃
Monostate assim viola o D (Dependency Inversion principle) do SOLID, já que ta fazendo instanciação do objeto dentro da classe. Da pra resolver com uma interface "state" e receber/injetar o objeto que implementa state via construtor. Vale lembra que SOLID é uma recomendação, não uma regra. Se singleton funciona pra vc, use.
Acredito que o maior problema do Singleton é o quando vc esconde dependências dentro dele. O que impossibilita que vc altere internamente alguma dependência sem modificar código ou que descubra (em alguns casos como c++/dll) o que vc precisa que exista para que internamente ele funcione. Acho que a maioria desses problemas podem ser resolvidos quando vc usa singleton através de um controle como injeção de dependências... que controla a quantidade de instâncias sem necessidade de variáveis estáticas.
Eu vendo o vídeo fiquei 'nossa, muito interessante, assim da não ter novas instancias e compartilhar as informações criadas em um lugar', depois que vocês falaram do monostate eu fiquei 'Obvio! Tinha aprendido em C# que tem os objetos staticos que já são por padrão compartilhados entre as instâncias'
Eu somente não compreendi no que o Monostate pode resolver o problema de uma mesma instancia ser executada em diferentes pontos da aplicação gerando bugs. Realmente não será mais uma instancia, porém várias, contudo os atributos ainda são estáticos, ou seja, o mesmo problema de acesso simultâneo em diferentes pontos da aplicação não permaneceria ?
Acho que o Singleton quebra o Open-Closed Principle e não o SRP. Para uma classe ser "open", deve ser possível herdar dela e Herança é um relacionamento "is-a". Se você herdar de uma classe de singleton, as instâncias da classe filha também são instâncias da classe pai devido ao relacionamento "is-a ", o que significa que você pode repentinamente ter várias instâncias da classe de singleton. Se a classe singleton inibir a herança, ela não estará mais "open" e se uma classe singleton permite herança e está "open" para extensão, ela não pode mais impor o padrão singleton.
Já que a classe tem duas responsabilidades, por que não separar elas em duas classes distintas? Um com todas as "regras de negócio" da classe e outra somente para centralizar a instanciação ?
Já que tocou no assunto, Service Locator seria uma opção mais interessante ao Monostate e Singleton, embora ele também seja considerado um antipattern.
Sobre Anti-Pattern: Penso que é igual a quando a gente fala sobre algo que é tratado como excessão à regra. Para ser uma excessão isso tem que ter se tornado uma regra então uma atualização de documentação é essencialmente necessária. Ou seja, se tem uso é um pattern assim como qualquer outro com suas devidas aplicações e restrições. Só isso. Ou se for colocar que é anti-pattern que seja sempre especificado em relação a qual pattern. Nesse caso um pattern é anti-pattern do outro. Não?
E possível atuar na área sem ter faculdade? Eu sempre tive interesse na área, e estou aproveitando a crise para estudar por conta, mas fico com medo de tudo isso ser inútil.
Sim e possível, inclusive conheço muitos que não possuem e atuam em diferentes níveis de cargo de júnior a especialista sem ter fáculdade. Meu comentário nãos desmerece o esforço de quem fez ou está fazendo, no entanto, o que conta é o conhecimento e isso cursos , e dedicação lhe garantem. Então estude muito e vai pra cima, cansei de ver gente formada em entrevista que não passa por não conseguir fazer a prova e pessoas sem faculdade passando e dando exemplo não se apega. Se puder faça faculdade, mas consegue fazer carreira sem ela também.
Acredito que a melhor forma de utilizar o singleton seja com injeção de dependência, assim temos apenas uma instância que será injetada em seus modulos...
Sempre usei o Monostate sem mesmo saber o que era kkkk! Acho desnecessário o Sigleton, sem sentido, já que você pode definir propriedades estáticas nas classes. Em um projeto grande, a alteração de uma “variável global” sem tratamento pode ser uma tremenda dor de cabeça, até mesmo se tornando uma missão impossível o debug. Por isso, melhor seguir o SOLID! Outra coisa que de fato tem muito peso na escolha do Design Pattern, é que a linguagem de programação, ela interfere muito nisso. Por exemplo, no .NET, é quase que intuitivo usar o Monostate, e pra mim, no PHP, pela falta de algumas funcionalidades em relação ao .NET, pode parecer, a primeira vista, mais fácil usar Singleton.
Ou melhor, deixo o construtor privado. Não é necessariamente a singleton pq não tem uma instância mas na minha visão é um singleton hehe. Na memória é quase a mesma coisa e o uso TB, mas em o chato getInstance()
Boa noite Código Fonte TV, não concordo em dizerr que o Singleton é vilão ou fere o SOLID. o Angular e C# implementam muito bem o singleton com IoC e continua sendo muito usado. o time da Angular inclusive recentemente criou a propriedade provideIn pra isso, e o time do .netcore usa o ServiceCollection com o AddSingleton em seu container.
Pra sair fogo enquanto você digita: Baixe o VS Code Baixe a extenssão Power Mode No VS Code, aperte Ctrl + shift + p Escreva Json, aperte Enter E cole essa linha → "powermode.presets": "flames". Salve e aproveite!
Parabéns pelo vídeo! Não conhecia o Monostate e vou começar a citá-lo nas minhas aulas. Também sou crítico do Singleton, mas por outros motivos, e até comentei isso nos meus vídeos sobre esse padrão: th-cam.com/play/PL3EuFy3x9CgCTaIxg6vbtN6VxrCsYFdWr.html Abraços e continuem disponibilizando material relevante!
Sinceramente, acredito que se você precisa recorrer ao Singleton ou Monostate é porque tem algo de errado no seu design. Ps: Monostate também é considerado um antipattern.
Muito bom.
Implementação exemplo em 00:02:18.
Críticas em 00:07:35.
Monostate em 00:08:50
Singleton : "A ideia por trás do singleton é que a própria classe carregue a sua instância".
😅😊😊😅😊😅😊w😮😊😊😅😅😅😊😊😊 h
Video excelente mais uma vez, sério, super parabéns pelo conteúdo, massa demais!!!
Pra quem ta começando agora ou até mesmo pra quem ja programa a algum tempo eu diria uma coisa:
Não precisa estudar todos os Design Patterns existentes e sair aplicando por ai em todo projeto que vcs veem, estudem antes de mais nada sobre lógica, programem bastante, façam projetos, evitem usar libs (especialmente quando vc ta começando, entra no código fonte, tem mt lib que é literalmente um arquivo só, tem mt lib que nem precisaria ser usada) , ai vc eventualmente vai dar de cara com um caso de uso que vc precisa implementar um design pattern. Vcs vão saber quando vcs vão ter que implementar um Design Pattern específico naquele contexto que vcs estão trabalhando. E sinceramente também nem liguem tanto pro Clean Code assim, sei que todo mundo fala dele, mas esqueçam a existência dele pra quando de fato vcs precisarem dele.
Tem um video do Programador BR que ele literalmente diz "F###-se o clean code" e é justamente isso. Antes de aprender algo pq alguém disse que tem que ser feito assim, foquem em desenvolver a lógica e especialmente o senso crítico em cima das coisas, aprendam a quando dizer NÃO pra algo. Tem vários momentos que aplicar o Clean Code não faz o menor sentido.
Posso dar um exemplo pessoal: Eu tava no meu projeto implementando um websocket (utilizando a API de WebSockets do Browser e não libs como o socket.io) percebi que enquanto eu desenvolvia quando eu tinha duas conexões abertas no browser com o mesmo websocket a conexão antiga se perdia e só se mantinha a última. Além disso tinha outro problema, quando eu fazia um fast refresh ou do server ou do front a conexão se perdia e eu precisava me reconectar novamente automaticamente. Fui atras de como resolver isso na internet e então dei de cara com o Singleton. Com ele eu consigo manter só uma instância do meu websocket ativa no browser e também fica fácil de me reconectar quando eu perco a conexão ou com o back ou com o front. Para aquele caso de uso o Singleton era a melhor opção. E era a melhor opção pq eu sabia que de fato teria que usar ele pra resolver meu problema.
Então voltando, meu processo foi: Encontrei um problema no meu código e preciso resolve-lo ---> Encontro um design pattern capaz de resolver meu problema ---> uso o Design Pattern para resolver o problema.
Vejo muito dev fazendo esse caminho: Não existe um problema ainda e usei um design pattern pq aprendi que é importante usar ---> uso um design pattern para resolver um problema que nem existe e talvez nunca exista
TL:DR: Aprendam lógica antes de aprender Design Patterns, Clean Code e qualquer coisa e USEM QUANDO VCS DE FATO PRECISEM. Vcs precisam ter um problema antes de sair implementado algo que foi criado justamente pra resolver um problema
Muito obrigado pelo seu comentário Nicolas!
Enriquecedor. Valeu!
Concordo plenamente xará, só complemento sugerindo o uso em projetos de testes pelo fato de que se for precisar usar e/ou trabalhar em uma empresa /projeto que necessite é bom ter pelo menos o básico para não ficar muito perdido.
Nicolasmelo12 eu vi esse vídeo do "f###-se o clean code" mas a pouco tempo atrás , tive minha primeira entrevista para Dev Mobile Jr e a coisa que me "reprovou" foi não ter tido contado com Cean Code e SOLID.
Entrevista pra Jr e os recruiter/empresas estão exigindo clean code mano. é foda, mas infelizmente quem que entrar numa vaga precisa dançar conforme a música.
.
A regua pra entrar no mercado parece estár ficando cada vez mais alta.
Foi citado (8:18) que um dos problemas de usar o Singleton é que uma chamada a um método da classe pode alterar um estado da classe e um outro lugar que esteja consumindo esses dados pode ter problemas, por não detectar ou não tratar essa alteração. O MonoState também não teria esse problema, uma vez que mesmo sendo instâncias diferentes elas compartilham o mesmo estado?
Eu levantei esse mesmo questionamento. Creio que essa restrição de "estado compartilhado" ainda seja verdadeira. O monorepo soluciona o princípio de responsabilidade única e faz o código mais "limpo". Porém de fato não vi solução para o estado compartilhado.
Eu assinei a Hostgator faz algum tempo, por causa da publicidade em um vídeo de vcs.
Melhor professor de Js
Para mim os dois padrões implementam a mesma funcionalidade com abordagens diferentes, pois os dois se utilizam de atributos estáticos para suas implementações. Os mesmo problemas de notificação de mudanças de estado dos atributos existentes no Singleton se apresentam no MonoState.
Exato! 6 por meia dúzia!
Concordo, em ambos os patterns você trabalha com algo muito próximo de variáveis globais, na prática eu procuro evitar ambos e utilizar Dependency Injection, mas quando não é possível, o principal ponto que pra mim pesa mais contra o Silgeton e a favor do Monostate é a utilização de interfaces, facilita bastante os testes. Porém em ambos eu utilizaria propriedades readonly, sem setters, ou com setters utilizando regras bem restritas, algo nessa linha, buscando ao menos minimizar os possíveis problemas.
Muito bom! Eu particularmente não conhecia o Monostate e já utilizei singletons algumas vezes, principalmente quando precisava implementar algum tipo de "Service". Achei a abordagem do monostate tão simples quando a do singleton, porém, nos permite usar melhor o poder da OO.
Como sugestão de design pattern acho que vale a pena mencionar o DELEGATE.
Parabéns e muito obrigado pelo vídeo. ❤👨💻
Eu passei por uma fase de paixão por laços de repetição, mas como paixão é doença eu comecei a trabalhar com chamada de funções e classes como vocês fazem e vi o código ter saltos de performance. Minha paixão por laços tem relação com a checagem de dados de saída de comandos sem escrever arquivos de saída. Ainda quero conseguir fazer isso sem for. Mas creio que se performance fir exigida será necessário fazer arquivos temporários. E também estou vendo que limpar arquivos temporários de modo inconsequente também traz dir de cabeça. O certo é remover somente o que o código cria, mesmo que estenda um pouco o código isso é eficiente, eficaz e deixa de causar problemas em aplicações que rodam em paralelo.
Essa observação é valida apenas no uso da pasta temporária do sistema ou com o uso de processos assíncronos da aplicação.
Só digo que essa nova fase está complicada de aprender, mas é graças a vocês que passei a ver a importância de se saber utilizar as chamadas de classes e funções.
Um grande abraço!
Eu já conhecia os dois, porém não precisei implementar nenhum deles ainda. Ultimamente tenho até usado o singleton, mas através da injeção de dependência (o contêiner injeta sempre a mesma instância quando preciso dela)
Perfeita explicação!!!!
Uso o singleton para criar "managers" dentro da aplicação e ele tem funcionado muito bem para isso. Não conhecia o mono state. Vou implementar para ver se é aplicável a minha solução. Minha dúvida fica com a alocação de memória e recursos, o mono state não usaria mais? Obrigado pelo tutorial!
Vídeo bem legal, trabalho em um projeto bem grande em Java que usaram singleton, eu não usaria mas tudo bem! Só faltou um detalhe, proteger a getInstance() contra multiplas execuções simultâneas, resultando em instâncias perdidas. Em Java usamos Synchronized na declaração da função.
Caraca, eu já tinha pensado nisso, eu implementei isso a muito tempo mas não sabia que isso era um Design Patterns.
Que legal...
Eu conhecia apenas o singleton, a partir de agora vou aposenta-lo. Muito obrigado!
Muito legal o video. Eu não conhecia o Monostate, e já usei o Singleton para solucionar alguns problemas e deu super certo.
Já usei muito o Singleton, mas só o usava com atributos somente leitura, que carregados basicamente na inicialização do sistema: dados da conexão com o banco de dados, dados da conexão com um outro servidor de algum outro serviço e outros do tipo. E usando dessa forma ainda vejo problema.
Tipo os dados serem acessados ao mesmo tempo?
Utilizo muito singleton, e agora pretendo migrar para o monostate. Não o conhecia. Muito obrigado pelo vídeo.
Monostate também é um anti-padrão.
Penso que o Singleton não seja um antipatern, mas carece de muito cuidado em sua aplicação. Particularmente costumo usar, principalmente em sistemas embarcados e depois de um tempo desenvolvi certa prática para identificar as situações onde ele se aplica.
Vocês são demais, parabéns!
Interessante. Mas como isso resolve o problema da geração de bugs?
O fato de ter um atributo compartilhado entre todas as instâncias ainda permite que um determinado trecho de código faça alterações nós dados de forma transparente e que podem impactar em outros locais
Piora o fato de que isso não é thread-safe :)
Seria legal vídeos explicando, para quais exemplos de projetos ou trechos de código, utilizar os padrões, eu fico muito perdido nisso ainda, acredito que muitos devs Jr também. Há e muito obrigado pela dedicação em trazer conteúdo de qualidade 😃
Monostate assim viola o D (Dependency Inversion principle) do SOLID, já que ta fazendo instanciação do objeto dentro da classe.
Da pra resolver com uma interface "state" e receber/injetar o objeto que implementa state via construtor.
Vale lembra que SOLID é uma recomendação, não uma regra. Se singleton funciona pra vc, use.
Ameei
Acredito que o maior problema do Singleton é o quando vc esconde dependências dentro dele. O que impossibilita que vc altere internamente alguma dependência sem modificar código ou que descubra (em alguns casos como c++/dll) o que vc precisa que exista para que internamente ele funcione. Acho que a maioria desses problemas podem ser resolvidos quando vc usa singleton através de um controle como injeção de dependências... que controla a quantidade de instâncias sem necessidade de variáveis estáticas.
Queria que vcs falassem do Strategy ou do Command, se puder.
tem playlist de design patterns?
como ficaria o monostate se ficasse responsável por gerenciar conexão com o banco?
Eu vendo o vídeo fiquei 'nossa, muito interessante, assim da não ter novas instancias e compartilhar as informações criadas em um lugar', depois que vocês falaram do monostate eu fiquei 'Obvio! Tinha aprendido em C# que tem os objetos staticos que já são por padrão compartilhados entre as instâncias'
Bastante interessante esses design patterns!
Video top! 👌
Video excelente
Falem sobre repository no laravel por exemplo, pois estudando a um tempo atrás é um assunto polemico entre os devs.
Não conhecia o singlestate...
Muito obrigado e parabéns pelo trabalho a toda equipe!
Eu somente não compreendi no que o Monostate pode resolver o problema de uma mesma instancia ser executada em diferentes pontos da aplicação gerando bugs. Realmente não será mais uma instancia, porém várias, contudo os atributos ainda são estáticos, ou seja, o mesmo problema de acesso simultâneo em diferentes pontos da aplicação não permaneceria ?
Acho que o Singleton quebra o Open-Closed Principle e não o SRP. Para uma classe ser "open", deve ser possível herdar dela e Herança é um relacionamento "is-a". Se você herdar de uma classe de singleton, as instâncias da classe filha também são instâncias da classe pai devido ao relacionamento "is-a ", o que significa que você pode repentinamente ter várias instâncias da classe de singleton.
Se a classe singleton inibir a herança, ela não estará mais "open" e se uma classe singleton permite herança e está "open" para extensão, ela não pode mais impor o padrão singleton.
O singleton, além de fazer a sua função, também cuida do seu ciclo de vida (criação e acesso), logo ele faz duas coisas, quebrando o SRP.
Excelente Vídeo pessoal. Parabéns casal Código fonte.
Qual alternativa em java?
Já que a classe tem duas responsabilidades, por que não separar elas em duas classes distintas? Um com todas as "regras de negócio" da classe e outra somente para centralizar a instanciação ?
Muito legal!!!
Parabéns!!
essa animação de "foguinho" durante a escrita do código é pacabá hein KKK
implementação bem parecida de verdaxi meismo vei! Muito bom ! Vou tirar 20 na programação 3
seria legal um vídeo de Service Locator vs Injeção de Dependência
Já que tocou no assunto, Service Locator seria uma opção mais interessante ao Monostate e Singleton, embora ele também seja considerado um antipattern.
Muito bom, e nao conhecia o monostate
Muito obrigado Harold! :D
Oba! Tava com saudades já! Hahaha
Sobre Anti-Pattern: Penso que é igual a quando a gente fala sobre algo que é tratado como excessão à regra. Para ser uma excessão isso tem que ter se tornado uma regra então uma atualização de documentação é essencialmente necessária. Ou seja, se tem uso é um pattern assim como qualquer outro com suas devidas aplicações e restrições. Só isso. Ou se for colocar que é anti-pattern que seja sempre especificado em relação a qual pattern. Nesse caso um pattern é anti-pattern do outro. Não?
Vocês podem fazer qual a tecnologia por trás do jogo Gartic?
E possível atuar na área sem ter faculdade?
Eu sempre tive interesse na área, e estou aproveitando a crise para estudar por conta, mas fico com medo de tudo isso ser inútil.
Sim e possível, inclusive conheço muitos que não possuem e atuam em diferentes níveis de cargo de júnior a especialista sem ter fáculdade. Meu comentário nãos desmerece o esforço de quem fez ou está fazendo, no entanto, o que conta é o conhecimento e isso cursos , e dedicação lhe garantem.
Então estude muito e vai pra cima, cansei de ver gente formada em entrevista que não passa por não conseguir fazer a prova e pessoas sem faculdade passando e dando exemplo não se apega.
Se puder faça faculdade, mas consegue fazer carreira sem ela também.
Porque no video (apresentacao) a vanessa fica do lado direto e quando vai codificar fica do lado esquerdo ?
Vc são top
Muito bom, mostra o Repository na próxima
Usava o monostate e nem sabia, kkk
Duvida: Pelo fato do Monostate ter um GetMembers() e SetMembers(), não fere a responsabilidade única do Solid?
Acredito que a melhor forma de utilizar o singleton seja com injeção de dependência, assim temos apenas uma instância que será injetada em seus modulos...
Sempre usei o Monostate sem mesmo saber o que era kkkk! Acho desnecessário o Sigleton, sem sentido, já que você pode definir propriedades estáticas nas classes. Em um projeto grande, a alteração de uma “variável global” sem tratamento pode ser uma tremenda dor de cabeça, até mesmo se tornando uma missão impossível o debug. Por isso, melhor seguir o SOLID!
Outra coisa que de fato tem muito peso na escolha do Design Pattern, é que a linguagem de programação, ela interfere muito nisso. Por exemplo, no .NET, é quase que intuitivo usar o Monostate, e pra mim, no PHP, pela falta de algumas funcionalidades em relação ao .NET, pode parecer, a primeira vista, mais fácil usar Singleton.
Eu gosto que minhas fábricas sejam singletons.
Ou melhor, deixo o construtor privado. Não é necessariamente a singleton pq não tem uma instância mas na minha visão é um singleton hehe. Na memória é quase a mesma coisa e o uso TB, mas em o chato getInstance()
Excelente seu comentário!
Que idade você tinha quando descobriu que chamava mono state de singleton?
Eu: 34
Segundo a comentar kkkkk
Amo o vosso canal, amei o video!(no momento ainda nem vi(kkkkkkkkkk))
Fogo do inferno este aí do VsCode.
Boa noite Código Fonte TV, não concordo em dizerr que o Singleton é vilão ou fere o SOLID.
o Angular e C# implementam muito bem o singleton com IoC e continua sendo muito usado.
o time da Angular inclusive recentemente criou a propriedade provideIn pra isso, e o time do .netcore usa o ServiceCollection com o AddSingleton em seu container.
wtf sai fogo quando o cara digita kkkkkkkkk
@Akira Gustavo Minami Programação Orientada ao Ódio
é pq o código acabou de sair do forno(badunts piada ruim)
@Akira Gustavo Minami oi akira
Pra sair fogo enquanto você digita:
Baixe o VS Code
Baixe a extenssão Power Mode
No VS Code, aperte Ctrl + shift + p
Escreva Json, aperte Enter
E cole essa linha → "powermode.presets": "flames".
Salve e aproveite!
@@system_gang6995 Eca, sai com essa moda pra lá, irmão! Aqui é RAIZ!! kkk
Estais hoje, mais linda! 😘
Minha visão é que esse monoState é apenas caracteristica da orientação de objetos, tratar como design pattern parece over demais...
Primeiro uhu
Parabéns pelo vídeo!
Não conhecia o Monostate e vou começar a citá-lo nas minhas aulas.
Também sou crítico do Singleton, mas por outros motivos, e até comentei isso nos meus vídeos sobre esse padrão: th-cam.com/play/PL3EuFy3x9CgCTaIxg6vbtN6VxrCsYFdWr.html
Abraços e continuem disponibilizando material relevante!
Sinceramente, acredito que se você precisa recorrer ao Singleton ou Monostate é porque tem algo de errado no seu design.
Ps: Monostate também é considerado um antipattern.
Singleton e monostate são apenas variáveis globais glorificadas.
SOLID => quem precisa de cabrestos?!
Qual o problema de vocês em usar o pobre Javascript... eu não entendo quando usam php :sadnoises:
Pra games infelizmente é um pattern que simplifica muito.
Da proxima vez aumente a fonte no editor