Abstract. 1. What is an ABSTRACT METHOD? 2. Why you would want to declare a method as abstract? 3. A non-abstract CLASS is called a concrete class

Transcription

1 ABSTRACT 2 1. What is an ABSTRACT METHOD? 2 2. Why you would want to declare a method as abstract? 2 3. A non-abstract CLASS is called a concrete class 2 4. Abstract Example 2 5. If you are extending ABSTRACT CLASS or implementing INTERFACE than you need to override all ABSTRACT METHOD unless your class is not abstract. ABSTRACT METHOD can only be used by using method overriding What is DRY (Don't repeat yourself) 3 7. What are the best Practices with Separation of Code and Data 4 1

2 Abstract 1. What is an ABSTRACT METHOD? declared without an implementation (without braces, and followed by a semicolon), like this: A method declared abstract is not actually implemented in the current class. It exists only to be overridden in subclasses. It has no body. For example, public abstract float price(); 2. Why you would want to declare a method as abstract? /* the Figure class must be declared as abstract because it contains an ABSTRACT METHOD */ public ABSTRACT CLASS Figure /* because this is an ABSTRACT METHOD the body will be blank */ public abstract float getarea(); public class Circle extends Figure private float radius; public float getarea() return (3.14 * (radius * 2)); public class Rectangle extends Figure private float length, width; public float getarea(figure other) return length * width; why did we declare the getarea method to be abstract in the Figure class? Well, what does the getarea method do? It returns the area of a specific shape. But, because the Figure class isn t a specific shape (like a Circle or a Rectangle), there s really no definition we can give the getarea method inside the Figure class. That s why we declare the method and the Figure class to be abstract. Any classes that derive from the Figure class basically have 2 options: 1. the derived class must provide a definition for the getarea method OR 2. The derived class must be declared abstract itself. 3. A non-abstract CLASS is called a concrete class You should also know that any non-abstract CLASS is called a concrete class. Knowing your terminology definitely pays off in an interview. 4. Abstract Example 2 // I say all motor vehicles should look like this: abstract class MotorVehicle int fuel;

3 // They ALL have fuel, so lets implement this for everybody. int getfuel() return this.fuel; // That can be very different, force them to provide their // own implementation. abstract void run(); // My teammate complies and writes vehicle looking that way class Car extends MotorVehicle void run() print("wrroooooooom"); 5. If you are extending ABSTRACT CLASS or implementing INTERFACE than you need to override all ABSTRACT METHOD unless your class is not abstract. ABSTRACT METHOD can only be used by using method overriding. Overriding ex class Animal public void move() System.out.println("Animals can move"); class Dog extends Animal public void move() System.out.println("Dogs can walk and run"); public class TestDog public static void main(string args[]) Animal a = new Animal(); // Animal reference and object Animal b = new Dog(); // Animal reference but Dog object a.move();// runs the method in Animal class b.move();//runs the method in Dog class Animals can move Dogs can walk and run Thread finished executing 6. What is DRY (Don't repeat yourself) Our first object oriented design principle is DRY, as name suggest DRY (don't repeat yourself) means don't write duplicate code, instead use ABSTRACTION to abstract common things in one place. If you have block of code in more than two place consider making it a separate method, or if you use a hard-coded value more than one time make them public final constant. Benefit of this Object oriented design principle is in maintenance. It's important not to abuse it, duplication is not for code, but for functionality. It means, if you used common code to validate OrderID and SSN it doesn t mean they are same or they will remain same in future. By using common code for two different functionality or thing you closely couple them forever and when your OrderID changes its format, your SSN validation code will break. So beware of such coupling and just don t combine anything which uses similar code but are not related. 3

4 7. What are the best Practices with Separation of Code and Data Single ABSTRACT METHOD [Type]. Also known as a functional INTERFACE, soon to be annotated with annotation. where EventListener is in fact a SAM. The best SAMs are those with single arguments, as they will further simplify writing of a lambda. Imagine writing listeners.add(c -> System.out.println(c.message())); Instead of listeners.add(new public void message(messagecontext c) System.out.println(c.message())); ); Avoid returning null from API methods returning a collection which does not have any value, make sure an Empty collection is returned rather than Null elements. This saves a lot of if else testing on Null Elements. public class getlocationname return (null==cityname? "": cityname); Your API consumers should be able to chain methods whenever applicable: initialise(someargument).calculate(data).dispatch(); In the above snippet, none of the methods should ever return null. In fact, using null s semantics (the absence of a value) should be rather exceptional in general. While there are some cases when returning nulls from methods is OK, there is absolutely no use case of returning null arrays or null collections! Let s consider the hideous java.io.file.list() method. It returns: An array of strings naming the files and directories in the directory denoted by this abstract pathname. The array will be empty if the directory is empty. Returns null if this abstract pathname does not denote a directory, or if an I/O error occurs. Hence, the correct way to deal with this method is File directory = //... if (directory.isdirectory()) String[] list = directory.list(); if (list!= null) for (String file : list) //... Avoid state, be functional HTTP is stateless. All relevant state is transferred in each request and in each response. This is essential to the naming of REST: Representational State Transfer. This is awesome when done in Java as well. much simpler if state is transferred in such objects, rather than manipulated from the outside. example fetches a cursor from a stored procedure: CallableStatement s = connection.preparecall("? =... "); // Verbose manipulation of statement state: s.registeroutparameter(1, cursor); s.setstring(2, "abc"); s.execute(); ResultSet rs = s.getobject(1); 4

5 // Verbose manipulation of result set state: rs.next(); rs.next(); 5