When we are going to model an object-oriented system, one of the most important things we should do is assign each type (BE IT interface, class, structure, enumeration or delegate) a set of concepts and responsibilities.

You're making pretty much an interface for every important method of your pets. Virtually every animal sleeps and eats, for example. You could create a single interface to group these features together. This helps a lot to maintain the simple work because:

• if you have to add one more feature to animals, just work in a single interface. You don't have to go to each class and have it implement another new interface;
• if you have to change the signature of some method, you will not have to run through all your animals to see which ones are affected, i.e. it becomes much easier to control who is affected by a change of a specific interface.

Something else, various animal sounds have their own interfaces in their implementation. A more common approach is to have a single method (again, this goes in the general interface for animals). You could call the method "talk"or " speak". Then, if the animal will bark, scream, meow or call the judge to complain of lack is in charge of implementing the method in the class that is to use the inheritance.

Finally, you ask: Okay, I put all the methods together in a single interface called Pet. But what if I have some animal that doesn't use some functionality? For example, a slug would never somersault backwards. In this case, you have several options:

• treat this in an abstract method and give some indication that the slug cannot somersault backwards;
• be a bastard and throw a NotImplementedException ;
• be a double bastard and leave the method empty.

In all cases, document Well what is doing;)

Note that there is no need for specific classes for dinosaurs and dogs if you think so. The amount of functionality in common between the two is simply too great to justify such specialization.

You might have some need for specialization, if you did something like:

• a single interface called Pet, which can for example evolve and move;
• three" sub " interfaces: animal, plant and robot;
• hence you assign each "sub" interface only what is specific to it. Robot does not grow (I think), plant does not speak and animal does not release ray of death.

Good luck and happy coding!

Abstract Class X Interface

You started by creating the Class Pet with common properties between derived classes. Is there any reason not to keep doing this for the methods and events? Passing these common members to Pet already simplifies a lot. Renan suggested putting everything together in an interface called Pet. But you already have this interface. An abstract class is both a class and an interface. The abstract class Pet is its interface.

Generalize o that you can

Follow Renan's recommendation and turn the sound emission methods of Pets into something generic. Remember that the sound emission is the only action, the way the sounds are emitted is that it will vary, that is, the implementation varies. What you did was exactly what is described in the link provided by Joshua Eduardo.

You probably haven't quite understood the conceptualization of what the interface is. It declares actions and not the mechanism (normally, but let's not make the mechanism being used in other ways, not every language does this), the implementation of these actions. Understand that abstract interfaces and methods of abstract classes define behavior, but do not implement this behavior. Only concrete classes can implement the behaviors. When you treat a bark or a neigh without the abstraction of the ability of animals to make sounds, you are leaving aside one of the advantages of object orientation that is the actual abstraction (having a barking abstraction to implement a barking is an artificial abstraction).

Perhaps all these sound emissions are already contemplated in the Talk() method and only different implementations are required. At this point I disagree with Renan that each type of Pet does not need specific classes. Need to be able to make specific implementations in these classes. The suggested solution would only work if all sound emissions were equal.

If or Talk() serves something else, you can create another generic method to denote the sound emission action of the pets, Speak() maybe?.

When you do this, all interfaces, individually, will be implemented in only one class each. Can you tell why this is necessary? If you have a good reason, okay, if you don't, you kill them. In general, an interface is only interesting when it is used in at least two classes. Future use is not a good reason. If in the future you need, then you create the interfaces. There is no problem in creating an interface and putting in an already existing class as long as the design of the class is right. An existing class can take on a new interface if it already has the desired behavior. This does not hurt any principle and does not create problems.

I say more. If you can abstract the method pairs (don't force the bar, only do it if it's the best thing to do), Eat and Recharge, Sleep e Maintenance, Poop and OilLeak, maybe find out which are the same action with different implementations.

Future implementation

If one day you need in a HybridPet that implements some methods (and events obviously) unique to the AnimalPet and also some unique methods of RoboticPet, then you create the IAnimalPet that will be used in the class AnimalPet and in the HybridPet and the IRoboticPet that will be used in the RoboticPet and HybridPet. This is if they really help something. You will only need two interfaces.

Conclusion

Noted that do you need zero interfaces? In your case, you have many interfaces . In current modeling, an interface is a lot.

Do not forget that in abstract classes, unlike interfaces you can give a standard implementation to the methods if they match for some types of pets.

Do not worry about the future in this case. If you have trouble creating a consistent interface in the future it's because your model was wrong, not because you stopped creating the interface before.

I find your case pretty simple and don't need to make the gambiarra of making a specialization an exception (and probably generate an exception in runtime in this case) as suggested by Renan.

If you improve modeling and still have doubts post new question so we can continue helping with the new problem.

In this case is bad practice because you are writing useless code. Create only the interfaces that are required now .

Leave to create in the future the interfaces that will be needed in the future. This will not increase your effort at all - the IDE automatically creates interfaces for you and already changes the code that references the implementation so that it will reference the interface, and even if the IDE did not do this the effort would be nothing more than a " search and replace".

Contrary to what your friend said, the performance of the application will not change at all, but your code will become simpler, which, among other benefits, decreases waste.

Man if you have an interface for an implementation, I don't see any use having the interface. Many people use as an argument: "if you need a day to extend the class is easier", but that day never arrives.

If you have more than one implementation for the interface, ok... but why use the interface ? from a practical point of view, is it necessary ?... don't inflate your code just to get "architecturally beautiful" the simpler the better.

I advise you to give a look at this blog from Adam Bien, and also look for some of his workshops. Although it is aimed at Java, it has some very interesting concepts about OO, which apply to any language.

Answering your question: not bad practice. More you should follow some principles when doing modeling, according to the principle YAGNI you do not need to create interfaces for all your classes for the simple fact that you will never use, but if you are having doubts when modeling a certain class I suggest creating an interface, especially if you are developing a package or using and want a low level of coupling.

Only use Interfaces if used Design by contract (DbC ).

If you do not use DbC, keep your code lean without using interfaces.

This is" the best " from the values of Lean Software Development because it eliminates waste. Of course, from other values, this "best" can be different.

I believe that using an interface serves to ensure that an object has required properties at the time it will be used, forcing execution this with typing. If I do not need this guarantee, then the creation and implementation of interface is a vain effort. If I expect a Logger object, I expect it to have a method that allows me to register a string, so I say that the Logger object I will receive should at least have a foo(string) method and so I will be sure that the application will work. But this is only valid if the Logger injection possibilities are more than one, such as when you develop a library that it writes logs, but expects the Logger to be injected by the application that will use your library.