Avantages de l’utilisation de classes abstraites par rapport aux classes ordinaires
J'ai décidé de me lancer seul dans de petits projets de codage centrés sur la qualité du code plutôt que sur la quantité de code et sur une question relative à l'utilisation de classes abstraites.
Maintenant, je connais les différences entre les classes abstraites et les interfaces, la plus grande (je pense) étant que cette interface ne vous permet de définir que des méthodes devant être implémentées par des classes à l'aide de l'interface et des classes abstraites vous permettant de définir à la fois la méthode et les membres. implémentation de méthode par défaut si vous le souhaitez. Ma question est quel est le principal avantage d'utiliser une classe abstraite par rapport à une classe normale? La seule différence réelle entre les deux à laquelle je peux penser est que vous ne pouvez pas créer une instance d'une classe abstraite. Y a-t-il d'autres différences entre les deux?
Strictement du point de vue de la conception, il est préférable de simplifier les choses. Je crois que le meilleur moyen de simplifier les choses est d'utiliser une analogie simple. Utilisons une analogie d'oiseaux ...
Interface: utilisez cette option lorsque vous souhaitez appliquer certaines fonctions à définir. par exemple. IBird a signé un contrat avec ScreamLikeABird et Fly (fonctions d’interface). Mais vous pouvez être plus précis et avoir un IOstrich qui a un contrat Run. Vous pouvez également avoir un IHawk qui a un contrat d’Attack, etc.
Résumé: utilisez cette option pour appliquer des fonctions de base et disposer de propriétés de base. par exemple. Avian pourrait être une classe de base pour les oiseaux pouvant avoir une fonction appelée LayEgg ainsi que des propriétés appelées Age, Species, NumberOfChicks ... etc. Ces choses ne changent pas/ne devraient pas changer le comportement d’un oiseau, puisque tous les oiseaux pondent des œufs, etc. Mais tous les oiseaux ne sonnent pas de la même manière quand ils crient ou volent de la même manière (certains ne volent même pas), etc., et qu'ils doivent donc être implémentés via une interface.
En plus de ne pas pouvoir créer d'instances de classes abstraites, certains langages peuvent prendre en charge l'utilisation de méthodes abstraites dans des classes abstraites. De manière similaire aux interfaces, une méthode abstraite devra être implémentée par la classe héritant de la classe abstraite.
À mon avis, le principal avantage des classes abstraites réside dans le fait qu’un code doit être partagé entre des classes du même type. Habituellement, vous pouvez utiliser une interface pour cela, mais parfois la fonctionnalité de telles classes peut se chevaucher et vous vous retrouvez avec une duplication de code. Dans ce cas, vous pouvez utiliser une classe abstraite et simplement y insérer le code.
Dans OO world, les classes abstraites permettent d’imposer des contraintes de conception et d’implémentation. Rien de plus. Vous ne devez en aucun cas utiliser des classes abstraites. Mais il y a peut-être des cas où vous feriez mieux d'imposer ces contraintes. Alors que sont-ils? Regardons en comparant ses homologues.
Classes abstraites vs interfaces
Comme vous le savez, ce sont deux des concepts fondamentaux de l'héritage.
Fondamentalement, l'interface est utilisée uniquement pour déclarer que vous êtes prêt à hériter du service sous-jacent et c'est tout. Ne contient aucune implémentation et n'a aucune fonctionnalité. En ce sens, l'interface est abstraite. C'est pourquoi il s'agit davantage d'une contrainte de conception que d'une contrainte d'implémentation. Pensez à une prise casque sur un haut-parleur. Chaque casque doit implémenter l’interface prise (avec les méthodes start, stop, listen, turnDown, turnUp). Chaque casque doit remplacer cette interface pour hériter de la fonctionnalité fournie par le haut-parleur et être mis en œuvre en conséquence.
Les classes abstraites, en revanche, peuvent inclure des méthodes avec une implémentation. C'est la différence fondamentale et dans ce sens, il peut utiliser davantage de réutilisation qu'une interface. De plus, ils peuvent contenir des champs privés, protégés et non statiques que vous ne pouvez pas utiliser via des interfaces. Vous pouvez forcer les sous-classes à implémenter certaines fonctionnalités indispensables avec des méthodes abstraites (celles sans implémentations). Les classes abstraites plus agiles que les interfaces.
Bien entendu, vous ne pouvez étendre qu'une classe en Java dans laquelle vous pouvez implémenter un nombre d'interfaces.
Cours abstraits vs cours réguliers
Alors pourquoi ne pas utiliser des classes régulières alors. Quel est l'avantage d'utiliser une classe abstraite? C'est assez simple. Si vous utilisez des classes abstraites, vous forcez la fonctionnalité principale à être implémentée par les frères et soeurs. En tant que développeur, vous n'avez pas besoin de vous rappeler que vous devez implémenter les fonctions essentielles. C’est là que les classes abstraites imposent des contraintes de conception par rapport aux classes ordinaires. De plus, en rendant la classe abstraite, vous évitez que cette classe (incomplète) ne soit créée par accident.
À mon avis, les classes abstraites sont plus utiles dans les projets réels que sur les livres. Parfois, les chefs de projet fournissent simplement la déclaration des méthodes et vous devez écrire du code pour les méthodes sans modifier la syntaxe de base fournie par le gestionnaire. c'est donc comment une classe abstraite utilise full. dans la méthode de classe simple, définir, déclarer et coder en même temps mais pas dans des classes abstraites. par exemple: -
abstract class Test
{
abstract void show();//method provided
}
class Child extends Test
{
void show()//coding
{
System.out.println("saurav");
}
}
class main
{
public static void main(String[] args)
{
Test c = new Child();
c.show();
}
}
Classes abstraites vs Classes régulières vs Interface. Les classes abstraites supportent généralement une idée de la généralisation et aident les programmeurs à conserver un minimum de discipline cérébrale en concevant des projets pluriannuels à cause de cela. Décrire une implémentation qui utilise des méthodes abstraites dans les classes subling, cependant, cette fonctionnalité est un désavantage pour des projets à court terme lorsqu'un développeur a un zeitnot.
En cas d'extension d'une classe A par une autre classe B (i, e partageant des propriétés de A à B), je peux mettre quelques cas d'utilisation différents entre la classe abstraite et la classe normale.
Classe abstraite : Utilisez une classe abstraite ' Abs ' si vous souhaitez que certaines méthodes soient utilisées obligatoirement par les classes qui l'étendent ( Abs ).
Classe normale : Lors de l'extension d'une classe normale A d'une autre classe B, je peux utiliser chacune des fonctions de A, mais ce n'est pas obligatoire.
Remplacer une fonction de A ajoutera des propriétés à B.
par exemple
class Automobile{
//type of fuel
abstract String gasOrPetrol(){
}
}
class BMW extends Automobile{
//I will have to worry if I don't know the fuel type of my BMW;
//so i made it compulsory to be implemented
//One more point, I also need to make the method abstract to make it really compulsory
//
String fuel="Petrol";
@Override
String gasOrPetrol() {
return "fuelType is "+fuel;
}
}
Mon intention est juste de donner une idée des bonnes choses qu’a une classe abstraite. Codage heureux ...
La seule raison pour déclarer une classe abstraite est qu'elle ne peut pas être instanciée. Il existe des situations dans lesquelles vous aurez des fonctionnalités communes partagées entre plusieurs classes, mais qui ne représentent pas en elles-mêmes un objet ou un objet incomplet. Dans ce cas, vous définissez la fonctionnalité commune comme abstraite afin qu'elle ne puisse pas être instanciée.