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

You are practically making an interface for each 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 keep the job simple because:

• If you have to add more functionality to the animals, just work on a single interface. You do not 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, ie: it is much easier to control who is affected by a change of a specific interface

Another thing, several 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 "talk" or "speak" method. Hence, if the animal is going to bark, yell, yell or call the judge to complain about lack is in charge of implementing the method in the class that will use the inheritance.

Finally, you ask: Yeah, I've put all the methods together into a single interface called Pet . But what if I have some animal that does not use some functionality? For example, a slug would never backfell. In this case, you have several options:

• Treat this in an abstract method and give some indication that the slug can not somersault backwards;
• Being a bastard and launching a NotImplementedException ;
• Be a double bastard and leave the method empty.

In all cases, document what you are doing well;)

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

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

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

Good luck and happy coding!

Abstract Class X Interface

You started by creating the Pet class with common properties between derived classes. Is there any reason not to continue doing this for methods and events? Passing these common members to Pet already greatly simplifies. 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 what you can

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

You probably still do not quite understand the concept of what the interface is. It states actions and not the mechanism (usually, but we are not going to make the mechanism being used in other ways, not every language does this), the implementation of these actions. Understand that abstract class interfaces and methods define behavior, but do not implement this behavior. Only concrete classes can implement behaviors. When you treat a barking or neighing without the abstraction of the animals' ability to emit sounds, you are leaving aside one of the advantages of object orientation which is the actual abstraction (having a bark abstraction to implement a bark is an artificial abstraction).

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

If Talk() is for something else, you can create another generic method to denote the sounding action of pets, Speak() maybe?.

When you do this, all interfaces, individually, will be implemented only in one class each. Can you tell why this is necessary? If you have a good reason, okay, if you do not have it, do not. 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 it in an existing class as long as the class design 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 (do not force the slash, just do it if you do the best), Eat and Recharge , Sleep and Maintenance , Poop , OilLeak , you might find out are the same action with different implementations.

Future implementation

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

Conclusion

Notice that you need zero interfaces? In your case, you have many interfaces . In the current modeling, an interface is very.

Do not forget that in abstract classes, unlike interfaces you can give a default implementation in 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 very simple and do not need to make the hassle of making a specialization an exception (and probably generating an exception in runtime in this case) as suggested by Renan.

If you improve modeling and still have questions post new question to continue helping with the new problem.

In this case it is bad practice because you are writing useless code. Only create the interfaces that are now .

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

Contrary to what your friend said, application performance will not change at all, but your code will be simpler, which, among other benefits, will reduce waste.

Dude, if you have an interface to an implementation, I do not see any utility to have the interface. Many people use it as an argument: "If you need a day to extend the class is easier," but that day never comes.

If you have more than one implementation for the interface, okay ... but why the interface? from a practical point of view, is it necessary? ... do not swell your code just to be "architecturally beautiful" as simpler the better.

I advise you to take a look at this Adam Bien blog, and also look for some his workshops. Although it is Java-centric, it has some very interesting OO concepts that apply to any language.

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

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

This is "best" from the Lean Software Development values because it eliminates waste. Obviously, from other values, this "best" may 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 the execution of this with Typing. If I do not need this guarantee, then the creation and implementation of interface is an in vain effort. If I wait for a Logger object, I hope it has a method that allows me to register a string, so I say that the Logger object I will receive must at least have a foo(string) method and so I will be sure that the application will work. But this is true only if the logger injection possibilities are more than one, such as when you develop a library that writes logs, but expects the Logger to be injected by the application that will use your library.

Answering your question: It is not bad practice. But 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 in doubt at the time of modeling certain class I suggest creating an interface, especially if you are developing a package or using and want a low level of coupling. / p>