DEV Community: William Koller

O que é um ArrayList?

William Koller — Tue, 18 Mar 2025 16:47:31 +0000

O ArrayList é uma estrutura de dados baseada em arrays que permite adicionar, remover e acessar elementos de forma eficiente. Diferente dos arrays tradicionais, o ArrayList cresce dinamicamente conforme novos elementos são adicionados.

Implementação do ArrayList em TypeScript

Abaixo está a implementação completa de um ArrayList genérico em TypeScript:

export class ArrayList<T> {
  private items: T[];
  private map: Map<string, T>;

  constructor(initialCapacity: number = 0) {
    this.items = new Array<T>(initialCapacity);
    this.map = new Map<string, T>();
  }

  add(element: T): void {
    this.items.push(element);
  }

  addAll(elements: T[]): void {
    this.items.push(...elements);
  }

  get(index: number): T | undefined {
    if (index < 0 || index >= this.items.length) {
      throw new Error('Index out of bounds');
    }
    return this.items[index];
  }

  set(index: number, element: T): void {
    if (index < 0 || index >= this.items.length) {
      throw new Error('Index out of bounds');
    }
    this.items[index] = element;
  }

  remove(index: number): T | undefined {
    if (index < 0 || index >= this.items.length) {
      throw new Error('Index out of bounds');
    }
    return this.items.splice(index, 1)[0];
  }

  removeElement(element: T): boolean {
    const index = this.items.indexOf(element);
    if (index !== -1) {
      this.items.splice(index, 1);
      return true;
    }
    return false;
  }

  size(): number {
    return this.items.length;
  }

  isEmpty(): boolean {
    return this.items.length === 0;
  }

  contains(element: T): boolean {
    return this.items.includes(element);
  }

  clear(): void {
    this.items = [];
  }

  toArray(): T[] {
    return [...this.items];
  }

  indexOf(element: T): number {
    return this.items.indexOf(element);
  }

  lastIndexOf(element: T): number {
    return this.items.lastIndexOf(element);
  }

  subList(fromIndex: number, toIndex: number): T[] {
    if (fromIndex < 0 || toIndex > this.items.length || fromIndex > toIndex) {
      throw new Error('Index out of bounds');
    }
    return this.items.slice(fromIndex, toIndex);
  }

  forEach(callback: (element: T, index: number) => void): void {
    this.items.forEach(callback);
  }

  sort(compareFn?: (a: T, b: T) => number): void {
    this.items.sort(compareFn);
  }

  setKeyValue(key: string, value: T): void {
    this.map.set(key, value);
  }

  getValue(key: string): T | undefined {
    return this.map.get(key);
  }

  removeKey(key: string): boolean {
    return this.map.delete(key);
  }

  hasKey(key: string): boolean {
    return this.map.has(key);
  }

  clearMap(): void {
    this.map.clear();
  }

  mapSize(): number {
    return this.map.size;
  }
}

Explicação dos Métodos:

add(element: T): Adiciona um elemento à lista.
addAll(elements: T[]): Adiciona múltiplos elementos de uma vez.
get(index: number): Retorna o elemento em um índice específico.
set(index: number, element: T): Atualiza o elemento em um índice.
remove(index: number): Remove um elemento pelo índice.
removeElement(element: T): Remove um elemento específico.
size(): Retorna o tamanho atual da lista.
isEmpty(): Verifica se a lista está vazia.
contains(element: T): Verifica se um elemento está presente na lista.
clear(): Remove todos os elementos da lista.
toArray(): Retorna a lista como um array.
indexOf(element: T): Retorna o índice da primeira ocorrência do elemento.
lastIndexOf(element: T): Retorna o índice da última ocorrência do elemento.
subList(fromIndex: number, toIndex: number): Retorna uma sublista entre os índices fornecidos.
forEach(callback): Itera sobre os elementos da lista.
sort(compareFn): Ordena os elementos com base em uma função opcional de comparação.

Exemplo de Uso:

const list = new ArrayList<number>();
list.add(10);
list.add(20);
list.add(30);
console.log(list.get(1)); // Saída: 20
list.remove(1);
console.log(list.toArray()); // Saída: [10, 30]

Repo no Github: https://github.com/williamkoller/array-list

Conclusão

Essa implementação do ArrayList em TypeScript oferece uma alternativa flexível para manipular listas dinâmicas de maneira eficiente. O uso de tipagem genérica permite que a lista funcione com qualquer tipo de dado, tornando-a extremamente versátil.

Se gostou do artigo, compartilhe com outros desenvolvedores! 🚀

Ddd Python

William Koller — Sat, 01 Feb 2025 02:45:05 +0000

SOLID - Princípios da Programação Orientada a Objetos (OOP)

William Koller — Thu, 08 Aug 2024 14:35:07 +0000

Princípios de Design

Bons sistemas de software começam com um código limpo. Por um lado, se os tijolos não são bem-feitos, a arquitetura de construção perde a importância. Por outro lado, você pode fazer uma bagunça considerável com tijolos bem-feitos. É aí que entra, os princípios SOLID - Robert C. Martin

Os princípios SOLID orientam a organização das funções e estruturas de dados de uma classe e como essas classes devem ser interconectadas. O uso do termo 'classe' não limita a aplicação dos princípios apenas a softwares orientados a objetos; qualquer agrupamento acoplado de funções e dados em um sistema de software pode se beneficiar deles. O objetivo dos princípios SOLID é criar estruturas de software de nível médio que:

Tolerem mudanças,
Sejam fáceis de entender,
Sirvam como base para componentes reutilizáveis em muitos sistemas de software.

