Thanks for the idea, Miranda. I'll add it to my backlog.

Исправил, спасибо!

Hello Mahendra,

The main purpose of interfaces is to establish a "contract" between parts of your program—it's the way for client code to say "In this method I need any objects which can do this, this and that (described in interface). I don't really care about the class of that object, as long as it does what I need."

Let's see how this can be helpful using the analogy from real life:

You inherited a bar from your grandpa. There works a bartender named Joe. Some day Joe got drunk on the job and you decided to fire him. But there's a gotcha, only Joe knows how to handle the bar. You don't know how to replace him, because you don't know what potential candidate should be capable of doing.

So, your bar (client code) is coupled to the concrete class (Joe). In such case, you could only replace Joe with his son (subclass), who used to help Joe before and learned the ropes. But he's alcoholic too (inherited the behavior from Joe), so you have to think of something else.

Finally, you asked around and managed to write a job description for a bartender position (created the interface). And suddenly it seems that you can fill the position with anyone, who's capable of doing things listed in that document—be that experienced bartender or a part-time student.

Irony aside, here's how I decide whether or not I need an interface in particular situation:

• Would I need to replace this class in some client code with some other class in the future?
• Or do I have to provide some extension point for other people using this code, so that they could pass their own classes instead of default one?

If the answer is yes (for any of above), I create the interface and link the client code to the interface rather to a concrete class.

If the answer is no, I don't create interface and tie the code to a class. But even if in the future it turns out that I actually need some flexibility, I can use the Extract Interface refactoring to create a common interface.

Please note, that like any real life contract, interfaces create the burden of bureaucracy. Plus, the complexity: you create several entities (interface + class) instead of just one (a class). That's why I would not suggest creating interfaces for each class in the program.

Hope this makes sense!

Да, действительно, там была опечатка. Спасибо, исправил.

Hey Mahendra,

Nice question! Here's what I think:

1. You need a class anyway, since you have to put the extracted method body somewhere. You can not put it inside interface, right?

2. You can always extract interface from a resulting class later (see Extract Interface refactoring).

Добрый день.

Хороший вопрос, спасибо. Мне кажется, что новичку курс будет полезен, особенно секция с запахами плохого кода, т.к. обычно первый год в профессии люди только такой код и пишут.

Думаю, для себя это легче всего это понять полистав каталог рефакторинга, доступный на сайте. Если вы понимаете о чем там идёт речь, то я думаю, что курс будет вам полезен. В крайнем случае, вы всегда можете поросить возврат денег, если поймете, что материал для вас слишком сложный.

С уважением,

Александр Швец

Hey Nastasia,

Great question! I think they both could act as an intermediate step to a cleaner code. Here's example:

1. You have a Primitive obsession situation(say, lots of arrays). It smells bad.

2. You turn arrays into classes.

3. Now you have a lot of Data classes. Smells better, but not that good yet.

4. You add some behaviors to data classes, and merge them together if both have similar purpose.

5. Bam! Now, you've got clean code and nice classes.

Does this make sense?

Спасибо за отзыв, Максим. Хорошая идея с тёмной темой, добавлю в список задач.

Hi, Prachi!

You should always try to do just one change at time. Yes, sometimes you could cut a corner and do several small refactorings at once. But each time you do it, you're risking making an error, since your focus is spread through all the places you changed.

Here's a metaphor. Imagine a surgery operation, where a surgeon is going to cut a person's appendix. But in the process, surgeon discovers a cancer tumor and thinks "hey, I'll gonna cut this stuff as well while I'm here". And then patient dies and nobody knows whether it was because appendix or cancer.

Hope this helps!

Спасибо, поправил! Даже нНе знаю как они просочились через 2 этапа проверок :)