Mario Cervera Profile picture
Jun 5, 2020 3 tweets 1 min read Read on X
📔 The "Interface Segregation Principle" (ISP) says:

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

Some people believe that this does not apply to dynamically typed languages because they don't have interfaces.

But, it applies 👇 1/3

#SolidPrinciples
We can generalize the ISP as:

"Clients should not be forced to depend on things they do not need".

If you create unnecessary dependencies, you increase coupling and you will experience the problems of *too much knowledge*.

Examples 👇 2/3
❓ Have you ever been forced to:

🔹Instantiate a complex net of objects just to run a simple test?
🔹Call two irrelevant functions before the function that interests you?
🔹Pass data into a function that does not use it?

These problems may appear when you *know too much*.
3/3

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Mario Cervera

Mario Cervera Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @macerub

Oct 16, 2021
📅 One year ago, in October 2020, I published my first blog post.

Since then, I've published 8 posts, in topics such as:

- Clean code
- Software testing
- Test-Driven Development (TDD)
- Design patterns
- Refactoring
- Algorithms

This is a thread with links to the 8 posts 🧵👇
❓ What is clean code?

I guess most people would agree that code is clean when it's easy to read and maintain.

But this is a bit shallow.

In this post, I dig deeper, discussing the essence of clean code beyond readability and maintainability.

mariocervera.com/the-essence-of…
❓ Are design patterns still relevant?

In this post, I explain why I believe that the answer to this question is 'yes'.

mariocervera.com/are-design-pat…
Read 9 tweets
Sep 29, 2021
📚 I've read many technical books during my career as a software engineer.

So, people often ask me for book recommendations.

This is a thread about the most common recommendations that I give (grouped in 5 knowledge areas) 🧵👇
1⃣ Algorithms and Data Structures.

The canonical reference is the CLRS book:

📔 "Introduction to Algorithms".

This book is thick and it contains a lot of algorithm analysis, so it's quite math-heavy.

But it's the best, in my opinion.
If you want something more accessible, you won't waste time reading:

📔 "The Algorithm Design Manual" (by Steven Skiena).

The second part of the book is a gold mine.

It contains a catalog of algorithmic problems that arise commonly in practice.
Read 13 tweets
Jun 22, 2021
During the last year, I've written threads on various topics, such as:

- Clean code.
- Automated testing.
- Software design.
- Algorithms.

🧵 This is a thread with links to the threads that I find more useful 👇
A thread about benefits of automated testing.

Read 10 tweets
Mar 14, 2021
🎨 The Single Responsibility Principle (SRP) says:

"A module should have only one responsibility".

❓ But, what does this mean? What is a responsibility? How do we know if a module has more than one?

Let's find out 🧵👇
Example: the Customer class.

🔹generateInvoice: calculates the amount the customer must pay.

🔹 calculateDiscount: returns a % discount for the customer.

🔹 save: stores the customer in the database.

🔹 toString: returns the customer as a string so it can be added to a report
❓ How many responsibilities does this class have?

To find out, we should ask ourselves:

➡️ Who is the audience for each method?

Or, alternatively:

➡️ Who are the users (actors) of the system that may request changes to these methods?
Read 8 tweets
Nov 14, 2020
❓ What is technical debt?

Technical debt is not poorly written code.

The technical debt metaphor only applies when there is a conscious and strategic decision.

A short thread with examples 🧵👇
Example 1⃣

You write code to reflect your *current* understanding of the problem.

You incur debt when this understanding is *partial* and, even then, you deliver the software (to learn more).

But you must pay the debt: you must incorporate the new learnings into the software.
Example 2⃣

You must meet a tight deadline to get the economic resources needed for a subsequent deadline.

Then, you make the strategic decision to write a suboptimal design for the first deadline.

After that, you pay the debt and improve the design for the second deadline.
Read 4 tweets
Sep 23, 2020
❓ Have you ever wondered what interfaces are for in object-oriented languages?

They are more than a just a class with abstract methods.

They play a key role in many design patterns and principles.

A thread 🧵 about 6 key aspects of interfaces.
1⃣ Interfaces establish knowledge boundaries.

When you call an interface method, you can often ignore what is under the hood.

Example: class 'C' need not know the exact database that stores the data.

🔑 Interfaces reduce complexity because they allow us to separate concerns. Image
2⃣ Interfaces establish architectural boundaries.

The separation in the previous example is also "physical".

You can change the 'Database' module without affecting the 'C' module.

🔑 Interfaces allow us to design systems that are loosely coupled and therefore more testable.
Read 9 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(