História

A história dos princípios SOLID é extensa. No final dos anos 1980, foram discutidos em reuniões sobre princípios de design com participantes da USENET (um precursor das redes sociais modernas). Ao longo dos anos, os princípios evoluíram: alguns foram eliminados, outros mesclados ou adicionados. O conjunto final se estabilizou no início dos anos 2000, embora a ordem de apresentação tenha variado. Em 2004, Michael Feathers formalizou os princípios em um e-mail, observando que, se Robert C. Martin reorganizasse os princípios, suas iniciais formariam a palavra SOLID - e assim nasceram os princípios SOLID.

Iremos falar cada palavra SOLID, abaixo.

SRP: Princípio de Responsabilidade Única (Single Responsability Principle)

O Princípio de Responsabilidade Única (SRP) afirma que uma classe deve ter apenas uma razão para mudar, ou seja, ela deve ter apenas uma responsabilidade ou tarefa. Isso significa que cada classe deve focar em uma única parte da funcionalidade do software, sendo responsável apenas por uma parte do comportamento do sistema. Isso facilita a manutenção, testes e entendimento do código, além de melhorar a coesão e reduzir o acoplamento entre as partes do sistema.

OCP: O Princípio de Aberto/Fechado (Open/Closed Principle)

O Princípio de Aberto/Fechado (OCP) afirma que uma entidade de software (como uma classe, módulo ou função) deve estar aberta para extensão, mas fechada para modificação. Isso significa que o comportamento de uma classe pode ser estendido sem alterar seu código-fonte original. A ideia é permitir que novas funcionalidades sejam adicionadas ao sistema sem a necessidade de alterar o código existente, reduzindo o risco de introduzir novos bugs e facilitando a manutenção e evolução do software.

LSP: Princípoir de Substituição de Liskov (Liskob Substitution Principle)

O Princípio de Substituição de Liskov (LSP) afirma que uma subclasse deve ser substituível por sua superclasse sem alterar o comportamento desejado do programa. Em outras palavras, objetos de uma classe derivada devem poder ser usados no lugar de objetos da classe base sem que o programa funcione de maneira incorreta. Isso garante que as subclasses preservem a integridade do sistema, respeitando o contrato estabelecido pela superclasse, o que facilita a reutilização e a manutenção do código.

ISP: Princípio de Segregação de Interface (Interface Segregation Principle)

O Princípio de Segregação de Interface (ISP) afirma que uma classe não deve ser obrigada a implementar interfaces que não utiliza. Em vez de ter uma única interface grande, é melhor ter várias interfaces menores e específicas, para que as classes possam implementar apenas o que realmente precisam. Isso reduz o acoplamento entre componentes e aumenta a coesão, facilitando a manutenção e evolução do software.

DIP: Princípio da Inversão de Dependência (Dependency Inversion Principle)

O Princípio da Inversão de Dependência (DIP) afirma que módulos de alto nível não devem depender de módulos de baixo nível, mas ambos devem depender de abstrações. Além disso, abstrações não devem depender de detalhes; os detalhes devem depender de abstrações. Isso significa que a estrutura do código deve ser orientada a interfaces ou classes abstratas, permitindo que a implementação concreta possa ser alterada sem afetar os módulos que utilizam essas abstrações. Isso promove um código mais flexível, reutilizável e de fácil manutenção.

Iremos mostrar uns exemplos em código de cada palavra SOLID, abaixo.

SRP: Princípio de Responsabilidade Única (Single Responsability Principle)

class Order {
  public items: Item[];

  constructor() {
    this.items = [];
  }

  addItem(item: Item) {
    this.items.push(item);
  }

  calculateTotal() {
    let total = 0;
    for (const item of this.items) {
      total += item.price;
    }
    return total;
  }
}

class Item {
  name: string;
  price: number;

  constructor(name: string, price: number) {
    this.name = name;
    this.price = price;
  }
}

class OrderPrinter {
  print(order: Order) {
    console.log('Order Details:');
    for (const item of order.items) {
      console.log(`- ${item.name}: $${item.price}`);
    }
    console.log(`Total: $${order.calculateTotal()}`);
  }
}

const order = new Order();
order.addItem(new Item('Shirt', 20)); // - Shirt: $20

order.addItem(new Item('Pants', 50)); // - Pants: $50

order.addItem(new Item('Shoes', 100)); // - Shoes: $100

order.addItem(new Item('Hat', 10)); // - Hat: $10

const orderPrinter = new OrderPrinter();
orderPrinter.print(order); // Total: $180

O Princípio de Responsabilidade Única (SRP) estabelece que uma classe deve ter apenas uma razão para mudar, ou seja, deve possuir uma única responsabilidade ou tarefa.

Como o código respeita o SRP

Responsabilidade de Gerenciamento de Itens:

A classe Order tem uma responsabilidade clara: gerenciar os itens de um pedido.
O método addItem permite adicionar itens ao pedido. Sua única responsabilidade é modificar a lista de itens (this.items) dentro do objeto Order.

Responsabilidade de Cálculo do Total:

O método calculateTotal é responsável por calcular o total do pedido somando os preços dos itens na lista.
Ele não está alterando o estado do objeto Order, apenas calculando e retornando um valor com base nos itens já existentes.

