Inheritance versus Composition

This is fairly basic topic in OOAD but I have seen most of programmers do not understand subtleties .
Mostly they do not want to think hard and make inheritance as default choice of implementation for re-use .

Finally end up with BIG FAT parent class extended by many classes with lot of if-else conditions and only god know what is the mess in that class .

Inheritance is achieved by extending class or interface/interfaces in java .
Composition is achieved by building stronger HAS_A relationship .

Inheritance (Compile Time Structure)

1. Uses sub-classing  or extending the base class (interface or class).
2. It is called white-box re-use because it knows internals of parent class.
3. New functionality is achieved by partially or completely re-defining of parent functionality .
4. Defined statically at compile time and easy to understand.
5. Inheritance break encapsulation - because it has access to internal state of parent class . If some thing is changed at parent class we need re-test all extended classes also . It might cause ripple effect of change if you change anything in parent class to all sub-classes.
6. To use inheritance you should know all internal state and documentation of parent class so there is learning curve .
7. Relationships can not be re-defined at run time .
8. Has to deal with small number of classes.

Composition (Run Time Structure)

1. Uses composition of small objects which have well defined interfaces .
2.It is called black-box re-use because object using the object do not know internal details of the object .
3. New functionality is developed by using small functionality of number of objects.
4. Composition have well  defined interfaces to all small objects so as long as there interface is same user object does not care details .
5. Composition promotes encapsulation allowing to change parent and subclass to change and evolve independently .
6. To use composition you do not need to know internal state of objects and once you know interfaces there is very small learning curve so code is easy to understand .
7. As per need you can compose object with large number of small objects to mimic required behavior .
8. Has to deal with large number of small classes.

So suppose you have small N number of small objects with specific focused behavior ideally you should able to compose  2^n possible compositions .

So Remember favor object composition over class inheritance for more testable code , less learning curve and more encapsulation  so reuse .  

Angular JS interview questions

Design patterns in one page

Main Opps concepts are classes, object ,  inheritance , polymorphism , abstraction  and  encapsulation .
Classes can have fixed state and fixed behavior  while object can have dynamic state and behavior .

You can use either object composition or class inheritance (class inheritance or interface inheritance ) while designing classes .Inheritance is tied to class at compile time .So such behavior is static at run-time . This is the main theme used class scoped  design patterns .


You can create large number of granular objects and use dynamic composition through polymorphism  to change behavior  at run-time as per your need. This is major theme used in object scoped  design patterns .

While designing always program  to interface and not to implementation so that code is reusable to client  and owner could plug-in any implementation as per need which client is unaware of . This is also major theme in most of design patterns .

Main Concepts :

Inheritance  (Extending abstract class , implementing one or many interfaces / abstraction/generalization/realization/Is_A  )

Inheritance is fixed at compile time so it has static behavior .

Composition (Association/Aggregation/composition / Has_A )
Composition can be decided at run time so it has  dynamic behavior  .


Creation Patterns 

Abstract Factory (Kit)
Provide an interface for creating families of related or dependent objects without specifying their
concrete classes.

Builder
Separate the construction of a complex object from its representation so that the same construction
process can create different representations.

Factory Method
Define an interface for creating an object, but let sub-classes decide which class to instantiate. Factory
Method lets a class defer instantiation to sub-classes.

Prototype
Specify the kinds of objects to create using a prototypical instance, and create new objects by
copying this prototype.

Singleton
Ensure a class only has one instance, and provide a global point of access to it.


Structural Patterns 

Adapter
Convert the interface of a class into another interface clients expect. Adapter lets classes work
together that couldn't otherwise because of incompatible interfaces.

Bridge
Decouple an abstraction from its implementation so that the two can vary independently.

Composite
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat
individual objects and compositions of objects uniformly.

Decorator
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative
to sub-classing for extending functionality.

Facade
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level
interface that makes the subsystem easier to use.

Flyweight
Use sharing to support large numbers of fine-grained objects efficiently.

Proxy
Provide a surrogate or placeholder for another object to control access to it.


Behavior Pattern 

Chain of responsibility
Avoid coupling the sender of a request to its receiver by giving more than one object a chance to
handle the request. Chain the receiving objects and pass the request along the chain until an object
handles it.

Command
Encapsulate a request as an object, thereby letting you parameterize clients with different requests,
queue or log requests, and support undo-able operations.

Interpreter
Given a language, define a representation for its grammar along with an interpreter that uses the
representation to interpret sentences in the language.

Iterator
Provide a way to access the elements of an aggregate object sequentially without exposing its
underlying representation.

Mediator
Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by
keeping objects from referring to each other explicitly, and it lets you vary their interaction

independently.

Memento
Without violating encapsulation, capture and externalize an object's internal state so that the object
can be restored to this state later.

Observer
Define a one-to-many dependency between objects so that when one object changes state, all its

dependents are notified and updated automatically.

State
Allow an object to alter its behavior when its internal state changes. The object will appear to change
its class.

Strategy
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets
the algorithm vary independently from clients that use it.

Template Method
Define the skeleton of an algorithm in an operation, deferring some steps to sub-classes. Template
Method lets sub-classes redefine certain steps of an algorithm without changing the algorithm's
structure.

Visitor
Represent an operation to be performed on the elements of an object structure. Visitor lets you define
a new operation without changing the classes of the elements on which it operates.


Non GOF patterns 

Object Pool
MVC pattern
Dependency Injection


Practical Hybrid Patterns :

Factory Method + Prototype +Singleton

