FindARotation

findarotation

With the introduction of OOPs, Inheritance and Composition entered our senses and still confusing us. Choosing between and is not easy. Often, the decision depends upon the information which is not yet there. Composition Inheritance The structure of an application plays an essential role in adding changes. Composition and Inheritance are the building blocks of an application structure. It is imperative to know when to use which one. Inheritance is a way of reusing code by inheriting the structure from the referred class or Type. The referred class is called or class and the referring class is called or . Inheritance parent base child subclass suggests that subclass inherits public members (API) of the parent class. A subclass can override or add new behaviour or extend the existing behaviour of the parent class. Inheriting the structure { {
     println( );
   } {
      println( )
   }
} {
      println( )
   }
} cat = Cat();
cat.walk() cat.speak() // Reference class class Animal fun walk () "animal walk" fun speak () "..." // Referring Class // Cat class "inherits the structure" from the Animal class : class Cat Animal { // overriding existing behaviour fun speak () "meow" // in main val // Cat can "reuse" parent class behavior // meow Composition is a way of reusing code by interacting with the referred class . Composition without any structural imposition ( x: , y: ); {
     println( )
  }
} ( sides: Array<Line>) { { (side sides) {
       side.draw(); }
  }
} // Reference Class class Line val Int val Int fun draw () "line drawing" // Refering class class Shape val fun shapeDraw () for in // code refering Matrix Uniformity I had a situation to ignore JsonNaming annotation¹ provided by Jackson library (Java ecosystem). There is no direct API provided by the library to facilitate the same. A possible solution to have a new class dictating the desired functionality and injecting the new class object to the library. Luckily, the chosen library provides the API to inject custom class (Thanks to open-close design). Should I compose or inherit from the existing Class? - . inherit { {
        JsonNaming ann = _findAnnotation(ac, JsonNaming.class); (ann == ) ? : ann.value();
    } } { { ;
    }
} ObjectMapper mapper = ObjectMapper();
mapper.setAnnotationIntrospector( IgnoreJsonNaming()); // class for library class JSONIntrospector // .. rest code Object public findNamingStrategy (AnnotatedClass ac) return null null // .. rest code // custom class class IgnoreJsonNaming extends JSONIntrospector @Override Object public findNamingStrategy (AnnotatedClass ac) return null // inject code new new Inheritance is more suitable in this context as it is expected to have structural similarity or uniformity. If I preferred to go with Composition, I would have to implement unnecessary methods to maintain structural similarity. Composition would not have worked : Imagine, If in future, library developers add new behaviours to the referred Class, I would end up changing in the latest Class to have structural similarity. Semantics Inheritance and Composition not only allow to reuse the code; they also define a relationship semantic between two classes. Inheritance : is-a Composition : has-_ (_ means any quantifier) Apple Fruit. (Inheritance) is a Apple seeds. (Composition) has Human mammal. (Inheritance) is a Human hands. (Composition) has two These keywords assist in basic analysing the requirements. Software Model: OOA/D Whenever we write software, we introduce so many concepts from Specification and Implementation point of view. Through rigorous analysis, these concepts end up with numerous classes. Shaping these classes (object decomposition) and connecting these classes become our primary responsibility. Implementation Concepts: Factory, Manager, Service, Client, Provider e.g. RestClient, EmailService, ValidtorFactory Sometimes, it is better to start with code at first, then evolve the design. You are free to play until the first release. Once the software is released, it is hard to reverse most of the decisions. Multiple Concepts Inheritance does not befit well for multi-dimensions concepts or variants or attributes. If applied, it leads to Combinatorial Explosion of classes. Say, you are modelling Pizza with two allowed Toppings Onion and Tomato. If you choose Inheritance to connect Pizza and Topping, then you would end with four classes. (concept 1) (concept 2) { { ;
  }
} { ;
  }
} { ;
  }
} { ;
  }
} // with inheritance class Pizza // without topping fun getPrice () return 100 : class PizzaWithTomatoToppings Pizza { fun getPrice () return 120 : class PizzaWithOnionTopping Pizza { fun getPrice () return 120 : class PizzaWithOnionAndTomatoToppings Pizza { fun getPrice () return 140 With Composition, two classes are sufficient. { t1 : Topping? = ; t2 : Topping? = ; { basePrice = ; basePrice + t1?.getPrice() ?: + t2?.getPrice() ?: }

} ( price: ) { { price;
  }
} // with composition class Pizza var null var null fun getPrice () val 100 return 0 0 class Topping val Int fun getPrice () return Takeaways In Inheritance, the structure imposition introduces tight coupling between both connected classes; it restricts their future editing. Inheritance is well suited for uniformity. Inheritance does not great for multi-dimensions concepts or variants or attributes. Composition does not impose any structure of any of connected Class. It is a flexible option. References Disable specific annotation in Jackson https://github.com/FasterXML/jackson-databind/issues/133 Previously published at https://themightyprogrammer.dev/article/inheritance-composition

Stories, News & Mentions about FINDAROTATION

Findarotation’s Stories on HackerNoon