Ambos os métodos (addItem e calculateTotal) estão diretamente relacionados à principal responsabilidade da classe Order, que é gerenciar os itens do pedido e realizar operações relacionadas a esses itens.
Justificativa de Conformidade com o SRP
Coesão: A classe Order possui alta coesão, já que todos os métodos e propriedades estão diretamente relacionados ao gerenciamento de um pedido.
Facilidade de Mudança: Se houver uma mudança na forma como os itens são gerenciados ou como o total é calculado, essas mudanças serão confinadas a esta única classe. Por exemplo, se a lógica de cálculo do total mudar (por exemplo, descontos ou taxas), apenas o método calculateTotal precisa ser atualizado.
Clareza: A classe Order é fácil de entender porque sua responsabilidade é única e bem definida. Qualquer desenvolvedor pode olhar para essa classe e compreender rapidamente que ela serve para gerenciar itens de um pedido e calcular o total desses itens.

Portanto, a classe Order demonstra uma aplicação clara do Princípio de Responsabilidade Única (SRP), mantendo uma única responsabilidade e tornando o código mais fácil de manter, entender e modificar.

OCP: O Princípio de Aberto/Fechado (Open/Closed Principle)

interface Shape {
  calculateArea(): number;
}

class Rectangle implements Shape {
  private width: number;
  private height: number;

  constructor(width: number, height: number) {
    this.width = width;
    this.height = height;
  }

  calculateArea(): number {
    return this.width * this.height;
  }
}

class Circle implements Shape {
  private radius: number;

  constructor(radius: number) {
    this.radius = radius;
  }

  calculateArea(): number {
    return Math.PI * this.radius * this.radius;
  }
}

class AreaCalculator {
  private shapes: Shape[];

  constructor(shapes: Shape[]) {
    this.shapes = shapes;
  }

  calculateTotalArea(): number {
    let totalArea = 0;
    for (const shape of this.shapes) {
      totalArea += shape.calculateArea();
    }
    return totalArea;
  }
}

const rectangle = new Rectangle(5, 10);
const circle = new Circle(7);

const areaCalculator = new AreaCalculator([rectangle, circle]);
const totalArea = areaCalculator.calculateTotalArea();
console.log("Total area:", totalArea); // Total area: 203.93804002589985T

O Princípio de Aberto/Fechado (OCP) afirma que uma entidade de software deve estar aberta para extensão, mas fechada para modificação. Isso significa que o comportamento de uma classe pode ser estendido sem alterar seu código-fonte original.
Como o código respeita o OCP
Interface Shape:
Define um contrato (calculateArea) que todas as formas (shapes) devem implementar. Isso permite que novas formas possam ser adicionadas sem modificar a interface ou as classes existentes.

Classes Rectangle e Circle:
Ambas implementam a interface Shape, fornecendo suas próprias implementações de calculateArea.
Se quisermos adicionar uma nova forma (por exemplo, Triangle), podemos criar uma nova classe que implemente Shape sem modificar as classes Rectangle ou Circle.

Classe AreaCalculator:
Aceita uma lista de objetos que implementam a interface Shape.
O método calculateTotalArea itera sobre essa lista e calcula a área total chamando calculateArea em cada forma.
Se novas formas forem adicionadas, não é necessário modificar AreaCalculator, pois ela depende da abstração Shape.

Justificativa de Conformidade com o OCP
Extensibilidade: O design permite a adição de novas formas sem modificar o código existente. Para adicionar uma nova forma, basta criar uma nova classe que implemente a interface Shape.
Evita Modificações: O código existente das classes Rectangle, Circle e AreaCalculator permanece inalterado quando novas formas são adicionadas, minimizando o risco de introdução de novos bugs.
Uso de Abstrações: A classe AreaCalculator trabalha com a abstração Shape em vez de classes concretas, promovendo a flexibilidade e aderência ao OCP.

class Triangle implements Shape {
  private base: number;
  private height: number;

  constructor(base: number, height: number) {
    this.base = base;
    this.height = height;
  }

  calculateArea(): number {
    return 0.5 * this.base * this.height;
  }
}

const triangle = new Triangle(10, 5);
const areaCalculatorWithTriangle = new AreaCalculator([rectangle, circle, triangle]);
const newTotalArea = areaCalculatorWithTriangle.calculateTotalArea();
console.log("New total area:", newTotalArea); // Calcula a área total incluindo o triângulo

Como podemos ver, adicionar uma nova forma (Triangle) não requer nenhuma modificação nas classes Rectangle, Circle ou AreaCalculator, demonstrando claramente a aplicação do Princípio de Aberto/Fechado (OCP).

LSP: Princípoir de Substituição de Liskov (Liskob Substitution Principle)

abstract class BaseNotification {
  abstract send(message: string): void;
}

class EmailNotification extends BaseNotification {
  constructor(private emailAddress: string) {
    super();
  }
  send(message: string): void {
    console.log(`Sending email to ${this.emailAddress}: ${message}`);
  }
}

class SMSNotification extends BaseNotification {
  constructor(private phoneNumber: string) {
    super();
  }

  send(message: string): void {
    console.log(`Sending SMS to ${this.phoneNumber}: ${message}`);
  }
}

class PushNotification extends BaseNotification {
  constructor(private deviceToken: string) {
    super();
  }

  send(message: string): void {
    console.log(`Sending push notification to ${this.deviceToken}: ${message}`);
  }
}

function notifyUser(baseNotification: BaseNotification, message: string) {
  baseNotification.send(message);
}

const emailNotification = new EmailNotification('user@example.com');
const smsNotification = new SMSNotification('123-456-7890');
const pushNotification = new PushNotification('device-token-123');

notifyUser(emailNotification, 'Your order has been shipped!'); // Sending email to user@example.com: Your order has been shipped!
notifyUser(smsNotification, 'Your order has been shipped!'); // Sending SMS to 123-456-7890: Your order has been shipped!
notifyUser(pushNotification, 'Your order has been shipped!'); // Sending push notification to device-token-123: Your order has been shipped!

