Factory Method Teoria - Padrões de Projeto - Parte 10/45
HTML-код
- Опубликовано: 7 фев 2025
- Vamos aprender a teoria do Factory Method. Este padrão tem a intenção de definir uma interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar. O Factory Method permite adiar a instanciação para as subclasses.
Veja a parte prática em: • Factory Method Prática...
Nessa playlist estamos falando sobre os padrões de projeto (design patterns) da gang of four (gof). Esses padrões foram catalogados nos anos 90 e são extremamente relevantes atualmente em qualquer linguagem de programação.
O livro original se chama "Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos" e pode ser adquirido em amzn.to/32nciKC
As categorias dos padrões de projeto são: creational (criacional), behavioural (comportamental) e structural (estrutural).
Os padrões de cada categoria são os seguintes.
Creational: Abstract Factory, Builder, Factory Method, Prototype e Singleton.
Structural: Adapter, Bridge, Composite, Decorator, Façade, Flyweight e Proxy.
Behavioural: Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method e Visitor.
O link da playlist (vou tentar disponibilizar um ou dois vídeos por semana):
• Padrões de Projeto (De...
Link do projeto no Github:
github.com/lui...
Cursos de Python e JavaScript / TypeScript com desconto:
www.otaviomira...
Twitter: / otaviomirandabr
#designpatterns #padroesdeprojeto #typescript
Quer aprender Python, JavaScript ou TypeScript? Da uma olhada nos meus cursos em www.otaviomiranda.com.br/2017/meus-cursos/
Boa noite quero fazer justiça ,as suas aulas são sempre de muita qualidade e prazeroso aprender com o senhor professor Otávio Miranda
Me ajudou demais, parabéns pelo conteúdo de extrema qualidade!!
Brigadão =)
Show amigo, muito obrigado pela aula!
Muito boa a aula, esclareceu bastante
Parabéns Otávio ,,👍🏻
Like por deixar as coisas um pouquinho mais claras para mim. Mas ainda tenho dúvida sobre o assunto, e deixo elas aqui para quem puder me ajudar a entender.
Se algum dia é decidido que um objeto do produto concreto ConcreteProduct precisa imprimir "What's up" também, e não somente "Hi", não seria necessário alterá-lo? Por que assumimos que o código está fechado para modificação?
Por que esse receio em alterar código? Pode ser pela minha falta de experiência, mas se for utilizado uma série "escada if-else" no método factoryMethod da classe Creator, para decidir, de acordo com um parâmetro, qual o objeto instanciar, isso não resolve o problema sem ter que criar um novo criador concreto? Nesse caso, nó teria que criar um novo if-else para instanciar um novo produto concreto. Me parece, a princípio, menos trabalho.
Se ao invés de uma classe, eu coloco a lógica que decide qual objeto instanciar dentro de um método na mesma classe que consome esse objeto, ainda estaria seguindo esse padrão? O criador abstrato é obrigatório para que seja possível afirmar que estamos usando o padrão Factory Method?
Obrigado pela aula, aqui no caso. 😁
Aos 5:43, você menciona que é possível passar parâmetros para uma fabrica e ela retornar tipos de objetos diferentes. É comum ter uma única fabrica que pode retornar diversos tipos de objetos ou ter diversas fabricas, que cada uma retorna o seu tipo?
fui o like numero 1000
Cara parabéns mesmo!!!
Obrigado
1000%❤
02:01 - motor em inglês é motor mesmo, está certo.
na verdade engine e motor são usados em inglês, sendo engine o mais comum
Você tem algum curso que ensina a documentar um sistema? Fazer levantamento de requísitos, Validação de requisitos, Modelagem e etc. Não encontro este tipo de curso nem a pau
(curso prático)
Só leituras são capazes disso. De fato nunca vi. Eu invisto em livros para sanar essa falta.
Sossega com esse laser aí, pelo amor de Deus que nervoso !! Estava tenso ? !