Resolved Is it bad to inherit from the main program in another class?

sock1992

Well-known member
Joined
May 20, 2020
Messages
107
Programming Experience
Beginner
in one of my classes I've inherited the main program. I just wanted to get another persons opinion on this. Is that bad practice or is it okay?
 
Last edited:
Welcome to the wonderful art of software engineering and API/class design.

Many years ago when people were still trying to figure out object oriented programming, people primarily used inheritance to avoid duplicating code, but back in the procedural programming days, duplicating code was a known bad practice. As people used object oriented programming more, people figured out that using inheritance just to save on code was actually a poor practice because it leads to tightly coupled and fragile class hierarchies. If you modified something on the ancestor classes, you needed to make sure that you didn't break anything in the descendants. If you need to re-use code, the modern practice is to always prefer aggregation over inheritance.

In general, take time to learn the SOLID object oriented programming principles. These will help guide as you make your design decisions.
 
In this specific case, you should absolutely not be inheriting the Program class that VS adds by default. That class should be the entry point for the application. If your application is very simple then you might put all the code in that one class. As your application gets more complex, you can move functionality out to other classes and use them in the Program class. For such an application, you might have the initialisation code in the Program class in one or more methods, then put the meat of the application functionality in other classes. Your Main method would then call the initialisation method first and then create and use the other class(es) as required. In your case, you might have an ExceptionNotification class with a Format method. Anywhere in your application, you can then call ExceptionNotification.Format. That's how it's supposed to work.

EDIT: Actually, I realise that I misinterpreted that method name. Maybe you would have a class named ExceptionNotifier and a method named NotifyFormat. You could then have other methods named NotifyX, where X is the name of the type of exception you're notifying for.

That said, I hope you're not really getting an exception thrown because the user didn't enter a number. If you're working with numeric user input then you should call TryParse on the appropriate numeric type to validate and convert in one step. In that case, invalid input would not generate an exception so a type or member name that implies that it does would be inappropriate.
 
Last edited:
In this specific case, you should absolutely not be inheriting the Program class that VS adds by default. That class should be the entry point for the application. If your application is very simple then you might put all the code in that one class. As your application gets more complex, you can move functionality out to other classes and use them in the Program class. For such an application, you might have the initialisation code in the Program class in one or more methods, then put the meat of the application functionality in other classes. Your Main method would then call the initialisation method first and then create and use the other class(es) as required. In your case, you might have an ExceptionNotification class with a Format method. Anywhere in your application, you can then call ExceptionNotification.Format. That's how it's supposed to work.

EDIT: Actually, I realise that I misinterpreted that method name. Maybe you would have a class named ExceptionNotifier and a method named NotifyFormat. You could then have other methods named NotifyX, where X is the name of the type of exception you're notifying for.

That said, I hope you're not really getting an exception thrown because the user didn't enter a number. If you're working with numeric user input then you should call TryParse on the appropriate numeric type to validate and convert in one step. In that case, invalid input would not generate an exception so a type or member name that implies that it does would be inappropriate.
Thank you for the reply. So If im trying to access a method from the Main Program e.g TurnNumberintoInt from within the ExceptionNotification class I can do Program.TurnNumberToInt and that would be okay?

Yeah i've done that :) these notification messages aren't anything to do with user input. The exceptionNotification class includes all the notification messages of other exceptions such as file read error etc.
 
Welcome to the wonderful art of software engineering and API/class design.

Many years ago when people were still trying to figure out object oriented programming, people primarily used inheritance to avoid duplicating code, but back in the procedural programming days, duplicating code was a known bad practice. As people used object oriented programming more, people figured out that using inheritance just to save on code was actually a poor practice because it leads to tightly coupled and fragile class hierarchies. If you modified something on the ancestor classes, you needed to make sure that you didn't break anything in the descendants. If you need to re-use code, the modern practice is to always prefer aggregation over inheritance.

In general, take time to learn the SOLID object oriented programming principles. These will help guide as you make your design decisions.
Ahh right okay! i'll take a look into that. Thankyou for your reply :)
 
So If im trying to access a method from the Main Program e.g TurnNumberintoInt from within the ExceptionNotification class I can do Program.TurnNumberToInt and that would be okay?
No, not OK. If that method is needed in places other than the Program class then it should be somewhere other than the Programclass that is accessible to the Program class and any other class that needs to use it.
 
Back
Top Bottom