O Princípio de Substituição de Liskov (LSP) afirma que uma subclasse deve ser substituível por sua superclasse sem alterar o comportamento desejado do programa. Em outras palavras, objetos de uma classe derivada devem poder ser usados no lugar de objetos da classe base sem que o programa funcione de maneira incorreta.
Como o código respeita o LSP
Classe Base Abstrata BaseNotification:
Define o método abstrato send, que deve ser implementado por todas as subclasses.
Fornece um contrato comum para todas as notificações, garantindo que qualquer tipo de notificação possa ser enviada usando o método send.

Subclasses EmailNotification, SMSNotification e PushNotification:
Cada uma dessas classes herda de BaseNotification e implementa o método send de forma específica para o tipo de notificação.
Elas podem ser usadas de forma intercambiável no contexto de BaseNotification.

Função notifyUser:
Aceita um objeto de BaseNotification e uma mensagem, chamando o método send do objeto passado.
Como todas as subclasses de BaseNotification implementam send, notifyUser pode aceitar qualquer uma das subclasses sem precisar de modificações.

Justificativa de Conformidade com o LSP
Substituibilidade: A função notifyUser pode receber qualquer instância de BaseNotification, seja ela EmailNotification, SMSNotification ou PushNotification, e chamará o método send sem problemas. Isso demonstra que as subclasses são substituíveis pela superclasse sem alterar o comportamento da função.
Consistência de Comportamento: Cada subclasse implementa o método send de acordo com suas próprias necessidades, mas a interface de uso (BaseNotification) permanece consistente. Isso garante que o comportamento do programa não se altere ao substituir uma instância de BaseNotification por qualquer uma de suas subclasses.
Polimorfismo: O uso de polimorfismo é evidente, pois a função notifyUser não precisa saber qual tipo específico de notificação está sendo enviada. Ela apenas chama send no objeto BaseNotification, confiando que o comportamento adequado será executado pela implementação concreta da subclasse.

Adicionar uma nova forma de notificação, como SlackNotification, é simples e demonstra a conformidade com o LSP:

class SlackNotification extends BaseNotification {
  constructor(private slackChannel: string) {
    super();
  }

  send(message: string): void {
    console.log(`Sending Slack message to ${this.slackChannel}: ${message}`);
  }
}

const slackNotification = new SlackNotification('#general');
notifyUser(slackNotification, 'Your order has been shipped!'); // Sending Slack message to #general: Your order has been shipped!

ISP: Princípio de Segregação de Interface (Interface Segregation Principle)

interface PaymentService {
  processPayment(amount: number): void;
}

class CreditCardPaymentService implements PaymentService {
  processPayment(amount: number): void {
    console.log(`Processando pagamento de R$${amount} com cartão de crédito...`);
  }
}

class BoletoPaymentService implements PaymentService {
  processPayment(amount: number): void {
    console.log(`Processando pagamento de R$${amount} com boleto bancário...`);
  }
}

class Purchase {
  private paymentService: PaymentService;

  constructor(paymentService: PaymentService) {
    this.paymentService = paymentService;
  }

  processPurchase(amount: number): void {
    console.log(`Processando compra de R$${amount}...`);
    this.paymentService.processPayment(amount);
    console.log('Compra concluída!');
  }
}

const creditCardPaymentService = new CreditCardPaymentService(); // Processando pagamento de R$100 com cartão de crédito...
const purchaseWithCreditCard = new Purchase(creditCardPaymentService); // Processando compra de R$100...
purchaseWithCreditCard.processPurchase(100);

const boletoPaymentService = new BoletoPaymentService(); // Processando pagamento de R$200 com boleto bancário...
const purchaseWithBoleto = new Purchase(boletoPaymentService); // Processando compra de R$200...
purchaseWithBoleto.processPurchase(200);

O Princípio de Segregação de Interface (ISP) afirma que uma classe não deve ser obrigada a implementar interfaces que não utiliza. Isso significa que é melhor ter várias interfaces pequenas e específicas do que uma única interface grande e genérica, permitindo que as classes implementem apenas o que realmente precisam.
Como o código respeita o ISP
Interface PaymentService:
Define um contrato específico para o serviço de pagamento com o método processPayment. Esta interface é pequena e focada, contendo apenas o que é necessário para o processamento de pagamentos.
Como a interface é específica para pagamentos, as classes que a implementam não são forçadas a adicionar métodos desnecessários.

Classes CreditCardPaymentService e BoletoPaymentService:
Ambas implementam a interface PaymentService e fornecem sua própria implementação do método processPayment.
Cada classe se concentra exclusivamente em como processar um tipo específico de pagamento (cartão de crédito ou boleto), mantendo a interface e a implementação focadas e coesas.

Classe Purchase:
Recebe uma instância de PaymentService e usa o método processPayment para processar o pagamento.
Não precisa saber ou se preocupar com os detalhes de como o pagamento é processado; isso é abstraído pela interface PaymentService.

Justificativa de Conformidade com o ISP
Interfaces Pequenas e Específicas: A interface PaymentService é pequena e específica, focando apenas no que é necessário para o processamento de pagamentos. As classes CreditCardPaymentService e BoletoPaymentService implementam exatamente o que é exigido pela interface, sem adicionar métodos desnecessários.
Não Forçado a Implementar Métodos Não Usados: As classes que implementam PaymentService não são forçadas a adicionar métodos que não são relevantes para o tipo específico de pagamento que elas processam. Isso evita que as classes se tornem complexas e difíceis de manter.
Flexibilidade e Manutenção: O design permite adicionar novos tipos de serviços de pagamento no futuro (por exemplo, pagamentos via PayPal ou transferência bancária) simplesmente implementando a interface PaymentService. Não há necessidade de modificar a interface ou as classes existentes, mantendo o sistema flexível e fácil de manter.