If you have to create very large number of types of objects using factory method then you need to pass some type identifier are parameter to factory method , then in factory method you have to create large number of if-else clauses or long switch clauses to implement logic .
To void this you can keep map or registry of type identifier  to object . The sub-classes should be clone-able or have copy constructor or they are singleton . So when request  comes to factory method with type identifier , look up in registry get  object of the type then either return clone of object or singleton object .
Instead of keeping registry  of objects you can keep mapping of type identifier to class then using reflection you can create objects on fly and return for the specified types .
Registry could be map /server or simply property /JON /XML file .

Web application security interview questions

Web Services Interview questions

Distributed Systems interview questions

Cassandra interview questions

Distributed Systems Concepts :

1. What will happen when nodes goes down and does not respond to co-coordinator node ?
2. What  synchronization is used in Cassandra nodes ? NTP or vector clock ?
3. How decide nodes in cluster with requirements for read and write load ?
4. What is CAP theorem ? Is it possible to achieve all three ? if not why ?
5. What is eventual consistency ?
6. How to tune read and write consistency in Cassandra ? How to get stronger consistency ? if we get strongest consistency level then how we will sacrifice  availability
7. What kind of hashing is used in Cassandra ?
8. What is consistent hashing  ?
9. Why write are faster in Cassandra ? Describe write path ?
9. Why read are slower  in Cassandra ? Describe read path ?
10. Compare read/write path in Cassandra and in mysql ?
11. When to choose Cassandra over mysql ?
12. Which consistency model Cassandra uses ? CA , AP and CP ? and why ? 
13. When some nodes are down , how Cassandra do replication ?
14. What is hinted hand off in Cassandra ?
15. What are consistency levels ? Are consistency levels per query or global ?
16. What are differences between ALL , QUORUM and ONE  what is effect on performance ?
17.  If my replication factor is 3 then In case of ONE  consistency level will Cassandra replicate  to 3 nodes ?
18. How to handle OLTP and OLAP load  ? what could be strategy ?

NOSQL interview questions

Elastic Search interview questions

Object Oriented Analysis and Design : OOAD Interview Questions (Scale , Design Patterns , Algorithms )

Nowadays nobody will ask you to design systems with limited number of users , always expectation would how you design highly available , partition tolerant , horizontally scaling secure cloud application .

Gone are the days ,  when interviewer was  asking to design chat server which works in one JVM process  for two users .

Now people need to start thinking laterally about highly scale-able, distributed,  parallel algorithms and how scale only by adding more hardware for dynamic load .
This fact is more essential now a days because architecture remains same for single user or millions of users , only difference is number of machines handling them in background .


Pre-requisite : 

 - Design patterns
- Distributed Systems
- Cloud Platform - AWS/OpenStack/Azure
- SQL/NO-SQL databases for big data , Tuning consistency in NO-SQL
- Map-Reduce - Hadoop/Apache Spark/ZooKeeper
- Micro- services architecture
- Rule /workflow engines
- Information retrieval - (Elastic search /Solr)
- Shared nothing architecture
- Synchronous systems (queue based producer /consumer) - P2P
- pub-sub models
- Caching (Write-through , Write-back , Write-around , eviction policies ) - Memcached, Redis



Design Goals - 

• Reusable , Extensible design 
• High performance ( Acceptable SLAs , Storage )
• High Availability
• Partition Tolerance
• Handles big data
• Security
• Scale linearly (vertical and horizontal ) with more hardware .

General aim is throw ambiguous questions to candidate and see how he can navigate through open ended scenarios . How he asks questions , how he create use cases , how he consider performance , scale , security and SOLID principles   to design .

Such questions are suitable for Face to Face interview or given offline tasks with sufficient time. It is not suitable for telephonic interviews .

Approach 

Top to bottom approach 

Macro Level -

1. Build basic use cases and in-variants .Understand success/warning/failure cases .Write down use cases one by one . Ask questions for scenarios using Ws like  What, Who, When , Where , Why and also How. 
2. Understand broad level independent logical modules /packages/micro-services .
3. Identify main entities /interfaces /classes in the system. Understand segregated interfaces . Do  not one fat interface .
4. Understand basic actors in the system .
5. Draw component /class /object /package diagram .
6. Anticipate changes in future requirements like if some things are not dynamic today , those could be dynamic in future , adding similar type of specialized functionality etc.

Micro-Level 

1. First do all interface based design , for all major classes (DAO classes , Coordinator classes )
2. Consider design patterns if applicable , do not over use them to show your knowledge .
3. Think multi-threaded approach with compute intensive / IO intensive activities .
4. Understand basic tasks and separable boundaries so that you can create distributed processing of item .If task is fully independent  then it will be helpful to use distributed computing - Map-Reduce .
5. Externalize configurable parts like  rules engine , thread-pool sizes in JSON , property file , XML etc.

General Questions 

1. Design Coffee Machine
2. Design lift system for a multi-storied building
3. Design Chat Server (typical pub-sub problem)
4. Design distributed cache
5. Design traffic signal system
6. Design bus/train scheduling system
7. Scheduling meetings with given number of meeting rooms.
8. Design online shopping site .
9. Design tiny URL system .
10. Do some kind of analytics on text for large number of files (typical Map-Reduce problem).
11. Design restaurant reservation system .
12. Design restaurant system with rule based pricing  and dynamic configurations for menu items .
13. Find connected components in large data . (say you have excel-sheet with some king of graph structure ).
14. Design Search Engine .
15. Design twitter
14. Design parking lot system.
15. Design custom re-entrant lock
16. Design custom thread pool.
17. Design Object thread pool or JDBC connection thread pool.
18. Design distributed file system.