Hi! I'm

Federico Calò

Software Developer | Technical Writer

I create modern web applications and custom digital tools to help businesses grow through technological innovation. My passion is combining computer science and economics to generate real value.

Contact Me

About Me

My passion for computer science was born at the Technical Commercial Institute of Maglie, where I discovered the power of programming and the fascination of creating digital solutions. From the start, I understood that computer science was not just code, but an extraordinary tool for turning ideas into reality.

During my studies in Business Information Systems, I began to interweave computer science and economics, understanding how technology can be the engine of growth for any business. This vision accompanied me to the University of Bari, where I obtained my degree in Computer Science, deepening my technical skills and passion for software development.

Today I put this experience at the service of businesses, professionals and startups, creating tailor-made digital solutions that automate processes, optimize resources and open new business opportunities. Because true innovation begins when technology meets the real needs of people.

My Skills

Data Analysis & Predictive Models

I transform data into strategic insights with in-depth analysis and predictive models for informed decisions

Process Automation

I create custom tools that automate repetitive operations and free up time for value-added activities

Custom Systems

I develop tailor-made software systems, from platform integrations to customized dashboards

const federico = {
  nome: "Federico Calò",
  ruolo: "Sviluppatore Software",
  città: "Bari, Italia",
  missione: "Aiutare attraverso l'informatica",
  passioni: [
    "Codice Pulito",
    "Innovazione",
    "Crescita Continua"
  ]
};

La Mia Missione

Credo fermamente che l'informatica sia lo strumento più potente per trasformare le idee in realtà e migliorare la vita delle persone.

Democratizzare la Tecnologia

La mia missione è rendere l'informatica accessibile a tutti: dalle piccole imprese locali alle startup innovative, fino ai professionisti che vogliono digitalizzare la propria attività. Ogni realtà merita di sfruttare le potenzialità del digitale.

Unire Informatica ed Economia

Non è solo questione di scrivere codice: è capire come la tecnologia possa generare valore reale. Intrecciando competenze informatiche e visione economica, aiuto le attività a crescere, ottimizzare processi e raggiungere nuovi traguardi di efficienza e redditività.

Creare Soluzioni su Misura

Ogni attività è unica, e così devono esserlo le soluzioni. Sviluppo strumenti personalizzati che rispondono alle esigenze specifiche di ciascun cliente, automatizzando processi ripetitivi e liberando tempo per ciò che conta davvero: far crescere il business.

Trasforma la Tua Attività con la Tecnologia

Che tu gestisca un negozio, uno studio professionale o un'azienda, posso aiutarti a sfruttare le potenzialità dell'informatica per lavorare meglio, più velocemente e in modo più intelligente.

Parliamone Insieme →

Join the Community

Join the developer community where we discuss software, AI, architecture and DevOps. Share ideas, ask questions and grow with us.

Channel

FC Dev Blog

Get notifications on new articles, complete series, weekly tips and featured tools. Bilingual IT/EN content directly in your Telegram.

New articles as they are published
Weekly tips and code snippets
Polls on future topics

Subscribe to Channel

Group

FC Dev Community

A bilingual IT/EN community for developers. Discussions, Q&A, mutual help and networking with other professionals.

Discussions on articles and technologies
Coding help and code review
Job opportunities and collaboration

Join the Group

Discussion Topics

View

Master SQL

RoadMap.sh

November 2024

View

Oracle Certified Foundations Associate

Oracle

October 2024

View

People Leadership Credential

Connect

September 2024

💻 Languages & Technologies

Java

Python

JavaScript

Angular

React

TypeScript

SQL

PHP

CSS/SCSS

Node.js

Docker

Git

💼

12/2024 - Present

Custom Software Engineering Analyst

Accenture

Bari, Puglia, Italy · Hybrid Analysis and development of computer systems through the use of Java and Quarkus in Health and Public Sector. Continuous training on modern technologies for creating customized and efficient software solutions and on agents.

💼

06/2022 - 12/2024

Software analyst and Back End Developer Associate Consultant

Links Management and Technology SpA

Experience analyzing as-is software systems and ETL flows using PowerCenter. Completed Spring Boot training for developing modern and scalable backend applications. Backend developer specialized in Spring Boot, with experience in database design, analysis, development and testing of assigned tasks.

💼

02/2021 - 10/2021

Software programmer

Adesso.it (prima era WebScience srl)

Experience in AS-IS and TO-BE analysis, SEO evolutions and website evolutions to improve user performance and engagement.

🎓

2018 - 2025

Degree in Computer Science

University of Bari Aldo Moro

Bachelor's degree in Computer Science, focusing on software engineering, algorithms, and modern development practices.

📚

2013 - 2018

Diploma - Corporate Information Systems

Technical Commercial Institute of Maglie