Exemplo de Extensão
Se quisermos adicionar um novo método de pagamento, como PayPalPaymentService, podemos seguir o mesmo padrão:

class PayPalPaymentService implements PaymentService {
  processPayment(amount: number): void {
    console.log(`Processando pagamento de R$${amount} com PayPal...`);
  }
}

const payPalPaymentService = new PayPalPaymentService();
const purchaseWithPayPal = new Purchase(payPalPaymentService);
purchaseWithPayPal.processPurchase(300); // Processando compra de R$300... Processando pagamento de R$300 com PayPal... Compra concluída!

DIP: Princípio da Inversão de Dependência (Dependency Inversion Principle)

import nodemailer from 'nodemailer';
import { EnvEmail } from './config/env-email';

interface EmailService {
  sendEmail(from: string, to: string, subject: string, body: string): void;
}

class NodemailerEmailService implements EmailService {
  private transporter: nodemailer.Transporter;

  constructor() {
    this.transporter = nodemailer.createTransport({
      service: EnvEmail.SMTP_HOST,
      auth: {
        user: EnvEmail.SMTP_USER,
        pass: EnvEmail.SMTP_PASS,
      },
    });
  }

  async sendEmail(
    from: string,
    to: string,
    subject: string,
    body: string
  ): Promise<void> {
    const mailOptions: nodemailer.SendMailOptions = {
      from,
      to,
      subject,
      text: body,
    };

    try {
      const info = await this.transporter.sendMail(mailOptions);
      console.log('Email sent:', info);
    } catch (error) {
      if (error instanceof Error) {
        console.error('Error sending email:', error.message);
        if (error.message.includes('Authentication')) {
          console.error(
            'Authentication error. Please check your SMTP credentials.'
          );
        } else {
          console.error('Non-critical error occurred. Retrying...');
        }
      } else {
        console.error('Unexpected error sending email:', error);
      }
      throw error;
    }
  }
}

class EmailSender {
  private emailService: EmailService;

  constructor(emailService: EmailService) {
    this.emailService = emailService;
  }

  sendEmail(from: string, to: string, subject: string, body: string): void {
    this.emailService.sendEmail(from, to, subject, body);
  }
}

const emailService = new NodemailerEmailService();
const emailSender = new EmailSender(emailService);

emailSender.sendEmail(
  EnvEmail.SMTP_USER,
  'williamkoller30@gmail.com',
  'Hello',
  'This is a test email'
);

O Princípio da Inversão de Dependência (DIP) afirma que:
Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações.
Abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.
Em termos simples, isso significa que as classes e módulos de alto nível (como lógica de negócios) devem depender de interfaces ou abstrações, e não de implementações concretas. As implementações concretas devem depender dessas abstrações, permitindo que as partes do sistema sejam mais flexíveis e menos acopladas.
Como o código respeita o DIP
Interface EmailService:
Define um contrato para o serviço de envio de emails com o método sendEmail. Isso permite que qualquer classe que implemente essa interface possa ser usada para enviar emails, sem que a classe EmailSender precise saber os detalhes da implementação.

Classe NodemailerEmailService:
Implementa a interface EmailService e usa a biblioteca nodemailer para enviar emails.
Contém detalhes específicos de como o email é enviado, como configuração do transporte e manipulação de erros, mas essas implementações não são conhecidas pela classe EmailSender.

Classe EmailSender:
Depende da abstração EmailService para enviar emails, não de uma implementação concreta. Isso permite que EmailSender use qualquer serviço que implemente EmailService sem modificar seu próprio código.
O construtor de EmailSender recebe uma instância de EmailService, permitindo a injeção de dependências. Isso facilita a troca de implementações concretas (por exemplo, substituindo NodemailerEmailService por um outro serviço de email) sem alterar EmailSender.

Justificativa de Conformidade com o DIP
Dependência de Abstrações: EmailSender depende da abstração EmailService, não de NodemailerEmailService. Isso permite que a classe EmailSender permaneça desacoplada da implementação específica de envio de email.
Flexibilidade e Manutenção: Como EmailSender usa a interface EmailService, podemos substituir NodemailerEmailService por qualquer outra implementação que também implemente EmailService, como um serviço de email baseado em API, sem precisar alterar a lógica de EmailSender.
Injeção de Dependências: A injeção de uma implementação concreta de EmailService no construtor de EmailSender segue o princípio da injeção de dependências, que promove um acoplamento mais solto e uma maior flexibilidade no design do sistema.

Exemplo de Extensão
Para adicionar um novo serviço de email, como SendGridEmailService, que implementa EmailService, seria necessário apenas criar a nova classe:

class SendGridEmailService implements EmailService {
  async sendEmail(
    from: string,
    to: string,
    subject: string,
    body: string
  ): Promise<void> {
    // Implementação usando SendGrid API
    console.log(`Sending email via SendGrid from ${from} to ${to}: ${subject}`);
    // Código para enviar email usando SendGrid API
  }
}

const sendGridEmailService = new SendGridEmailService();
const emailSenderWithSendGrid = new EmailSender(sendGridEmailService);
emailSenderWithSendGrid.sendEmail(
  EnvEmail.SMTP_USER,
  'williamkoller30@gmail.com',
  'Hello',
  'This is a test email via SendGrid'
);

