Classes which inherited from the same abstract class calling each other

Question

I have a design that contains such classes.
1) Media - defines some methods to get data which business logic wants and some others to deal with data
media.java
public abstract class Media {
   public abstract Object getSomeData(String type);
   public void methodForMedia() {
       // do something here...
}And certainly, a lot of classes derive from it to function differently.
etc,
DynamicMedia.java
public class DynamicMedia extends Media {
   public Object getSomeData(String type) {
      // get some data here...
      return somedata;
   public void methodForMedia() {
       // inherits and overrides here
   public void methodForDynamicMedia(String data1, Object data2) {
       // do something here...
}FixedMedia.java
public class FixedMedia extends Media {
   public Object getSomeData(String type) {
      // get some data here...
      return somedata;
   public void methodForMedia() {
       // inherits and overrides here
   public Object getFixedMediaData(String type) {
       // get some fixed data here
       return someFixedData;
}2) Business - which implements business logic
public class Business {
     public void transactionOne() {
           FixedMedia fm = getMedia(FixedMedia.class);
           Object fixedData = fm.getFixedMediaData("fixedDataType");
           DynamicMedia dm = getMedia(DynamicMedia.class);
           dm.methodForDynamicMedia("somedata", fixedData);
}Calling methods defined in DynamicMedia might need
many data that can only be retrieved through FixedMedia
(or any similar class just as FixedMedia - derived from Media and handle "fixed" data).
So we decide to define a field to contain a reference of FixedMedia or its container (a list, map)
in DynamicMedia to reduce the codes.
But it results the coupling between DynamicMedia and FixedMedia(s).
Which design is better on testing, quality?

Answer 1

Why not just use an interface?
And why does methodForDynamicMedia() exist only there?
So we decide to define a field to contain a reference of FixedMedia or its container (a list, map)
in DynamicMedia to reduce the codes.Sounds like a muddled design. Sometimes you might make an implementation decision that adversely impacts the design but you better have a better reason than just because it reduces some code. Maybe it reduces a lot of code, but if so then that might suggest something is wrong with the design.