Technical diploma specializing in Business Information Systems, combining IT knowledge with business management.

Contattami

Hai un progetto in mente? Parliamone! Compila il form qui sotto e ti risponderò al più presto.

* Campi obbligatori. I tuoi dati saranno utilizzati solo per rispondere alla tua richiesta.

SOLID Principles: The Foundations of Software Architecture

The SOLID principles are five fundamental guidelines for writing quality object-oriented code. Introduced by Robert C. Martin (Uncle Bob), these principles help create maintainable, extensible, and testable software. SOLID is an acronym representing: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.

🎯 The 5 SOLID Principles

S - Single Responsibility Principle (SRP)
O - Open/Closed Principle (OCP)
L - Liskov Substitution Principle (LSP)
I - Interface Segregation Principle (ISP)
D - Dependency Inversion Principle (DIP)

1. Single Responsibility Principle (SRP)

"A class should have only one reason to change"

Each class must have a single well-defined responsibility. This makes the code easier to understand, test, and modify.

❌ SRP Violation:

class User {{ '{' }}
  constructor(
    public name: string,
    public email: string
  ) {{ '{' }}{{ '}' }}

  // Responsibility 1: Validation
  validateEmail(): boolean {{ '{' }}
    return /\S+@\S+\.\S+/.test(this.email);
  {{ '}' }}

  // Responsibility 2: Persistence
  save(): void {{ '{' }}
    // Save to database
    console.log("Saved to DB");
  {{ '}' }}

  // Responsibility 3: Notifications
  sendWelcomeEmail(): void {{ '{' }}
    console.log(`Email to #123;{ '{' }}this.email{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

✅ Respects SRP:

// One responsibility per class
class User {{ '{' }}
  constructor(
    public name: string,
    public email: string
  ) {{ '{' }}{{ '}' }}
{{ '}' }}

class UserValidator {{ '{' }}
  validateEmail(email: string): boolean {{ '{' }}
    return /\S+@\S+\.\S+/.test(email);
  {{ '}' }}
{{ '}' }}

class UserRepository {{ '{' }}
  save(user: User): void {{ '{' }}
    console.log("Saved to DB");
  {{ '}' }}
{{ '}' }}

class EmailService {{ '{' }}
  sendWelcome(user: User): void {{ '{' }}
    console.log(`Email to #123;{ '{' }}user.email{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

2. Open/Closed Principle (OCP)

"Classes should be open for extension but closed for modification"

You should be able to add new functionality by extending existing code, not modifying it. Use abstractions (interfaces, abstract classes) to allow extensions.

❌ OCP Violation

class DiscountCalculator {{ '{' }}
  calculate(type: string, amount: number): number {{ '{' }}
    // Every new type requires modifying this class!
    if (type === 'student') {{ '{' }}
      return amount * 0.9; // 10% discount
    {{ '}' }} else if (type === 'senior') {{ '{' }}
      return amount * 0.85; // 15% discount
    {{ '}' }} else if (type === 'vip') {{ '{' }}
      return amount * 0.8; // 20% discount
    {{ '}' }}
    return amount;
  {{ '}' }}
{{ '}' }}

✅ Respects OCP

// Interface for extension
interface DiscountStrategy {{ '{' }}
  apply(amount: number): number;
{{ '}' }}

class StudentDiscount implements DiscountStrategy {{ '{' }}
  apply(amount: number): number {{ '{' }}
    return amount * 0.9;
  {{ '}' }}
{{ '}' }}

class SeniorDiscount implements DiscountStrategy {{ '{' }}
  apply(amount: number): number {{ '{' }}
    return amount * 0.85;
  {{ '}' }}
{{ '}' }}

class VIPDiscount implements DiscountStrategy {{ '{' }}
  apply(amount: number): number {{ '{' }}
    return amount * 0.8;
  {{ '}' }}
{{ '}' }}

// Closed for modification, open for extension
class DiscountCalculatorOCP {{ '{' }}
  calculate(strategy: DiscountStrategy, amount: number): number {{ '{' }}
    return strategy.apply(amount);
  {{ '}' }}
{{ '}' }}

// Adding new discount = create new class, not modify existing
const calc = new DiscountCalculatorOCP();
console.log(calc.calculate(new StudentDiscount(), 100)); // 90
console.log(calc.calculate(new VIPDiscount(), 100)); // 80

3. Liskov Substitution Principle (LSP)

"Objects of a subclass must be able to replace objects of the base class without altering the correct behavior of the program"

Subclasses must extend the behavior of the base class, not change it in ways that break expectations.

❌ LSP Violation

class Rectangle {{ '{' }}
  constructor(protected width: number, protected height: number) {{ '{' }}{{ '}' }}

  setWidth(width: number): void {{ '{' }}
    this.width = width;
  {{ '}' }}

  setHeight(height: number): void {{ '{' }}
    this.height = height;
  {{ '}' }}

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

// Violates LSP: Square cannot substitute Rectangle
class Square extends Rectangle {{ '{' }}
  setWidth(width: number): void {{ '{' }}
    this.width = width;
    this.height = width; // Unexpected side effect!
  {{ '}' }}

  setHeight(height: number): void {{ '{' }}
    this.width = height;
    this.height = height; // Unexpected side effect!
  {{ '}' }}
{{ '}' }}

function increaseRectangleWidth(rect: Rectangle): void {{ '{' }}
  rect.setWidth(rect.getArea() + 10);
  // Expectation: only width changes
  // Reality with Square: height also changes!
{{ '}' }}

✅ Respects LSP

// Use composition instead of problematic inheritance
interface Shape {{ '{' }}
  getArea(): number;
{{ '}' }}

class RectangleLSP implements Shape {{ '{' }}
  constructor(private width: number, private height: number) {{ '{' }}{{ '}' }}

  setWidth(width: number): void {{ '{' }}
    this.width = width;
  {{ '}' }}

  setHeight(height: number): void {{ '{' }}
    this.height = height;
  {{ '}' }}

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

class SquareLSP implements Shape {{ '{' }}
  constructor(private side: number) {{ '{' }}{{ '}' }}

  setSide(side: number): void {{ '{' }}
    this.side = side;
  {{ '}' }}

  getArea(): number {{ '{' }}
    return this.side * this.side;
  {{ '}' }}
{{ '}' }}

// Works with any Shape without surprises
function printArea(shape: Shape): void {{ '{' }}
  console.log(`Area: #123;{ '{' }}shape.getArea(){{ '}' }}`);
{{ '}' }}

4. Interface Segregation Principle (ISP)

"Clients should not be forced to depend on interfaces they do not use"

It's better to have small and specific interfaces than large and generic ones. Avoid "fat interfaces" that force classes to implement useless methods.

❌ ISP Violation

// Interface too large
interface Worker {{ '{' }}
  work(): void;
  eat(): void;
  sleep(): void;
{{ '}' }}

class HumanWorker implements Worker {{ '{' }}
  work(): void {{ '{' }} console.log("Working"); {{ '}' }}
  eat(): void {{ '{' }} console.log("Eating"); {{ '}' }}
  sleep(): void {{ '{' }} console.log("Sleeping"); {{ '}' }}
{{ '}' }}

// Robot doesn't eat or sleep, but is forced to implement them!
class RobotWorker implements Worker {{ '{' }}
  work(): void {{ '{' }} console.log("Working"); {{ '}' }}
  eat(): void {{ '{' }} throw new Error("Robot doesn't eat"); {{ '}' }}
  sleep(): void {{ '{' }} throw new Error("Robot doesn't sleep"); {{ '}' }}
{{ '}' }}

✅ Respects ISP

// Segregated interfaces by responsibility
interface Workable {{ '{' }}
  work(): void;
{{ '}' }}

interface Eatable {{ '{' }}
  eat(): void;
{{ '}' }}

interface Sleepable {{ '{' }}
  sleep(): void;
{{ '}' }}

// Human implements all interfaces
class HumanWorkerISP implements Workable, Eatable, Sleepable {{ '{' }}
  work(): void {{ '{' }} console.log("Working"); {{ '}' }}
  eat(): void {{ '{' }} console.log("Eating"); {{ '}' }}
  sleep(): void {{ '{' }} console.log("Sleeping"); {{ '}' }}
{{ '}' }}

// Robot implements only what's needed
class RobotWorkerISP implements Workable {{ '{' }}
  work(): void {{ '{' }} console.log("Working 24/7"); {{ '}' }}
{{ '}' }}

// Specific functions for specific interfaces
function makeWork(worker: Workable): void {{ '{' }}
  worker.work();
{{ '}' }}

function feedWorker(worker: Eatable): void {{ '{' }}
  worker.eat();
{{ '}' }}

const human = new HumanWorkerISP();
const robot = new RobotWorkerISP();

makeWork(human); // OK
makeWork(robot); // OK
feedWorker(human); // OK
// feedWorker(robot); // ❌ Compile-time error: robot is not Eatable

5. Dependency Inversion Principle (DIP)

"Depend on abstractions, not on concrete implementations"

High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces). Abstractions should not depend on details, but details should depend on abstractions.

