generic programming

What Does Generic Programming Look Like?, Benefits of Generic Programming and Generic Program… Generic Programming is a specialized form of programming in some languages (primarily statically typed languages) where code is written to process objects of any arbitrary type. The distinction between generic programming and normal programming is when writing generic code the “type” (often denoted T ) of the data is not explicitly stated. The generic programming paradigm is challenging to master because it requires a high level of abstraction (ignoring the type of data in its entirety). Languages, like C++ (templates), Java, C , and soon Golang, have built-in support for generic programming and include a large standard library of generic collections and data structures. In the above examples, the logic is the same and is type agnostic. These examples both define generics, which manage an internal array of elements (non-type specific), and have cooresponding add methods for new array elements. The genericization of these list objects allows for both implementations to work within their ecosystem and reduce duplicated code for a List of any type of data. With Generic types (often denoted as T but not always), no assumptions can be made about the instance type being processed. Since no assumptions of type can be made in generic code it becomes possible for the same logic to work for many types in a consistent and repeatable way. The type agnostic nature makes generics a powerful language feature, but it also makes generic code difficult to read or to understand for unaccustomed engineers. Strictly speaking, some languages like C and Java have a base Object class ALL classes inherit from. In those situations, you can make assumptions about the type as long as you treat it as the base Object. Generic programming requires a different mindset from object oriented programming because the type of the data is not explicitly stated. Instead, the focus is on how an “unknown” type is able to be manipulated without the need to know the type. A great use case, and the most common use case for generics, is data structures. While in most languages interfaces are defined and implemented by classes explicitly this is not always the case. For example, both Go and TypeScript use implicit interfaces, not pre-declared directly on a type, and are later inferred through a type contract negotiation process. Implicit interface typing is a powerful tool. Interfaces define a contract a type must adhere to. The interface contract can then be used as the type in code, rather than the original type. This contract allows for many different types to be used, essentially genericizing the code substantially.3 If using an interface type is possible for your purposes, then it is generally the recommended method for generic programming. There are several reasons for this best practice: 1) Interfaces allow for code to use specific knowledge about a type (i.e. parameters or methods), and 2) The interface contract is type checked by the compiler at compile time. Reflection libraries are used to inspect the type of a variable or object and perform operations on it. Generally, reflection is able to access the metadata of any object and access properties, execute methods, and manipulate values. Reflection is, however, a double edged sword. So, why not use reflection instead of supporting generics in the language? Reflection libraries are just that – libraries. They are limited to accessing and manipulating metadata about a type. Reflection libraries suffer from serious performance implications and are NOT statically type checked by the compiler. Due to the lack of complier support, using reflection can lead to difficult bugs, performance issues, and a large amount of code where there is no type safety. It is also easy to misuse reflection. Reflection does not benefit from IDE support (because it only functions at runtime) or complier support. The lack of immediate