Neste exemplo, SendGridEmailService é uma nova implementação de EmailService, e EmailSender pode utilizá-la sem mudanças no seu código, exemplificando o Princípio da Inversão de Dependência (DIP).

Conclusão

Adotar esses princípios pode transformar significativamente a maneira como você projeta e desenvolve software. Eles não são apenas recomendações teóricas, mas práticas comprovadas que ajudam a criar sistemas que são mais fáceis de entender, modificar e expandir. Ao investir tempo em entender e aplicar SOLID, você não apenas melhora a qualidade do seu código, mas também prepara sua base de código para um futuro mais sustentável e adaptável.

Se você está buscando criar software que se destaca pela sua clareza e robustez, integrar os princípios SOLID em sua prática de desenvolvimento é um passo essencial. Com uma abordagem fundamentada nesses princípios, você estará bem posicionado para construir sistemas que não apenas atendem às necessidades atuais, mas que também se adaptam e evoluem com o tempo.

Referências tiradas do livro Arquitetura Limpa por Robert C. Martin

Repositorio no Github: https://github.com/williamkoller/ts-node-solid-examples

Hoje iremos falar sobre a velocidade em percorrer um elemento em JavaScript

William Koller — Tue, 05 Dec 2023 12:45:54 +0000

Quando precisamos buscar uma lista de elementos em JavaScript sempre usamos .find(), mas o .find() usa o paradigma declarativo ou seja o paradigma declarativo em JavaScript se refere a uma abordagem de programação na qual você descreve o que deseja alcançar e deixa a linguagem cuidar da implementação dos detalhes.

Exemplo:

const numbers = [10, 20, 30, 40, 50];

  function findGreaterThan30(element) {
    return element > 30;
  }

  const result = numbers.find(findGreaterThan30);

  console.log(result); // 40

No paradigma imperativo em JavaScript, você fornece instruções detalhadas sobre como realizar uma tarefa. Nesse estilo de programação, você se concentra em especificar passo a passo como um programa deve executar as ações desejadas.

Examplo:

const numbers = [10, 20, 30, 40, 50];
  let result;

  function findGreaterThan30Imperative(array) {
    for (let i of Object.keys(array)) {
      if (array[i] > 30) {
        result = array[i];
        break;
      }
    }
  }

  findGreaterThan30Imperative(numbers);

  console.log(result); // 40

Ambos trazem o mesmo resultado, mas qual sera o mais rapido.

Vamos passar para duas functions uma declarative() e a outra imperative()

Exemplo:

function declarative() {
  console.time('declarative');

  const numbers = [10, 20, 30, 40, 50];

  function findGreaterThan30(element) {
    return element > 30;
  }

  const result = numbers.find(findGreaterThan30);

  console.log(result); // 40

  console.timeEnd('declarative');
}

declarative();

function imperative() {
  console.time('imperative');

  const numbers = [10, 20, 30, 40, 50];
  let result;

  function findGreaterThan30Imperative(array) {
    for (let i of Object.keys(array)) {
      if (array[i] > 30) {
        result = array[i];
        break;
      }
    }
  }

  findGreaterThan30Imperative(numbers);

  console.log(result); // 40
  console.timeEnd('imperative');
}

imperative();

Executando e olhe a diferença:

Espero ter ajudado <3 e cuidado ao usar .find() em JavaScript.

Assinatura de commits

William Koller — Fri, 17 Jun 2022 22:42:42 +0000

Como conseguimos garantir que somos nós mesmos que fazemos os commits?!

Qualquer pessoa pode alterar a configuração do git, colocar seu e-mail e dizer que foi você que subiu aquele commit.

Para assinar commits, iremos ver o GNUPG.

Nesse link: gnupg vemos que GNUPG é The GNU Privacy Guard.