❌ DIP Violation

// Direct dependency on concrete implementation
class MySQLDatabase {{ '{' }}
  save(data: string): void {{ '{' }}
    console.log(`Saved to MySQL: #123;{ '{' }}data{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

// UserService depends on the concrete MySQLDatabase class
class UserService {{ '{' }}
  private db = new MySQLDatabase(); // Strong coupling!

  createUser(name: string): void {{ '{' }}
    this.db.save(name);
  {{ '}' }}
{{ '}' }}

// Changing database requires modifying UserService

✅ Respects DIP

// Abstraction (interface)
interface Database {{ '{' }}
  save(data: string): void;
{{ '}' }}

// Concrete implementations depend on the abstraction
class MySQLDatabaseDIP implements Database {{ '{' }}
  save(data: string): void {{ '{' }}
    console.log(`Saved to MySQL: #123;{ '{' }}data{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

class MongoDBDatabase implements Database {{ '{' }}
  save(data: string): void {{ '{' }}
    console.log(`Saved to MongoDB: #123;{ '{' }}data{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

class PostgreSQLDatabase implements Database {{ '{' }}
  save(data: string): void {{ '{' }}
    console.log(`Saved to PostgreSQL: #123;{ '{' }}data{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

// UserService depends on the abstraction, not the implementation
class UserServiceDIP {{ '{' }}
  // Dependency Injection: database is injected
  constructor(private db: Database) {{ '{' }}{{ '}' }}

  createUser(name: string): void {{ '{' }}
    this.db.save(name);
  {{ '}' }}
{{ '}' }}

// Easy to change implementation without modifying UserService
const mysqlService = new UserServiceDIP(new MySQLDatabaseDIP());
const mongoService = new UserServiceDIP(new MongoDBDatabase());
const pgService = new UserServiceDIP(new PostgreSQLDatabase());

mysqlService.createUser("Alice"); // MySQL
mongoService.createUser("Bob");   // MongoDB
pgService.createUser("Charlie");  // PostgreSQL

SOLID in Practice: Complete Example

Let's see how to apply all SOLID principles together in a notification system:

SOLID Notification System

// ISP: Segregated interfaces
interface MessageSender {{ '{' }}
  send(message: string, recipient: string): void;
{{ '}' }}

// DIP: Concrete implementations depend on abstraction
class EmailSender implements MessageSender {{ '{' }}
  send(message: string, recipient: string): void {{ '{' }}
    console.log(`📧 Email to #123;{ '{' }}recipient{{ '}' }}: #123;{ '{' }}message{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

class SMSSender implements MessageSender {{ '{' }}
  send(message: string, recipient: string): void {{ '{' }}
    console.log(`📱 SMS to #123;{ '{' }}recipient{{ '}' }}: #123;{ '{' }}message{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

class PushNotificationSender implements MessageSender {{ '{' }}
  send(message: string, recipient: string): void {{ '{' }}
    console.log(`🔔 Push to #123;{ '{' }}recipient{{ '}' }}: #123;{ '{' }}message{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

// SRP: Single responsibility - notification management
class NotificationService {{ '{' }}
  constructor(private sender: MessageSender) {{ '{' }}{{ '}' }} // DIP

  notify(message: string, recipient: string): void {{ '{' }}
    this.sender.send(message, recipient);
  {{ '}' }}
{{ '}' }}

// OCP: Open for extension (new loggers) closed for modification
interface Logger {{ '{' }}
  log(message: string): void;
{{ '}' }}

class ConsoleLogger implements Logger {{ '{' }}
  log(message: string): void {{ '{' }}
    console.log(`[LOG] #123;{ '{' }}message{{ '}' }}`);
  {{ '}' }}
{{ '}' }}

// SRP: Separate responsibility for logging
class NotificationServiceWithLogging {{ '{' }}
  constructor(
    private sender: MessageSender,
    private logger: Logger
  ) {{ '{' }}{{ '}' }}

  notify(message: string, recipient: string): void {{ '{' }}
    this.logger.log(`Sending notification to #123;{ '{' }}recipient{{ '}' }}`);
    this.sender.send(message, recipient);
  {{ '}' }}
{{ '}' }}

// Usage
const emailService = new NotificationServiceWithLogging(
  new EmailSender(),
  new ConsoleLogger()
);

const smsService = new NotificationServiceWithLogging(
  new SMSSender(),
  new ConsoleLogger()
);

emailService.notify("Welcome!", "user@example.com");
smsService.notify("Code: 1234", "+39123456789");

Benefits of SOLID Principles

      ✅ Advantages
      Maintainability: Code easier to understand and modify
Extensibility: Add features without breaking existing code
Testability: Small and focused classes are easier to test
Reusability: Modular reusable components
Flexibility: Change implementations without rewriting everything

    

Conclusion

SOLID principles are not rigid rules but guidelines for writing quality code. Applying them requires practice and judgment: sometimes slightly violating them is acceptable for simplicity. The goal is maintainable, testable, and extensible code, not dogmatically following every principle.

🎯 Key Points

SRP: One class = one responsibility
OCP: Open for extension, closed for modification
LSP: Substitutable subclasses without surprises
ISP: Small and specific interfaces
DIP: Depend on abstractions, not on concretes