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.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.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?In this specific case, you should absolutely not be inheriting theProgram
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 theProgram
class. For such an application, you might have the initialisation code in theProgram
class in one or more methods, then put the meat of the application functionality in other classes. YourMain
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 anExceptionNotification
class with aFormat
method. Anywhere in your application, you can then callExceptionNotification.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 namedExceptionNotifier
and a method namedNotifyFormat
. You could then have other methods namedNotifyX
, 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 callTryParse
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.
Ahh right okay! i'll take a look into that. Thankyou for your replyWelcome 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.
No, not OK. If that method is needed in places other than theSo 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?
Program
class then it should be somewhere other than the Program
class that is accessible to the Program
class and any other class that needs to use it.