É uma implementação completa e gratuita do padrão OpenPGP conforme definido pelo RFC4880 (também conhecido como PGP. O GnuPG permite criptografar e assinar dados e comunicações; possui um sistema de gerenciamento de chaves versátil, juntamente com módulos de acesso para todos os tipos de diretórios de chaves públicas. GnuPG, também conhecido como GPG, é uma ferramenta de linha de comando com recursos para facilitar a integração com outros aplicativos. O GnuPG também oferece suporte para S/MIME e Secure Shell (ssh).

Instalação no linux

sudo apt update 
sudo apt install gnupg

Iremos verificar se existe alguma chave criada no nosso computador.

gpg --list-secret-key --keyid-form LONG

Vamos criar a nossa chave

gpg --full-generate-key

Selecionamos (1) para usarmos RSA
4096 bits long
y
quanto tempo quer que seja valido a chave: 1y
y
Real name: seu nome Email address: seuemail@mail.com
selecionar O para salvar e sair.
criar uma senha no seu computador para ter acesso a chave.

Iremos verificar a chave criada.

gpg --list-secret-key --keyid-form LONG

Com esse retorno:

sec   rsa4096/1F64329A378F71EE 2022-06-17 [SC] [expires: 2023-06-17]
      8EF31698FB71ACAC945C4A3E1F64329A378F71EE
uid                 [ultimate] William Koller <williamkoller404@gmail.com>
ssb   rsa4096/43D2BB51F0668C4B 2022-06-17 [E] [expires: 2023-06-17]

Iremos copiar o sec => 1F64329A378F71EE que é o id para pegarmos a chave publica e adicionar no github.

 gpg --armor --export 1F64329A378F71EE

Pegamos a chave e adicionamos no github em GPG Keys

Agora iremos configurar o git para assinar commit e tags

git config --global commit.gpgsign true
git config --global tag.gpgSign true

Criei esse projeto no github para exemplificar

Precisamos adicionar a nossa chave no git

git config --global user.signingkey 1F64329A378F71EE

Quando formos commitar irá aparece essa tela para confirmamos a senha

Agora iremos verificar se o git esta vinculado ao nosso commit

git log --show-signature -1

Vamos no repositorio verificar se o usuário está verificado, clicamos hash do commit.

Ultimo passo

sudo nano ~/.gnupg/gpg.conf

E adicionar use-agent e salvar e em seguida roda esse comandogpgconf --launch gpg-agent

Pronto agora temos a verificação de assinatura de commits.

Espero ter ajudado.

Como criar um projeto com Nestjs do zero com deploy no Heroku usando Github Actions

William Koller — Sat, 04 Jun 2022 16:29:42 +0000

Ola devs e devas!

Porque iremos usar Nestjs?!
Nestjs é um framework Nodejs que conseguimos escalar muito rapidamente usando POO e é meu framework favorito.

Em primeiro lugar precisa ter instalados node e o cli do nestjs, para instalarmos o cli rodamos esse comando npm i -g @nesjs/cli

Agora iremos criar o projeto com cli do nest: nest new api-example-dev.to-ci-cd

O cli do nest é muito poderoso e cria toda uma estrutura inicial para nós.

Para acessar digitaremos: cd api-example-dev.to-ci-cd && code .

Essa é a estrutura de pasta que temos:

Agora iremos rodar o projeto com o comando: yarn start:dev

Aplicação de pé:

Agora iremos criar o projeto no heroku:

Antes disso, precisamos instalar o cli do heroku e fazer o login:

sudo snap install heroku --classic
heroku login

Iremos adicionar o remote do heroku no nosso projeto: heroku git:remote -a api-example-dev-to-ci-cd

Agora criaremos o arquivo Procfile que sera lido pelo heroku na hora que fizermos o push:

Procfile:

web: npm run start:prod

Agora iremos preparar para fazer o push:

git add .
git commit -m "chore: add setup"
git push heroku main

Iremos criar o nosso projeto no Github:

Precisamos adicionar a porta do projeto no heroku:

Iremos acessar a nossa aplicação:

Tudo ok com nossa aplicação, agora iremos implementar nosso CI/CD para automatizar nossos deploy.

Criaremos o arquivo ci-cd.yml:

name: 'CI/CD'

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  continuous-integration:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x]

    steps:
      - uses: actions/checkout@v2

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}

      - name: Install dependencies
        run: yarn install

  continuos-delivery:
    runs-on: ubuntu-latest

    needs: [continuous-integration]

    steps:
      - uses: actions/checkout@v2

      - name: Deploy to heroku
        if: ${{ github.ref == 'refs/heads/master' || github.ref == 'refs/heads/main'}}
        uses: akhileshns/heroku-deploy@v3.12.12
        with:
          heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
          heroku_app_name: ${{ secrets.HEROKU_APP_NAME }}
          heroku_email: ${{ secrets.HEROKU_EMAIL }}

Agora iremos adicionar as secrets no Github:

Iremos preparar para fazer o push, mas agora no github:

git add .
git commit -m "chore: add ci/cd workflow"
git push origin main

Rodando o Actions:

Agora iremos mudar o retorno para vermos o CI/CD funcionando:

export class AppService {
  getHello(): { message: string } {
    return {
      message: `welcome to the @dev.to example api with CI/CD Heroku`,
    };
  }
}

Precisamos alterar o retorno na nossa controller também:

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get()
  getHello(): { message: string } {
    return this.appService.getHello();
  }
}

Preparando o push:

git add .
git commit -m "feat: add new return"
git push origen main

Rodando a Action com a nova alteração:

Iremos acessar a aplicação novamente:

Pronto, implementamos CI/CD no Github Actions com deploy no Heroku

Rest e seus níveis de maturidade

William Koller — Mon, 23 May 2022 19:36:22 +0000

O que sabemos sobre Rest:

Muitos desenvolvedores "já sabem trabalhar com REST";
Representational state of transfer (Transferência Representacional de Estado);
surgiu em 2000 por Ray Fielding em uma dissertação de doutorado;
Simplicidade;
Stateless (sem guardar estado);
Cacheável;

REST: Níveis de maturidade (Richardson Maturity Model)

Nível 0 - POX:

Nível 0 de maturidade significa que uma determinada aplicação não utilizou os recursos de URI, métodos HTTP e Hypermedia (HATEOAS);

Iremos notar que nesse exemplo modelo mais comum, faz uso apenas de verbos POST e GET:

POST - http://localhost:3005/products/saveProduct

GET - http://localhost:3005/products/getProduct/628bd53ff6a8e68c40859468

Logo... nada a ver com REST e muito distante de RESTful.

Nível 1 - Recursos:

Nível 1 de maturidade considera a utilização eficiente de URIs. Os recursos são mapeados, porém não empregam com eficiência o uso dos verbos.

Nível 2 - VERBOS HTTP (HTTP VERBS):

Nível 2 de maturidade considera o uso eficiente de URIs e verbos HTTP.

Nesse nível, a API suporta os seguintes verbos HTTP:

– HTTP POST: utilizado para criar registro em banco de dados;

– HTTP GET: utilizado para a leitura de registros em banco de dados;

– HTTP PUT: utilizado para atualizar um determinado registro em banco de dados;

– HTTP PATCH: utilizado para atualizar parte de um determinado registro em banco de dados.

Exemplo:

POST /products
{
 name: "Notebook Samsung Book Np550 Celeron"
 description: "4gb 500gb 15.6 W11 Cinza"
}

