diff --git a/docs/Entregas/Tres/Interna.md b/docs/Entregas/Tres/Interna.md
index c95a3640..211daa2a 100644
--- a/docs/Entregas/Tres/Interna.md
+++ b/docs/Entregas/Tres/Interna.md
@@ -18,7 +18,7 @@ software](https://unbarqdsw2023-2.github.io/2023.2_G1_ProjetoAmazon/Entregas/Doi
a ser desenvolvido com base na etapa anterior, e assim, desenvolveu o software
da disciplina utilizando padrões de projeto e uma [arquitetura
MVC](https://github.com/UnBArqDsw2023-2/2023.2_G1_ProjetoAmazon/blob/main/docs/ArquiteturaReutilizacao/reutilizacao/Arquitetura.md).
-Assim, este documento sumariza todos esses processos.
+Assim, este documento sumariza todos esses processos.
## Processo
@@ -53,7 +53,7 @@ no qual foi
[validado](https://unbarqdsw2023-2.github.io/2023.2_G1_ProjetoAmazon/Entregas/Um/EntrevistaValidacao.html)
dias após.
-### Modelagem
+## Padrões de Projeto
Na segunda entrega, foi desenvolvido duas classes de diagramas, os
estáticos(classes, pacotes, componentes e implantação) e os
@@ -66,45 +66,51 @@ Dando um enfoque maior no
[diagrama de classes](https://unbarqdsw2023-2.github.io/2023.2_G1_ProjetoAmazon/Entregas/Dois/DiagramaDeClasses/DiagramaDeClasses.html),
podemos listar alguns casos de possíveis reutilizações do software.
-1 - Proxy: na imagem 1, podemos ver que a classe carrinho tem uma relação
-simples com uma conta de usuário,sendo assim , para a aplicação é importante
-que o usuário só tenha acesso a este recurso caso ele esteja autenticado no
-sistema, caso não, ele deve ser barrado ao tentar acessar este recurso, assim,
-o padrão de projeto proxy é o ideal para esta situação.
+### 1 - **Proxy**:
+
+No diagrama 1 podemos observar a implementação de um Proxy que
+checa se o usuário está autenticado antes de realizar qualquer operação. Isso é
+importante para garantir que somente usuários autenticados possam fazer
+operações que modificam o carrinho, já que não existe carrinho que não é
+associado a um usuário já existente.
+
+
+ 
+ Diagrama 1 (Fonte: Autor, 2023).
+
+
+### 1.1- Implementação **Proxy**:
+A implementação desse padrão está evidenciada na imagem 1:
- 
+ 
Imagem 1 (Fonte: Autor, 2023).
-2 - Strategy: na imagem 2, pode-se encontrar a classe concreta pagamento e 3
-classes que herdam dela: pix, boleto e cartão. No contexto da aplicação, é
+O proxy faz o controle de acesso por meio do método `has_acess`, e possui uma
+instância da classe concreta `CartService`. Ambas implementam o protocol
+`CartServiceProtocol`.
+
+### 2 - **Strategy**:
+No diagrama 2, pode-se encontrar a classe concreta pagamento e 3
+classes que herdam dela: pix, boleto ou outras. No contexto da aplicação, é
importante que o usuário autenticado possa escolher qual o método de pagamento
que ele irá utilizar para obter o produto, sendo assim, o padrão strategy se
encaixa nessa situação.
- Imagem 2 (Fonte: Autor, 2023).
+ Diagrama 2 (Fonte: Autor, 2023).
-Vale lembrar que durante o diagrama de classes podemos encontrar exemplos de
-GRASPs como polimorfismo afim de garantir um baixo acoplamento e alta coesão.
-Um exemplo claro já foi descrito na imagem 1 que é o de uma herança das classes
-pix, boleto e cartão com a classe pagamento.
-
-### Padrões de Projeto
-
-Por fim, os padrões de projeto são uma concretização da reutilização de
-software. A seguir, podemos ver como foram implementadas os padrões de projeto
-descritos na seção anterior deste documento:
-
-1- Strategy: No momento da produção deste artefato, o padrão ainda não está
-totalmente concluido. A implementação desse padrão está evidenciada na imagem 3:
+### 2.2- Implementação **Strategy**:
+A implementação do padrão Strategy está descrita na imagem 2.
+Esse padrão permite o alto desacoplamento da funcionalidade relacionada ao
+pagamento utilizando diversos métodos de pagamento diferentes.
- 
- Imagem 3 (Fonte: Autor, 2023).
+ 
+ Imagem 2 (Fonte: Autor, 2023).
Como em python não temos explicitamente classes abstratas ou interfaces, a
@@ -120,20 +126,82 @@ permite que um serviço opere usando somente a noção abstrata de um método de
pagamento, mas ainda assim conseguindo acessar seus respectivos dados. Isso é
útil em situações onde não é preciso saber o método de pagamento específico.
-2- Proxy: A implementação desse padrão está evidenciada na imagem 4:
+Vale lembrar que durante o diagrama de classes podemos encontrar exemplos de
+GRASPs como polimorfismo afim de garantir um baixo acoplamento e alta coesão.
+Um exemplo claro já foi descrito na imagem 2 que é o de uma herança das classes
+pix, boleto e outras com a classe pagamento.
+
+
+## Considerações finais
+
+A implementação dos padrões de projeto Proxy e Strategy, aplicados ao escopo da disciplina, pode ser conferida no [repositório da disciplina](https://github.com/UnBArqDsw2023-2/2023.2_G1_ProjetoAmazon/tree/main/src).
+
+### Modelagem e Reutilização
+**[Proxy](#padrões-de-projeto)**: Foi implementado um Proxy para verificar a autenticação do usuário antes de permitir operações no carrinho. Isso garante que apenas usuários autenticados possam modificar o carrinho.
+
+**[Strategy](#padrões-de-projeto)**: A implementação do padrão Strategy foi evidenciada no contexto de métodos de pagamento. A classe concreta de pagamento permitiu a criação de subclasses como PIX, boleto, entre outras, proporcionando flexibilidade na escolha do método de pagamento.
+
+**Flyweight, Builder, Observer (Não Implementados dentro do projeto)**: Reconhecemos a oportunidade de explorar os padrões Flyweight, Builder e Observer para aprimorar a arquitetura do software. No contexto do perfil do comprador na Amazon, esses padrões poderiam ser aplicados da seguinte forma:
+
+- `Flyweight`: Neste padrão de projeto, temos como objetivo colocar mais objetos na quantidade de RAM disponível ao compartilhar partes comuns de estado entre múltiplos objetos ao invés de manter todos os dados em cada objeto. Neste caso, fizemos uma simplificação da classe endereço que estava contida dentro da classe contaDoUsuario, nele nos abstraimosa classe pesada e deixamos apenas atributos essenciais, ja na classe EnderecoCompleto temos atributos que são derivados daqueles atributos que estão na classe endereço.
+
+ Diagrama e Código - Flyweight
+
+ 
+ Diagrama 4 (Fonte: Autor, 2023).
+
+
+ 
+ Imagem 3 (Fonte: Autor, 2023).
+
+
+
+
+- `Builder`: Para melhorar a velocidade de criação do usuário, há a necessidade de cria-lo utilizando o padrão builder, tal padrão se utiliza de uma interface que define oe metodos que serão implementados no builder concreto. O builder concreto é justamente a classe UsuarioBuilder, na qual implementa todos os métodos da interface. Alguns métodos notáveis que podemos destacar são :
+
+ - Inicializador: Inicia com um reset e atribuindo um carrinho para o usuário, já que não há a necessidade de um processo maior para a construição do mesmo.
+ - Reset: Realiza a instânciação de um novo usuário.
+ - Get Usuário: retorna o usuário
+ - Demais metodos: implementam lentamente o usuário
+
+ Diagrama e Código - Builder
- 
+ 
+ Diagrama 4 (Fonte: Autor, 2023).
+
+
+ 
Imagem 4 (Fonte: Autor, 2023).
+
+
+
+- `Observer`: O usuário necessita saber a situação do seu pedido, sendo assim, há a necessidade de implementar o padrão observer. No exemplo acima, foi criado uma interface chamada observador, no qual irá observar determinada classe. A classe observada é Pedido no qual tem um método que notifica todas as classes que desejam observa-la, assim, a classe ContaDoUsuario é notificada e atualiza seu status.
+
+
+ Diagrama e Código - Observer
+
+ 
+ Diagrama 5 (Fonte: Autor, 2023).
+
+
+ 
+ Imagem 5 (Fonte: Autor, 2023).
+
+
+
+
+Embora tenhamos aplicado com sucesso os padrões Strategy e Proxy, reconhecemos que outros padrões como Flyweight, Builder e Observer poderiam ser explorados para aprimorar ainda mais a arquitetura do software.
+
+Além disso, é importante resaltar que foi utilizado módulos prontos do Django, como autenticação, renderização, entre outros, foram utilizados, evidenciando a importância da reutilização de software não apenas a nível de código, mas também de frameworks e bibliotecas.
-Na classe de service, temos o método "has_access" no qual verifica se o usuário
-está autenticado, senão, ele retorna uma excessão, se sim, retorna o usuário.
-Na sequência, temos os métodos que atuam como a operação que desejamos guardar.
## Referências
>[1] SILVEIRA, Samara. A reutilização de software e suas aplicações. Disponível em: <https://blog.casadodesenvolvedor.com.br/reutilizacao-de-software/>. Acesso em: 29 nov 2023.
+>[2] PlantUML Web Server. Disponível em: . Acesso em: 1 dez. 2023.
+
## Histórico de versão
@@ -142,3 +210,7 @@ Na sequência, temos os métodos que atuam como a operação que desejamos guard
| `1.0` | 29/11/2023 | Iniciando o documento | Kauã | Ana |
| `1.1` | 30/11/2023 | Adicionando informações | Kauã | Ana |
| `1.2` | 30/11/2023 | Informações sobre especialização | Guilherme | Arthur |
+| `1.3` | 01/12/2023 | Alterações no documento | Kauã e Ana| Beatriz |
+| `1.4` | 01/12/2023 | Melhoria dos Diagramas | Guilherme | Arthur |
+| `1.5` | 01/12/2023 | Adição dos padrões e diagramas | Ana e Kauã| Beatriz |
+
diff --git a/docs/Entregas/Tres/Proxy.png b/docs/Entregas/Tres/Proxy.png
new file mode 100644
index 00000000..8c566a4a
Binary files /dev/null and b/docs/Entregas/Tres/Proxy.png differ
diff --git a/docs/Entregas/Tres/VisaoLogica.md b/docs/Entregas/Tres/VisaoLogica.md
index c3df6ae1..062033c8 100644
--- a/docs/Entregas/Tres/VisaoLogica.md
+++ b/docs/Entregas/Tres/VisaoLogica.md
@@ -8,7 +8,18 @@ Visão Lógica apresenta a oragnização do software de modo mais estrutural, on
## Metodologia
-Para a confecção da visão lógica da arquitetura, os membros responsáveis decidiram trazer uma visão por meio dos pacotes. Com base no diagrama de pacotes foi elaborado a visão lógica, elucidando pontos que foram consirados importantes na arquitetura de acordo com os autores. Foi utilizado o webapp [Lucidchart](https://www.lucidchart.com/pages/) para a confecção do artefato. Por fim, foi publicado o diagrama para os membros do grupo ficarem cientes do processo.
+Para a confecção da visão lógica da arquitetura, os membros responsáveis decidiram trazer uma visão por meio dos pacotes e Sequência. Com base no diagrama de pacotes e Sequência foi elaborado a visão lógica, elucidando pontos que foram consirados importantes na arquitetura de acordo com os autores. Foi utilizado o webapp [Lucidchart](https://www.lucidchart.com/pages/) para a confecção do artefato. Por fim, foi publicado o diagrama para os membros do grupo ficarem cientes do processo.
+
+## Diagrama de Sequência
+
+O diagrama de sequência é um diagrama de interação que mostra como os processos operam com um foco em sequência. Ele mostra objetos, classes e componentes envolvidos nas operações e a sequência de mensagens trocadas entre os objetos necessários para realizar a funcionalidade da operação.
+
+
+
+ Diagrama de Sequência: Versão 2.0 (Fonte: Autores, 2023).
+
+
+## Diagrama de Pacotes
### Primeira versão
@@ -29,10 +40,11 @@ Segunda versão criada em 30/11/2023.
-
## Referências
> [1] SLIDE AULA - Arquitetura e Desenho de Software - Aula Arquitetura e DAS - Parte II. Profa. Milene Serrano . Disponivel em: [aprender3](https://aprender3.unb.br/pluginfile.php/2649469/mod_label/intro/Arquitetura%20e%20Desenho%20de%20Software%20-%20Aula%20Arquitetura%20e%20DAS%20-%20Parte%20II%20-%20Profa.%20Milene.pdf). Acesso em 27 de nov. de 2023.
+>
+> [2] Diagrama de Seqüência. Disponivel em: [profs.ic.uff](http://profs.ic.uff.br/~viviane.silva/es1/util/aula8.pdf). Acesso em 4 de out. de 2023.
## Histórico de versão
@@ -41,4 +53,5 @@ Segunda versão criada em 30/11/2023.
| :----: | :--------: | :--------------------------------------: | :-----------: | :-----------: |
| `1.1` | 28/11/2023 |Criação do documento e adição da imagem inicial | Samuel Sato | Augusto D. Camargo |
|`1.2`|30/11/2023|Adição do diagrama mais detalhado, sendo essa a sua versão final|Augusto D. Camargo| Samuel Sato|
+|`1.3`|01/12/2023|Adição do diagrama de Sequencia|Beatriz| Samuel Sato|
diff --git a/docs/Entregas/Tres/VisaodeprocessosVF.png b/docs/Entregas/Tres/VisaodeprocessosVF.png
new file mode 100644
index 00000000..51f041d5
Binary files /dev/null and b/docs/Entregas/Tres/VisaodeprocessosVF.png differ
diff --git a/docs/Entregas/Tres/assets/Fly.png b/docs/Entregas/Tres/assets/Fly.png
new file mode 100644
index 00000000..f727e43e
Binary files /dev/null and b/docs/Entregas/Tres/assets/Fly.png differ
diff --git a/docs/Entregas/Tres/assets/Proxy.png b/docs/Entregas/Tres/assets/Proxy.png
new file mode 100644
index 00000000..0d0ecc67
Binary files /dev/null and b/docs/Entregas/Tres/assets/Proxy.png differ
diff --git a/docs/Entregas/Tres/assets/builder.png b/docs/Entregas/Tres/assets/builder.png
new file mode 100644
index 00000000..9c0fa4a6
Binary files /dev/null and b/docs/Entregas/Tres/assets/builder.png differ
diff --git a/docs/Entregas/Tres/assets/builder_diagram.png b/docs/Entregas/Tres/assets/builder_diagram.png
new file mode 100644
index 00000000..c75f9525
Binary files /dev/null and b/docs/Entregas/Tres/assets/builder_diagram.png differ
diff --git a/docs/Entregas/Tres/assets/fly_diagram.png b/docs/Entregas/Tres/assets/fly_diagram.png
new file mode 100644
index 00000000..e4200010
Binary files /dev/null and b/docs/Entregas/Tres/assets/fly_diagram.png differ
diff --git a/docs/Entregas/Tres/assets/observer.png b/docs/Entregas/Tres/assets/observer.png
new file mode 100644
index 00000000..3e75fdb8
Binary files /dev/null and b/docs/Entregas/Tres/assets/observer.png differ
diff --git a/docs/Entregas/Tres/assets/observer_diagram.png b/docs/Entregas/Tres/assets/observer_diagram.png
new file mode 100644
index 00000000..78a3c10c
Binary files /dev/null and b/docs/Entregas/Tres/assets/observer_diagram.png differ
diff --git a/docs/Entregas/Tres/assets/proxy-example.png b/docs/Entregas/Tres/assets/proxy-example.png
new file mode 100644
index 00000000..86a0981d
Binary files /dev/null and b/docs/Entregas/Tres/assets/proxy-example.png differ
diff --git a/docs/Entregas/Tres/assets/strategy-example.png b/docs/Entregas/Tres/assets/strategy-example.png
new file mode 100644
index 00000000..efecf75c
Binary files /dev/null and b/docs/Entregas/Tres/assets/strategy-example.png differ
diff --git a/docs/Entregas/Tres/assets/strategy.png b/docs/Entregas/Tres/assets/strategy.png
index e1283646..e5e3feda 100644
Binary files a/docs/Entregas/Tres/assets/strategy.png and b/docs/Entregas/Tres/assets/strategy.png differ
diff --git a/docs/Entregas/Tres/participacoes.md b/docs/Entregas/Tres/participacoes.md
index 15ade2e1..2181a86b 100644
--- a/docs/Entregas/Tres/participacoes.md
+++ b/docs/Entregas/Tres/participacoes.md
@@ -20,6 +20,7 @@ Para a realização do trabalho em grupo foram utilizados os aplicativos Discord
| [DAS de implementação]( ) | Ana e Mylena | Beatriz |
| [DAS de processo]( ) | Beatriz e Gabriel | Mylena e Ana |
| [Data view]( ) | Augusto | Guilherme |
+| [DAS Logica]( ) | Samuel Sato , Augusto, Beatriz | Augusto, Beatriz,Samuel |
Tabela 1. Contribuição dos membros para a entrega de diagramas estáticos. Fonte: Autores.
diff --git a/docs/Entregas/Tres/processos.md b/docs/Entregas/Tres/processos.md
index 195f9d7d..8d157b65 100644
--- a/docs/Entregas/Tres/processos.md
+++ b/docs/Entregas/Tres/processos.md
@@ -8,15 +8,17 @@ Essa visão pode abranger os fluxos de trabalho, que representam a ordem lógica
## Metodologia
-Durante a fase de modelagem, nossa equipe desenvolveu tanto o diagrama de sequência quanto o diagrama de atividades. Ao criar a documentação da visão de processos, utilizamos esses diagramas como base, mas fizemos algumas modificações e aprimoramentos para melhor atender às nossas necessidades e proporcionar uma representação mais clara e eficaz.
+Durante a fase de modelagem, nossa equipe desenvolveu tanto o diagrama de sequência quanto o diagrama de atividades. Ao criar a documentação da visão de processos, utilizamos esses diagramas como base.
+
+O **diagrama de processos**, ultimo diagrama do documento, foi feito levando em consideração diagrama de atividades e sequência.
Para a criação dos diagramas, foi utilizado o site [LucidChart](https://www.lucidchart.com/), que é uma ferramenta online para criação de diagramas.
## Diagramas
-### Diagrama de Sequência
+## Diagrama de Sequência
-O diagrama de sequência é um diagrama de interação que mostra como os processos operam com um foco em sequência. Ele mostra objetos, classes e componentes envolvidos nas operações e a sequência de mensagens trocadas entre os objetos necessários para realizar a funcionalidade da operação. [4]
+O diagrama de sequência é um diagrama de interação que mostra como os processos operam com um foco em sequência. Ele mostra objetos, classes e componentes envolvidos nas operações e a sequência de mensagens trocadas entre os objetos necessários para realizar a funcionalidade da operação.
@@ -48,6 +50,12 @@ Afim de especificar melhor os processos de gestão do grupo, cadastro de usuario
Diagrama de Atividades - Compra: Versão 2.0 (Fonte: Autores, 2023).
+## Diagrama de Processo - Principal
+
+
+
+ Diagrama de Processos(Fonte: Autores, 2023).
+
## Bibliografia
> [1] AULA - ARQUITETURA & DAS – PARTE II. Serrano, Milene. Disponível em: [Aprender3](https://aprender3.unb.br/pluginfile.php/2649469/mod_label/intro/Arquitetura%20e%20Desenho%20de%20Software%20-%20Aula%20Arquitetura%20e%20DAS%20-%20Parte%20II%20-%20Profa.%20Milene.pdf). Acesso em: 25 nov 2023.
@@ -77,5 +85,6 @@ Model of Software Architecture. Disponível em: [cs.ubc.ca](https://www.cs.ubc.c
| `1.0` | 25/11/2023 | Criação do documento | Beatriz e Gabriel | Mylena e Ana |
| `1.1` | 25/11/2023 | Adição da V.2 do Diagrama de Sequência | Beatriz e Gabriel | Mylena e Ana |
| `1.2` | 25/11/2023 | Adição da V.2 dos Diagramas de Atividades | Beatriz e Gabriel | Mylena e Ana |
+| `1.3` | 01/12/2023 | Adição do Diagrama de Processos | Beatriz | Ana |
diff --git a/src/store/services.py b/src/store/services.py
index 4b136661..27b7b69d 100644
--- a/src/store/services.py
+++ b/src/store/services.py
@@ -1,21 +1,35 @@
+from abc import abstractmethod
from authuser.models import User
from store.models import *
+from typing import Protocol
-class CartService():
- def hasAccess(self, request):
- try:
- return User.objects.get(id=request.user.id)
- except:
- raise Exception('You must be logged in')
+from django.core.exceptions import ObjectDoesNotExist
+class CartServiceProtocol(Protocol):
+ @abstractmethod
+ def get_cart(self, user: User) -> Cart:
+ raise NotImplementedError
+
+ @abstractmethod
+ def add_product(self, user: User, product: Product, quantity: int):
+ raise NotImplementedError
+
+ @abstractmethod
+ def get_products(self, user: User) -> list[CartProduct]:
+ raise NotImplementedError
+
+ @abstractmethod
+ def create_order(self, user: User) -> Order:
+ raise NotImplementedError
+
+class CartService(CartServiceProtocol):
def get_cart(self, user: User) -> Cart:
cart, _ = Cart.objects.get_or_create(belongs_to=user)
return cart
- def get_products_in_cart(self, cart: Cart):
- return CartProduct.objects.filter(cart=cart)
+ def add_product(self, user: User, product: Product, quantity: int):
+ cart = self.get_cart(user)
- def add_product_to_cart(self, cart: Cart, product: Product, quantity: int):
cart_product, _ = CartProduct.objects.get_or_create(
cart=cart,
product__pk=product.pk,
@@ -25,16 +39,12 @@ def add_product_to_cart(self, cart: Cart, product: Product, quantity: int):
cart_product.quantity += quantity
cart_product.save()
- def getCart(self, request):
- try:
- user = self.hasAccess(request)
- cart = Cart.objects.get(belongs_to=user)
- return {'Cart':cart,'User':user}
- except Exception as e:
- raise Exception(e)
-
- def create_order_from_cart(self, user: User) -> Order:
- cart = Cart.objects.get(belongs_to=user)
+ def get_products(self, user: User) -> list[CartProduct]:
+ cart = self.get_cart(user)
+ return list(CartProduct.objects.filter(cart=cart))
+
+ def create_order(self, user: User) -> Order:
+ cart = self.get_cart(user)
products_in_cart = cart.products.all()
if len(products_in_cart) == 0:
@@ -44,3 +54,67 @@ def create_order_from_cart(self, user: User) -> Order:
order.products.set(products_in_cart)
return order
+
+
+class CartServiceProxy(CartServiceProtocol):
+ _service: CartService
+
+ def __init__(self, service: CartService) -> None:
+ self._service = service
+
+ def get_cart(self, user: User) -> Cart:
+ self._check_access(user)
+ return self._service.get_cart(user)
+
+ def add_product(self, user: User, product: Product, quantity: int):
+ self._check_access(user)
+ return self._service.add_product(user, product, quantity)
+
+ def get_products(self, user: User) -> list[CartProduct]:
+ self._check_access(user)
+ return self._service.get_products(user)
+
+ def create_order(self, user: User) -> Order:
+ self._check_access(user)
+ return self._service.create_order(user)
+
+ def _check_access(self, user: User):
+ try:
+ User.objects.get(pk=user.pk)
+ except ObjectDoesNotExist:
+ raise ValueError("You must be authenticated")
+
+# No python não existem Interfaces, e sim Protocolos. Funcionalmente, elas são
+# iguais. No entanto, como o Python é uma linguagem dinamicamente tipada, não
+# existe check em tempo de compilação para garantir que o protocolo está implementado
+# corretamente. Ferramentas como MyPy podem ser usadas para obter essa garantia.
+class PaymentStrategy(Protocol):
+ @abstractmethod
+ def pay(self, payment_method: PaymentMethod, order: Order) -> bool:
+ raise NotImplementedError
+
+
+class CreditCardPaymentStrategy(PaymentStrategy):
+ def pay(self, payment_method: CreditCardPaymentMethod, order: Order) -> bool:
+ # Interação com serviço externo de pagamento aqui.
+
+ return True # ou False, caso o pagamento falhe
+
+# Demais Strategies poderiam ser implementadas aqui.
+# PixPaymentStrategy, TicketPaymentStrategy,
+# GiftCardPaymentStrategy, BoletoPaymentStrategy
+
+class PaymentStrategyFactory:
+ _strategies: dict[str, PaymentStrategy]
+
+ def __init__(self) -> None:
+ self._strategies[CreditCardPaymentMethod.__class__.__name__] = CreditCardPaymentStrategy()
+ # Inicialização das demais strategies aqui.
+
+ def get_instance(self, payment_method: PaymentMethod) -> PaymentStrategy:
+ strategy = self._strategies.get(payment_method.__class__.__name__)
+
+ if strategy is None:
+ raise ValueError(f"There is no payment strategy for {payment_method.__class__.__name__}")
+
+ return strategy
diff --git a/src/store/urls.py b/src/store/urls.py
index 231b46b6..b8d2c714 100644
--- a/src/store/urls.py
+++ b/src/store/urls.py
@@ -5,6 +5,5 @@
urlpatterns = [
path('', index, name="index"),
path('product/', product, name="product"),
- path('payment/', payment, name="payment"),
path('cart/', CartView.as_view() , name="cart")
]
diff --git a/src/store/views.py b/src/store/views.py
index 7358d090..baac26c3 100644
--- a/src/store/views.py
+++ b/src/store/views.py
@@ -2,33 +2,26 @@
from django.shortcuts import render, redirect
from django.views import View
-from store.services import CartService
-from store.models import CartProduct, Product
+from store.services import CartService, CartServiceProxy
+from store.models import Product
+
+cart_service = CartService()
+cart_service_proxy = CartServiceProxy(cart_service)
def index(request):
products = Product.objects.all()
return render(request, 'index.html', {'products': products})
-def payment(request):
- return render(request, 'payment/payment.html',{'product':{
- 'name':"carrinho",
- 'image':"src\static\img\images.jpg",
- 'price':100.00,
- 'description':"um carrinho controle remoto",
- 'sold_by':'caua',
- 'amount_in_stock':10
- }})
-
def product(request, id):
product = Product.objects.get(id=id)
return render(request, 'products/product.html', {'product': product})
class CartView(LoginRequiredMixin, View):
- cart_service = CartService()
+ cart_service = CartServiceProxy(CartService())
def get(self, request):
cart = self.cart_service.get_cart(request.user)
- products = self.cart_service.get_products_in_cart(cart)
+ products = self.cart_service.get_products(request.user)
context = {'cart': cart, 'products': products}
return render(request, 'products/cart.html', context)
@@ -37,8 +30,7 @@ def post(self, request):
amount = int(request.POST['amount'])
product = Product.objects.get(pk=product_id)
- cart = self.cart_service.get_cart(request.user)
- self.cart_service.add_product_to_cart(cart, product, amount)
+ self.cart_service.add_product(request.user, product, amount)
return redirect('cart')