My thoughts on C#
-
The Managed Extensibility Framework. It's a built-in way to make composable applications in C#, and can double as a dependency injection mechanism. It's not terribly hard to use, but might be a little more overhead than you want to deal with when you're starting out. [Managed Extensibility Framework (MEF) | Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/framework/mef/)
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
Thanks Nathan. MEF looks like another branch in the NET framework tree like WPF. It's good to know that it exists. I'll take a closer look at it with the link and code you provided thanks. Brian
-
You know, here's a much easier way, which is basically using a global in C# without the work. I just don't advise it in general, but it does have uses:
public class SomeClass
{
public static string SomeValue = "This is a Value";
}public class SomeOtherClass
{
public string LocalValue = SomeClass.SomeValue;
}"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
Thanks Nathan. Looks like a lot less code. Is there a reason why you advise against using this type of code? Brin
-
Brian_TheLion wrote:
I'm being drawn towards C++ as it does allow global variables compared to C#. I know that it's not good to use global variables and most variables should remind within their own class but it's not always easy to design a program like this and the program I have in mind that I want to write has many varables between classes.
Yeah, that's not how you do that. There are a few approaches that are valid from a C# point of view, but by and large a variable in the global namespace is never the answer unless the language itself forces that on you (thank you, JavaScript). There are better tools: a static container class, a service locator, or best of all dependency injection.
Brian_TheLion wrote:
I have in mind that I want to write has many varables between classes. I could write it with less classes but I want to have classes for certain purposes that can be reused in other programs. It also makes the program easier to deal with when changes are made.
Good OOP uses many, many classes that work in conjunction to build a system.I suggest you take some time to learn about [SOLID Programming](https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design). Global variables also make maintenance much, much harder in complex software. Modern IDEs have made this a little less significant, but for good, flexible software you should still prefer composability to imperative structure.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
Hi Nathan. I just noticed your link to "SOLID Programming". There are some good examples at that site thanks. Brian
-
Thanks Nathan. Looks like a lot less code. Is there a reason why you advise against using this type of code? Brin
Largely because it's hard to maintain, and very common to forget that you stuck a static property on an object 3 years ago when you first wrote the code. It can also lead to unexpected object states when you can change a static property from outside that object, and proper value validation logic - let alone proper state checks - is often ignored in accessors. Lastly, it's simply not an OOP approach. It's an old-school method that is more-or-less a legacy of structured programming. Yes, static properties are very cool when used to modify the behavior of a genus of objects on the fly, but that's simply not what we're doing here. IMO if you find yourself writing software like this you're not thinking about it in a way that will lead to a good end result. If you're just learning it's fine. Use it as a tool to make something that works. Just keep in the back of your mind that you're learning the skills to do it better the next time, and that how you conceptualize your code will have a huge impact on how good your code ends up being.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
Brian_TheLion wrote:
I'm being drawn towards C++ as it does allow global variables compared to C#. I know that it's not good to use global variables and most variables should remind within their own class but it's not always easy to design a program like this and the program I have in mind that I want to write has many varables between classes.
Yeah, that's not how you do that. There are a few approaches that are valid from a C# point of view, but by and large a variable in the global namespace is never the answer unless the language itself forces that on you (thank you, JavaScript). There are better tools: a static container class, a service locator, or best of all dependency injection.
Brian_TheLion wrote:
I have in mind that I want to write has many varables between classes. I could write it with less classes but I want to have classes for certain purposes that can be reused in other programs. It also makes the program easier to deal with when changes are made.
Good OOP uses many, many classes that work in conjunction to build a system.I suggest you take some time to learn about [SOLID Programming](https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design). Global variables also make maintenance much, much harder in complex software. Modern IDEs have made this a little less significant, but for good, flexible software you should still prefer composability to imperative structure.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
Just one quest question Nathan. You gave me a link to SOLID Programming. In the code examples at that site they use a dollar sign in front of a variable. What's the reason for this? Brian
-
Just one quest question Nathan. You gave me a link to SOLID Programming. In the code examples at that site they use a dollar sign in front of a variable. What's the reason for this? Brian
He's using PHP for his demo. The concept of SOLID applies to all OOP languages. IIRC that's just a required convention in PHP, but it's been a minute since I worked with it.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
-
Largely because it's hard to maintain, and very common to forget that you stuck a static property on an object 3 years ago when you first wrote the code. It can also lead to unexpected object states when you can change a static property from outside that object, and proper value validation logic - let alone proper state checks - is often ignored in accessors. Lastly, it's simply not an OOP approach. It's an old-school method that is more-or-less a legacy of structured programming. Yes, static properties are very cool when used to modify the behavior of a genus of objects on the fly, but that's simply not what we're doing here. IMO if you find yourself writing software like this you're not thinking about it in a way that will lead to a good end result. If you're just learning it's fine. Use it as a tool to make something that works. Just keep in the back of your mind that you're learning the skills to do it better the next time, and that how you conceptualize your code will have a huge impact on how good your code ends up being.
"Never attribute to malice that which can be explained by stupidity." - Hanlon's Razor
OK Thanks. Brian
-
Brian_TheLion wrote:
Having used programs like Quick Basic over the years makes it more difficult to break free from the procedure programming method
I, too, started on procedural languages like FORTRAN, COBOL and BASIC and initially found the Object Oriented way seemed artificial, clunky and back-to-front. Now, having spent several years in an OO environment, I can see the benefits and would never go back to the old ways. It can be hard to unlearn things that work and to undo your mental images of how things interact, but it is worth it in the long run. I'd suggest that you park your adventure game and write something from scratch, forcing yourself to use the OO paradigm (horrible word) and then evaluate what worked well and what seem odd. Then revisit your adventure game looking at the objects (players, inventory items, rooms) and seeing how they map onto classes and then look at their properties (inventory items are-in rooms, players -have- inventory items, players are-in rooms, rooms are-adjacent-to- other rooms) then look at methods that change the properties (players move-to rooms).
Good advice thanks jsc42. My Text adventure program is more involved than a simple game so it might be better to try writing some less challenging programs first such as a number guessing program to get some practice. Brian
-
Your quest for the "ultimate programming language" seems to be an adventure game in itself. Except you're ignoring all the clues left by those that have come before you. Assembler PC Basic Lattice C (MS C) dBase Clipper VB Cirrus (MS Access V1) FoxPro ... C#
The Master said, 'Am I indeed possessed of knowledge? I am not knowing. But if a mean person, who appears quite empty-like, ask anything of me, I set it forth from one end to the other, and exhaust it.' ― Confucian Analects
Hi Gerry. You wrote: Your quest for the "ultimate programming language" seems to be an adventure game in itself. Except you're ignoring all the clues left by those that have come before you. Assembler PC Basic Lattice C (MS C) dBase Clipper VB Cirrus (MS Access V1) FoxPro ... C# I'm not certain what you mean. The commands that past languages have in common are things like If, then, else, etc Brian
-
Hi Richard. It's more of understanding what I have read. so if I still don't understand it then I ask questions. You can't ask a book questions. Not all books give a clear understanding on C#. Lets take an example: A book will tell you that the 'set' command is to set a value and the 'get' command is to get a value, but it fails to tell me why I need to use the set and get commands. Why not just have Name = "Peter" like some programming languages, so I'm thinking when and why should I use these commands; some C# code does not use the get set commands. After doing some research on the internet and studying example code I now have a better idea on how these commands are used. It's also sometimes the way something is explained that makes it easier to understand. I downloaded and started to read Net book zero a few weeks ago, I must take another looks at this book. Thanks for the reminder. Brian
Brian_TheLion wrote:
Why not just have Name = "Peter"
That is exactly what it now has. As I said before, repeated studying will help to make things clear. But you also need to understand that programming languages are continually evolving, so some older guides may not include the latest changes.