Is the facility a great practice?

Question

Object-oriented programming languages, for example. java, C #, ... support for object types. For example, this is perfectly true in java:

URL url = new URL("url"); URLConnection conn = url.openConnection(); if( !conn instanceof HttpURLConnection ) throw new Exception("not http request"); HttpURLConnection con = (HttpURLConnection) conn; 

Or another basic example that I tried:

 public class Base { public void base(){} } public class Derived extends Base { public void derived(){} } Base b = new Derived(); b.base(); 

A derived class has all the methods of the base class, plus more. There is no reason why you cannot create a base class by calling the constructor of the derived class.

I also stumbled upon this link http://www.volantec.biz/castingObjects.htm , which explains how object modeling works. Still good.

But why is the HttpURLConnection con = new HttpURLConnection("url address") not used in the first example (I know HttpURLConnection is an abstract class). It just seems more understandable, simpler. On the other hand, when dealing with interfaces , casting objects will be useful . Another example is the List<Object> list, which I sometimes see in some classes. This means that you can save all possible classes in this list. After that, you can simply give it to the original if you know what type it is. It would not be clearer to save only certain classes to list, i.e. List<String> , List<MyClass> . Does List<Object> good design practice in general?

Answer 1

When developing a class hierarchy, you always need to leave the Liskov Substitution Principle (aka, LSP) :

Derived types must be fully replaceable for base types.

In other words, in order to decide whether to extend the class, you should ask yourself if the components that depend on your new class will be well served if you change it to your base class.

The problem with casting is that if you ever need to convert an object of a base class to a Derived class, it means that you are breaking the LSP.

If you need to make sure that the object has a specific implementation when you expect an interface, then, of course, something is wrong with your design.

Interfaces are like contracts. If you use an implementation method that is not in the interface, it means that you are violating this contract by creating a connection between your code and the implementation.

Remember that your code should always rely on abstractions, not nodules .

Answer 2

by casting with the Object ur class, which basically grants all available permissions to derived classes, that is, the function will never reject upcoming parameters, since u provided access to the object so that it is dangerous, and according to @Henrique says that it’s correct that if you need to make sure that the object is a concrete implementation, when you expect an interface, then, of course, something is wrong with your design.