HTTP/1.1 201 Created
Location: /products/628bda5a314e825e8965e05a

Nível 3 - HATEOAS:

Nível 3 conhecido por Hypermedia as the Engine of Application State, Roy Fielding descreve HATEOAS como uma das premissas necessárias para considerar um API RESTful.

Exemplo:

Referências:

Código de exemplo: https://github.com/williamkoller/rest-example-with-nestjs

Espero ter ajudado <3;

Como evitar SQL Injection no MongoDB

William Koller — Tue, 26 Apr 2022 01:09:27 +0000

O que é SQL Injection?

SQL Injection é um ataque no qual código malicioso é passado para um servidor SQL, que o executa. O ataque pode resultar em acesso não autorizado a dados confidenciais, ou destruição de dados críticos.

Como saber se uma query não previne SQL Injection?!

Neste exemplo estou usando CodeQL, o que é CodeQL?!

É um mecanismo de análise de código que descobre vulnerabilidades.

Nesse exemplo na aba de security do github:

O code sacanner nos avisa, que se uma consulta de banco de dados (como uma consulta SQL ou NoSQL) for criada a partir de dados fornecidos pelo usuário sem higienização suficiente, um usuário mal-intencionado poderá executar consultas de banco de dados mal-intencionadas.

Como recomendação para queries NoSQL, podemos usar um operador como $eq do MongoDB

Iremos fazer um refactor no UsersRepository para evitar SQL Injection:

Depois de rodar o Github Actions, notamos que não tem mais alerta na aba de security no github:

E assim não temos mais alerta de SQL Injection;

Repo de exemplo:

https://github.com/williamkoller/my-readings

Espero ter te ajudado de alguma maneira, pode comentar e compartilhar.

Como remover dados duplicados em go

William Koller — Fri, 15 Apr 2022 02:03:42 +0000

Ola devs e devas

Iremos usar de exemplo um slice de int para passarmos dados duplicados nele.

Criaremos um arquivo main.go de exemplo

Esse é o retorno:

intSliceValues [1 2 3 3 4 4 5 6 7 8 9 9 9]

Agora iremos criar uma function para remover os dados duplicados

E agora no main, ficaria assim:

O retorno:

intSliceValues [1 2 3 3 4 4 5 6 7 8 9 9 9] uniqueSlice [1 2 3 4 5 6 7 8 9]

Conclusão:

A partir da função main, declaramos um slice. Também imprimimos o valor original da slice.
Definimos uma função onde estamos passando os valores originais do slice e verificando as duplicatas.
Lógica para verificação de duplicatas: Para isso definimos outra slice e atribuindo os primeiros valores verificando se o valor já existe na novo slice ou não. Ele retorna o slice sem duplicatas.
Estamos chamando a função removeDuplicate da função principal onde o slice de retorno da função é impressa.

Espeor ter ajudado.

Como trabalhar com Switch no Golang

William Koller — Sat, 02 Apr 2022 21:51:12 +0000

Ola devs e devas.

Para ilustrar esses exemplos de switch em golang, iremos usar como exemplo dia da semana.

Esse primeiro exemplo iremos definir uma function para obtermos a resposta do dia da semana:

Nesse exemplo iremos usar o switch com o fallthrough;
O que seria a palavra-chave fallthrough é usada na instrução switch em golang. Esta palavra-chave é usada no bloco switch case. Se a palavra-chave de fallthrough estiver presente no bloco case, ela transferirá o controle para o próximo caso, mesmo que o caso atual possa ter correspondência:

Nesse exemplo iremos definir uma variavel com inferencia de tipo var dayWeek string:

Nesse exemplo podemos utilizar o switch desta maneira:

Para executarmos cada exemplo, ficaria assim:

E como respostas, ficaria assim:

go run main.go

Um ponto importante, no caso do golang nao precisamos usar o palavra-chave break apos o retorno do case. Pois o go ja faz isso automaticamente.

Notamos que podemos usar os 4 exemplos diferentes de switch em go.

Espero ter ajudado.

Como trabalhar com Loop no Dart

William Koller — Thu, 17 Feb 2022 18:17:09 +0000

Iremos iniciar uma lista

var list = [1, 2, 3, 4, 5, 6];

Utilizando o método forEach

list.forEach((element) {
  print(element);
});

Utilizando for Loop

for (int i = 0; i < list.length; i++) {
  var e = list[i];
  print(e);
}

Utilizando for in Loop

for (var e in <List>[list]) {
  print(e);
}

Utilizando while Loop

var i = 0;
while (i < list.length) {
  print(list[i]);
  i++;
}

Repo:

loop-dart

Primeiros passos em Dart, como instalar Dart SDK no Linux e compilar Hello World!!

William Koller — Thu, 17 Feb 2022 12:13:12 +0000

Como instalar Dart SDK no Linux

Instalar usando apt-get:



sudo apt-get update
sudo apt-get install apt-transport-https
sudo sh -c 'wget -qO- https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -'
sudo sh -c 'wget -qO- https://storage.googleapis.com/download.dartlang.org/linux/debian/dart_stable.list > /etc/apt/sources.list.d/dart_stable.list'

Em seguida instalar Dart SDK:



sudo apt-get update
sudo apt-get install dart

Verificar a versão instalada:

dart --version

Como compilar Hello World em Dart:

Criar arquivo com extensao .dart

touch hello_world.dart

Criando Hello World em Dart:



void main() {
  print("Hello, world");
}

Como compilar o arquivo hello_world.dart

dart run hello_world.dart

Conclusão:

Simples de compilar dart.