Return to Answer

In layman's words:

A. O/C principle means that especialization must be done by extending, not by modifying a class to acommodate for especialized needs.

B. Adding missing ( not especialized ) functionality means the design was not complete and you have to add it to the base class, obviously without violating the contract. I think this is not violating the principle.

C. Refactoring doesn't violate the principle.

When a design matures, say, after some time in production:

• There should be very little reasons to do so ( point B ), tending to zero over time.
• ( Point C ) will always be possible although more infrecuent.
• All new functionality is supposed to be an specialization, meaning the classes must be extended (inherited from) ( point A ).

In layman's words:

A. O/C principle means that specialization must be done by extending, not by modifying a class to accommodate for specialized needs.

B. Adding missing ( not specialized ) functionality means the design was not complete and you have to add it to the base class, obviously without violating the contract. I think this is not violating the principle.

C. Refactoring doesn't violate the principle.

When a design matures, say, after some time in production:

• There should be very little reasons to do so ( point B ), tending to zero over time.
• ( Point C ) will always be possible although more infrequent.
• All new functionality is supposed to be a specialization, meaning the classes must be extended (inherited from) ( point A ).

In layman's words:

A. O/C principle means that especialization must be done by extending, not by modifying a class to acommodate for especialized needs.

B. Adding missing ( not especialized ) functionality means the design was not complete and you have to add it to the base class, obviously without violating the contract. I think this is not violating the principle.

C. Refactoring doesn't violate the principle.

When a design matures, say after sometime in production:

• There should be very little reasons to do ( point B ), tending to zero over time.
• ( point C ) will always be possible although more infrecuent.
• All new functionality is supposed to be an specialization, meaning the classes must be extended (inherited from) ( point A ).

In layman's words:

A. O/C principle means that especialization must be done by extending, not by modifying a class to acommodate for especialized needs.

B. Adding missing ( not especialized ) functionality means the design was not complete and you have to add it to the base class, obviously without violating the contract. I think this is not violating the principle.

C. Refactoring doesn't violate the principle.

When a design matures, say, after some time in production:

• There should be very little reasons to do so ( point B ), tending to zero over time.
• ( Point C ) will always be possible although more infrecuent.
• All new functionality is supposed to be an specialization, meaning the classes must be extended (inherited from) ( point A ).

In layman's words:

A. O/C principle means that especialization must be done by extending, not by modifying a class to acommodate for especialized needs.

B. Adding missing ( not especialized ) functionality means the design was not complete and you have to add it to the base class, oviously without violating the contract. I think this is not violating the principle.

C. Refactoring doesn't violate the principle.

When a design matures, say after sometime in production:

• There should be very little reasons to do ( point B ), tending to zero over time.
• ( point C ) will always be possible although more infrecuent.
• All new functionality is supposed to be an specialization, meaning the classes must be extended (inherited from) ( point A ).

In layman's words:

A. O/C principle means that especialization must be done by extending, not by modifying a class to acommodate for especialized needs.

B. Adding missing ( not especialized ) functionality means the design was not complete and you have to add it to the base class, obviously without violating the contract. I think this is not violating the principle.

C. Refactoring doesn't violate the principle.

When a design matures, say after sometime in production:

• There should be very little reasons to do ( point B ), tending to zero over time.
• ( point C ) will always be possible although more infrecuent.
• All new functionality is supposed to be an specialization, meaning the classes must be extended (inherited from) ( point A ).