//---------------------Single responsibility principle -----------------------------------------

//	1 class - 1 duty, in other words in one class could be one public method
//	for example - the screwdriver has something to twist. If you make it massive, then
//	it can be used for hammering nails
//	(though this is not very convenient),
	  ---------------------------------
//	or another example: human Greg
//	he opened courses for something by himself.
//	He has 2 responsibilities:
//	he has to teach these courses,
//	and deal with financial issues.

	class GreG{
		...
		public void Teach(){}
		public void doSomeWithMoney(){}
	}

//	according SRP one person  has to hire another one person to take Greg out of one tis duty (financial issues or a teaching).

	class GreG{
		...
		public void Teach(){}
	}

	class anotherMan{
		public void countMoney(){}
	}

//---------------------Open/closed principle-----------------------------------------------

//	software entities (classes, modules, functions, etc.) should be opened for extension, but closed for modification
//	for instance, we have a Rectangle class witm 2 parametres and 1 method;

	class Rectangle {
		int width,height;
		int Area(){
			return width*height;
		}
	}

//	we have array of Rectangles and we should count suma of their areas in e new class
	class Areas{
		int areaCount(Rectangle [] rects){
			int sum=0;
			for(Rectangle r:rects){
			sum+=r.Area();
			}
			return sum;
		}
	}

//	Later we need to extend this class for counting suma of Circles areas

	class Areas{
		int areaCount( shape [] rects){
			int sum=0;
			if(shape  instanceof Rectangle){
				for(Rectangle r:rects){
					sum+=r.Area();
				}
			}
			else
			{
				for(Circle c:rects){
					sum+=c.Area();
				}
			}
			return sum;
		}
	}

	Further, in order not to change the class from time to time.
	we can create the abstract class "Shape" witch will have the function to calculate area.
	other figures extends frome Shape class and redefine the function if calculating area.

	abstract class Shape{ double Area();}

	class Rectangle extends Shape{
		double width,height;
		double Area(){
			return width*height;
		}
	}
	class Circle extends Shape{
		double radius;
		double Area(){
			return 3.14*radius*radius;
		}
	}

	class Areas{
		int areaCount( Shape [] shapes){
			int sum=0;
			for(Shape s:shapes){
				sum+=s.Area();
			}
			return sum;
		}
	}

//---------------------Liskov substitution principle-----------------------------------

//	all successors are able to include to their behavior the ancestor behavior
//	for Example: we have bird class and it can fly

	class bird{
		string fly(){
			return "i can fly" ;
		}
	}

//	and it has successors - duck, sparrow, ostrich and  penguin

	class duck extends bird{
		string fly(){
			return "i can fly" ;
		}
		string swim()
		{
			return "i can swim";
		}
	}

	class sparrow extends bird{
		string fly(){
			return "i can fly" ;
		}

	}

	class ostrich extends bird{
		string fly(){
			throw "i can not fly" ;
		}
		string run()
		{
			return "i can run";
		}
	}

	class penguin extends bird{
		string fly(){
			throw "i can not fly" ;
		}
		string swim()
		{
			return "i can swim";
		}
		string walk()
		{
			return "i can walk";
		}
	}
//	as we can see, there are the exceptions in ostrich  and penguin classes. they can not fly.
//	and we must throw an exception.
//	it would be better to do the inheritance with another method or class,
//	for example, all birds can walk:

	class bird{
		string Walk(){
			return "i can Walk" ;
		}
	}

	class duck extends bird{
		string Walk(){
			return "i can Walk" ;
		}
		string fly(){
			return "i can fly" ;
		}
		string swim()
		{
			return "i can swim";
		}
	}

	class sparrow  extends bird{
		string Walk(){
			return "i can Walk" ;
		}
		string fly(){
			return "i can fly" ;
		}

	}

	class ostrich extends bird{
		string Walk(){
			return "i can Walk" ;
		}
		string run()
		{
			return "i can run";
		}
	}

	class penguin extends bird{
		string Walk(){
			return "i can Walk" ;
		}
		string swim()
		{
			return "i can swim";
		}
	}


//---------------------Interface segregation principle--------------------------------------

//	for example, there is an interface "spend time" which will be added to the object "day"

	interface ISpendTime{
		string readbook();
		string learnEnglish();
		string chatWithFriends();
		string doStuff();
	}
	class day implements ISpendTime{
	string readbook(){
		return "readBook";
	}
	string learnEnglish(){
		return "learnEnglish";
	}
	string chatWithFriends(){
		return "chatWithFriends";
	}
	string doStuff(){
		throw "I wodnt do this";
		}
	}
//	there is not the fact that someone will want to all these activities during one day
//	he have to refuse some these actions.
//	it is possible to add each of these actions to different interfaces.
//	And after that, connect those interfaces that are needed.

	interface Ireadbook{
		string readbook();
	}
	interface IlearnEnglish{
		string learnEnglish();
	}
	interface IchatWithFriends{
		string chatWithFriends();
	}
	interface IdoStuff{
		string doStuff();
	}
	class day implements Ireadbook , IlearnEnglish{
		string readbook(){
			return "readBook";
		}
		string learnEnglish(){
			return "learnEnglish";
		}
	}

//---------------------Dependency inversion principle--------------------------------
//	high level modules should not depend on low level modules.
//	Abstractions should not depend on details.
//	Details should depend upon abstractions.

//	if we have the method witch has as parameter some object,
//	but we want to use only one of metod of this object.
//	it would be beter to pass not specific object, but any object witch has the method we need.

//	for example if we need to eat, it is not  neccesary to go in
//	the certain shop or cafe, as we can just go to the nearest one