_I am going off of the 'Design Pattern' path right now to discuss the O in the SOLID principles (Single Responsibility, Open Closed, Listkov Substitution, Interface Segregation, and Dependency Inversion)._

How Can Something Be Open And Closed At The Same Time?

The Open Closed Principle's motivation is to minimize code reformatting. Classes and functions should be Open for extension, closed for modification. If you are having to reformat the base class for every subclass necessary, then you are probably violating the Open Closed Principle. Let's take an example which first violates the principle, then modify it to satisfy our conditions.

Implementation

 public class Tutor {
              public void tutor(Student studentName) {
                   if (studentName.equals("Devan")){
                        tutorDevan();
                   } else if (studentName.equals("Sally")){
                        tutorSally();
                   }
              }
              public abstract void tutorDevan(){
                   ...
              }
              public abstract void tutorSally(){
                   ...
              }
         }
         public class Student {
              String studentName;
         }
         public class StudentDevan extends Student {
              StudentDevan(){
                   super.studentName = "Devan"
              }
         }
         public class StudentSally extends Student {
              StudentSally(){
                   super.studentName = "Sally"
              }
         }
         ```

        Note: This is assuming that every student needs to be tutored differently.

        Notice how the base class is holding all of the logic! This is a big no-no. Notice how large the Tutor class will be if we have a 250 size student-roster.

        The Good News!
        =====


        There is a much better solution with an Open Closed, OOP-_esque_ flavor.
        

java public class Tutor { public void tutor(Student student) { student.tutor(); } } public class Student { public abstract void tutor(); } public class Devan extends Student { public void tutor(){ ... } } public class Sally extends Student { public void tutor(){ ... } } ```

Notice how much cleaner this looks. The logic is put back into the subclasses and now whenever we have a new student (provided that we are in drop-add week), we do not have to change the logic in the Tutor class, but modify a new Student subclass.