In a base class object, I have an overridable subroutine that I would like all derived objects to have the ability to include. However, they don't have to, and if it's not necessary for them to use it, I don't want them to be forced to declare it. To enforce this, I've left the default behavior empty. For example, here's my whole sub:
Protected Overridable Sub MySubroutine(ByVal someObject As Object)
End Sub
Is this bad practice? I don't want to declare it as MustOverride, but I don't want default behavior. Is there a "better" way of doing this, or is this perfectly acceptable? I don't want to be that hack programmer... just trying to learn :)
Yes, this is perfectly acceptable. A MustOverride member can often be too strict of a requirement for an inheriting class so if you want a virtual member without default implementation this is the proper thing to do.
Anyone who is inheriting from this class will appreciate the fact that you have defined a virtual member as a "hook" into your class like this. Also the fact that you have declared this method as Protected is also a good idea as public virtual members can be problematic from a maintenance standpoint.
As a step in your learning process, you should download .Net Reflector (from redgate).
Using it will tell you a lot about how others develop their code, and how Microsoft develops the framework code. You'll learn a lot from it.
Related
I've got a class called ArtificialIntelligenceBase from which you can create your own artificial intelligence configuration sending some variables to the constructor or you can make a class that inherits from ArtificialIntelligenceBase and in the constructor of this new class just call the function super() with the parameters of the configurations.
I've also created some examples of artificial intelligences in classes, AIPassive, AIAgressive and AIDefensive. Obviously all of them inherits from ArtificialIntelligenceBase.
The point is that there're only few public functions in the base class. The variables in the base class are read only and the non public functions are protected in case you need to apply some modifications on them when created another pre-defined AI.
You can also create another AI just calling the base class sending some parameters in the constructor like this: new ArtificialIntelligenceBase(param1, param2, param3, param4);
I've tought about make the classes as a singleton because the classes can never change and once setted, their variables never change.
The question is: Is the singleton the best pattern to do this? Because I'm not sure.
PD: You don't need to explain any patter, just mention the name and I'll search for how it works
PPD: I'm developing in AS3. Just in case it helps
Thanks
In general, singletons are evil. I don't see any reason in your case to use a singleton, either. It sounds like you're using your own version of a factory method pattern (using a constructor somehow?) or maybe a prototype (I don't know AS3 one bit), but if you're looking for other patterns a couple of other ones are abstract factory and builder.
You don't need to use the singleton pattern to limit yourself to using only one instance per type of class, though. It doesn't help avoid redundancy.
Do anyone knows about the class which has the common function which we generally use while developing web application. I have no idea what you may call it, it may be the utility class or common function class. Just for reference, this class can have some common function like:
Generate Random number
Get the file path
Get the concatinated string
To check the string null or empty
Find controls
The idea is to have the collection of function which we generally use while developing asp.net application.
No idea what you are really asking, but there already are ready-made methods for the tasks you write in various library classes:
Random.Next() or RNGCryptoServiceProvider.GetBytes()
Path.GetDirectoryName()
String.Concat() or simply x + y
String.IsNullOrEmpty()
Control.FindControl()
Gotta love the intarwebs - An endless stream of people eager to criticize your style while completely failing to address the obvious "toy" question. ;)
Chris, you want to inherit all your individual page classes from a common base class, which itself inherits from Page. That will let you put all your shared functionality in a single place, without needing to duplicate it in every page.
In your example it looks like utility class - it is set of static functions.
But I think that you should group it in few different classes rather than put all methods in one class - you shouldn't mix UI functions(6) with string functions(3,4), IO functions (2) and math(1).
As Mormegil said - those functions exists in framework, but if you want to create your own implementations then I think that for part of your function the best solution is to create extension method.
if we can access the private members through setters and getters then what is the use of private?
You need the private to enforce Encapsulation. It is one of the fundamental paradigm of Object Oriented programming to keep the implementation of something separate from the interface. This reduces the coupling between your different program parts and in the long run make it more maintainable.
Take the following example :
class toto {
private String someThing;
public String getSomething();
public void setSomething(String Something);
}
If you change above to simply put someThing public, sure you have less code, but if one day that someThing needs to change to a more complex object for some new functionality while the old code could still work fine with a string then you need to change everything. By isolating the internal representation of someThing you can evolve your system much more easily
class toto {
private ComplexSomeThing someThing;
public String getSomething(){ someThing.toString();}
public void setSomething(String something){ something = new ComplexSomeThing(something);}
public ComplexSomeThing (getComplexSomething();
public void setComplexSomething(ComplexSomething someThing);
}
There are other reasons that makes encapsulation a Good Thing (tm), this is just a silly example to illustrate the point.
EDIT
There is somewhat of a debate right now as to using protected vs private or to use concepts akin to properties in some languages (Delphi, C#) rather than getters and setters (as in Java).
Protected rather than private will allow easier changes by the clients of the code but it does expose the innards of your system more so there is a balance to strive for between usability of the API and it's maintainability. However the basic principle of encapsulation remains.
Whatever the option chosen one still needs to expose functionality that is coherent and on the same level of abstraction and hide the gory details of how this is done.
To me the debate is not to declare a jihad against private but to find a way to provide extensibility and flexibility while not breaking the coherence of the API.
Here some interesting reading about private if you want to dig further. However I must stress that before forming an opinion about private you should really master the concepts of encapsulation and polymorphism, their apparent simplicity does hides some subtle complexities.
Because the getters and setters can act as a proxy. They make it so that you can hide the actual insides of the class, and only let the outside classes access the data through methods. Allowing you to treat the inners of the class however you want.
Just because your getter/setter is named getName() and your property is called name, doesn't mean it will always be that way.
What if you wanted to change the variable to be fullName. If you directly accessed public variables, the change would break a lot of code. Instead, you can simply remap where getName() retrieves its data from.
One of my best examples of this is my own URL class, where I allow for creating and manipulating a URL. If you want to set the scheme, you can get $obj->setScheme(). However, you don't know whether I am manually making the string every time you change the URL, whether I am storing them as separate parts. This gives me flexibility as I can store your data however I want to.
Furthermore, I can preform manipulations on the data before storing it. In my URL class, I assume that all schemes and host names are lowercase. I can standardize this by converting all strings saved via setHost() to lowercase, and then storing them. If I used a public variable, you would have to assume that the client that put the data in was correctly storing it.
They can also validate information that is being passed in to make sure that it is valid data, and cause an error if it isn't.
No one forces you to put in getters and setters for every variable. Indeed, blindly using private members + dummy getters & setters for every variable is pointless, even though many "object oriented encapsulation" tutorials do this all the time for some reason. For one thing, such encapsulation is no encapsulation from concurrency viewpoint.
I think what you really want to understand is why we use public properties with private backing fields, instead of just using public fields. There are several questions on SO like this; here's one:
What is the difference between a Field and a Property in C#?
I think you have good answers so far (information hiding and all that). Just want to add a suggestion about using setters.
As you mentioned using accessors makes private variables a bit pointless and in some environments performance consequence of using getters and setters just makes it worthless.
On the other hand if you don't have such concerns, I think using getters isn't so bad, but you should think twice before using setters. They make your object mutable which is especially hard to maintain in concurrent environments.
What is the best way to provide strongly typed access to the session object? I am planning on turning on Option Strict, which is causing the compiler to complain about my lazy programming technique of directly accessing the session object:
Dim blah As Integer = Session("Blah")
My initial thought is to create a class that wraps the session and provides strongly typed properties for the information stored in the session. However, I cannot decide if the class should be a singleton, or instantiated on every use, or where the code should reside (i.e. within the web project or within a class library).
I'm leaning towards a singleton in my class library, but I don't know if that is the best solution, or if I am missing any other possibilities.
Proposed Solution:
Public Class SessionAccess
Public Shared Property Blah(ByVal session As HttpSessionState) As Integer
Get
Return Convert.ToInt32(session("Blah"))
End Get
Set(ByVal value As Integer)
session("Blah") = value
End Set
End Property
End Class
Code Behind:
Dim blah As Integer = SessionAccess.Blah(session)
I deleted my original answer as #Jason Berkan made a very good point when he questioned my answer. Jason, I think this idea is fine.
The only thing I would change in your code example is to check to ensure that the session variable exists.
Either my proposal is the "standard" way to do it, or else no one wraps their session access, since this question hasn't received very many answers.
I did find one line in this answer that mentioned creating a SessionManager:
Wrap the ASP.NET Session with a
SessionManager to avoid development
mistakes in spelling, etc. when
referencing items from Session.
I have not thought of any reason to not use a singleton class to provide typed access to the session, so that is the solution I went with in the project.
I have a bunch of different forms that I would like to create a base MustInherit class for. One function I would like them all to contain is a shared function called GetForms(). I know that you can't declare a shared function MustOverride so I did the following in my abstract class:
Public Shared Function GetForms() As List(Of OrderForm)
'to be overridden in child class'
Return Nothing
End Function
And this in my child class:
Public Overloads Shared Function GetForms() As List(Of OrderForm)
'do stuff'
End Function
Will this cause problems down the line, or is this an acceptable workaround? It has a smell to it, but it will enforce that all my forms include a shared GetForms function.
EDIT I realize that if this were possible with interfaces, I would use one, but you can't declare shared functions in interfaces and I would like to make sure that this is a SHARED function.
This has a smell because it creates a false expectation of the behavior of the code.
You mention that your reason for doing this is that 'it will enforce that all my forms include a shared GetForms function'. This is only partly true. Yes, they will all have the GetForms function, but you're not actually forcing the derived classes to implement their own version of it. If you forget to implement the function on one of them, you'll be calling the base version, and you won't get any sort of warning about it from the compiler.
That is the smell: it can't actually enforce the behavior that you want, but it creates an impression, at first glance, that it can. This will lead to headaches 6 months from now when you're adding a new Form type and you've forgotten the convention. You'll get no warning that something's wrong until you start getting bad results during testing.
If you want to enforce behavior, you have to do it using instance members; using MustOverride (abstract) functions or an interface.
You can have static (Shared) methods like that, but you can't enforce the implementation of them.
Each static method is local to it's class, you can't overload it in a child class or make it abstract (MustInherit). You have to use an instance method (non-static) to get the object oriented aspects that you want.
Yes, that does smell!
Looks like you should be using an interface instead.
Here is a vb.net article: http://www.developer.com/lang/other/article.php/939411
Why wouldn't you simply declare it as:
Public MustOverride Function GetForms() As List(Of OrderForm)?
Static methods aren't inherited, so the expectation of overriding is not something we want to encourage. In other words, I think you might be barking up the wrong tree here.