I've just made myself up a problem and am now wondering how to solve it.
To begin with, I'm using some third-party components, including some calendar controls like schedule and timeline. They're used in the project classes more or less like that:
Friend Class TimeBasedDataView
'some members
End Class
Friend Class ScheduleDataView
Inherits TimeBasedDataView
Public Schedule As Controls.Schedule.Schedule
'and others
End Class
Friend Class TimeLineDataView
Inherits TimeBasedDataView
Public TimeLine As Controls.TimeLine.TimeLine
'and others
End Class
(Hmm, code coloring fail, never mind...) Now, to allow managing the look of data being presented there are some mechanisms including so called Style Managers. A lot of code in them repeats, varying almost only with the control it maintains:
Friend Class TimeLineStyleManager
Private m_TimeLine As TimeLineDataView
Private Sub Whatever()
m_TimeLine.TimeLine.SomeProperty = SomeValue
End Sub
End Class
Friend Class ScheduleStyleManager
Private m_Schedule As ScheduleDataView
Private Sub Whatever()
m_Schedule.Schedule.SomeProperty = SomeValue
End Sub
End Class
I was wondering if I could create some base class for those managers, like
Friend Class TimeBasedCtrlStyleManagerBase(Of T As TimeBasedDataView)
Private m_Control As T
'and others
End Class
which would unify these two, but I've got lost when it came to maintaining two components that have nothing in common (except their properties' names, etc.). Type reflection maybe? I'll be grateful for any advice ;)
Looks like you've got a case where you're looking to introduce inheritance, where it's not needed - it would've been better if the third party controls all adhered to a common interface (and then generics may have saved the day), but as they're third party, I'd assume that you have minimal impact on future direction of it.
You've done exactly the right kind of thing - inheritance and generics is perfect for this situation - but I would make the TimeBasedCtrlStyleManagerBase class MustInherit/abstract and then simply inherit down your two specific managers.
All common management code goes in the abstract base class and any specific code goes in the two specific managers.
Of course you'll need to change Private m_Control As T to Protected m_Control As T for this to work.
Friend Class TimeLineStyleManager
Inherits TimeBasedCtrlStyleManagerBase(Of TimeLineDataView)
End Class
Friend Class ScheduleStyleManager
Inherits TimeBasedCtrlStyleManagerBase(Of ScheduleDataView)
End Class
Related
I have a situation where I have several VB.NET Modules in the same Logical-Module of a large application.
I would like the update function of each module to be public, but I would like users to be forced to qualify the function call with the module name.
ModuleName.Update()
instead of
Update()
Is this possible?
Thanks.
No.
The VB.NET specifications automatically use Type Promotion to allow this behavior to occur. The only way to avoid this is to have a type at the namespace that has the same name (Update) which would prevent (defeat) the type promotion provided in VB.NET.
Yes, it is possible, if you are willing to wrap the module within a namespace of the same name as the module:
Namespace ModuleName
Module ModuleName
...
End Module
End Namespace
Using modules is usually a poor design, because its methods become visible directly in the name space.
Consider replacing them with Classes. Put Shared on all the members:
Class ClassName
Public Shared Property SomeData As Integer
Public Shared Sub Update()
End Sub
End Class
Update would be referenced as:
ClassName.Update()
Make it impossible to instantiate, by having a Private instance constructor (is NOT Shared):
Private Sub New()
End Sub
Any needed class instantiation can be done like this:
Shared Sub New()
... code that runs once - the first time any member of class is accessed ...
End Sub
We have this:
Friend NotInheritable Class ConcreteGraphFactory
Inherits AbstractGraphFactory
Public Shared ReadOnly Instance As New ConcreteGraphFactory()
Private Sub New()
MyBase.New()
End Sub
Friend Overrides Function Create() As AbstractGraph
Return New ConcreteGraph()
End Function
Private NotInheritable Class ConcreteGraph
Inherits AbstractGraph
Private ReadOnly Question1 As New Question("Why isn't this showing a warning?")
Public Overrides Function GetRoot() As IRoot
Return Question1 '<---HERE
End Function
Public Sub New()
End Sub
End Class
End Class
And I have IRoot:
Friend Interface IRoot
Inherits IQuestion
Function GetContainer() As AbstractGraph
End Interface
And finally Question:
Public Class Question
Implements IQuestion
' code....
End Class
Why would VS not show a warning? Question does not implement IRoot...
If you want the compiler to give an error there, then you need to set Option strict to On. You can do that on the Compile tab of the project's Properties. Or add Option Strict On to the top of the file that contains this code.
Here are a few pages that have more details about what Option Strict means.
http://support.microsoft.com/en-us/kb/311329
https://msdn.microsoft.com/en-us/library/zcd4xwzs.aspx
Option Strict Off means that the Visual Basic compiler doesn't enforce strict data typing. It will try to do implicit type conversions and throw run time errors if that can't be done.
I didn't think it had anything to do with IRoot being an interface, but after trying it out it looks like it does. If GetRoot returned a class that Question didn't inherit from, then you would get a compiler error even with Option Strict off.
Running with Option Strict off actually makes some things easier, especially when dealing with late bound COM objects. For the most part, you don't have to worry about type casts when writing code.
However, it's also one of the reasons many people don't like VB.NET. Personally, I liked it when I was working with it, but it's been long enough now that it does seem strange that the compiler wouldn't be doing all the strict type checking for you. I could always tell when some VB code had been generated via a conversion tool from C# because it would have a bunch of DirectCast calls that you wouldn't see in code that a VB developer had written.
When C# came out with the dynamic keyword in 2009, the VB.NET developers were thinking, "Meh. We've always been able to write code without worrying about types." Of course, VB.NET wasn't the same as dynamic in C#, but many of the early dynamic code examples were showing things that you could already do in VB with option strict turned off.
Whats the difference between these two initialization methods for obj? I've seen both of these, but know know if there is an appropriate time to use one vs the other. I found this post which covers C#, but not sure if the same applies to VB.Net.
Public Class Class1
Sub New()
End Sub
Dim obj As New Object
End Class
vs
Public Class Class1
Sub New()
obj=New Object
End Sub
Dim obj As Object
End Class
My apologies ahead of time if this a duplicate.
In this case, there is no difference. The main difference would be if your constructor does other operations -
In that case, the inline initialization (Dim obj As New Object) will occur prior to any code inside the constructor. Putting the initialization in the constructor lets you choose the order of initialization.
Virtually nothing is different about these samples. In both cases you get the following order of operations
Constructor for Class1 is called
Base constructor (Object in this case) is called
Field obj is assigned a value
In all likely hood it results in identical IL being generated.
Your first version is "declarative". The advantages of it are:
It is easier to see how an field as initialized, as you don't have to look for it in the constructor.
If you have multiple constructors you don't need to repeat yourself.
Your first version is "imperative". The advantages of it are:
You control exactly when it gets created.
You can have different versions for each constructor.
I personally default to declarative style code whenever possible.
Beginner question. How come I can do this:
Public Class Form1
Private StudentsInMyRoom As New ArrayList
Public Class student
Public name As String
Public courses As ArrayList
End Class
Private Sub btnCreateStudent_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnCreateStudent.Click
Dim objStudent As New student
objStudent.name = "Ivan"
objStudent.courses = New ArrayList
StudentsInMyRoom.Add(objStudent)
End Sub
End Class
But I CANNOT do this:
Public Class Form1
Private StudentsInMyRoom As New ArrayList
Public Class student
Public name As String
Public courses As ArrayList
End Class
Dim objStudent As New student
objStudent.name = "Ivan"
objStudent.courses = New ArrayList
StudentsInMyRoom.Add(objStudent)
End Class
In the second example, all of the objStudent.etc get squiggly underlined and it says "declaration expected" when I hover over it. It's the same code except now it is not tied to clicking a button. Can't figure out what is the difference.
It's because the implementation needs to be in a method, the way you have it means the code couldn't possibly be executed, how would you reference this code from elsewhere?
It doesn't have to be tied to a click however:
Private Sub AnyNameYouLike
Dim objStudent As New student
objStudent.name = "Ivan"
objStudent.courses = New ArrayList
StudentsInMyRoom.Add(objStudent)
End Sub
Will work.
Rather than tell you how to fix this code directly, I'm going to explain what I think is going wrong with your thought process, so you can also do a better job writing code in the future.
What I see here is a simple misunderstanding for someone new to programming of how classes work. When you build and define a class, you are not (yet) allocating any memory in the computer, and you are not yet telling the computer to do anything. All you are doing is telling the computer about how an object might look at some point in the future. It's not until you actually create an instance of that class that anything happens:
Public Class MyClass
Public MyField As String
End Class
'Nothing has happened yet
Public myInstance As New MyClass()
'Now finally we have something we can work with,
' but we still haven't done anything
myInstance.MyField = "Hello World"
'It's only after this last line that we put a string into memory
Classes can only hold a few specific kinds of things: Fields, Properties, Delegates (events), and Methods (Subs and Functions). All of these things in the class are declarations of something, rather than the thing itself.
Looking at your samples, the code from your second example belongs inside of a method.
If you want this code to run every time you work with a new instance of your class, then there is a special method, called a constructor, that you can use. That is declared like this:
Public Class MyClass
Public MyField As String
'This is a constructor
Public Sub New()
MyField = "Hello World"
End Sub
End Class
However, even after this last example you still haven't told the computer to do any work. Again, you must create an instance of the class before the code in that constructor will run.
This is true of all code in all .Net programs anywhere. The way your program starts out is that the .Net framework creates an instance of a special object or form and then calls (runs) a specific method in that form to sort of get the ball rolling for your program. Everything else comes from there.
Eventually you will also learn about Shared items and Modules, that can (sort of) break this rule, in that you don't have to create an instance of the object before using it. But until you are comfortable working with instances, you should not worry about that too much.
Finally, I want to point out two practices in your code that professional programmers would consider poor practice. The first is ArrayLists. I can forgive this, because I suspect you are following a course of study that just hasn't covered generics yet. I only bring it up so you can know not to get too attached to them: there is something better coming. The second is your "obj" prefix. This was considered good practice once upon a time, but is no longer fashionable and now thought to be harmful to the readability of your code. You should not use these prefixes.
I know that it is poor programming and architecture when you have a class object that is only to be used in one place. But I've also been warned about creating an object that is all powerful and that can do too much. So how do I break this down? Here is an example of what I mean - please don't take these things literal as this is only an example.
Anyway I have an object that I am working with which is rather complex. A lot of information is stored in this object and it can perform much manipulation on the data. So, let's call this object Earth.
Public Class Planet
Private _population As UInteger = 0
Public ReadOnly Property Population() As UInteger
Get
Return _population
End Get
End Property
Public Overridable Sub CreatePerson(Optional ByVal numberOfPeople As Integer = 1)
_population += numberOfPeople
End Sub
End Class
Simple enough so far. But I could go on and on with the many things that object could possibly perform. So, in order to keep things from getting too complex I broke down "activites" that would happen during the day and during the night by creating two other Objects: Day and Night (these two are not shown). So now I have an updated Planet class.
Public Class Planet
Private _population As UInteger = 0
Private _day As New Day
Private _night As New Night
Public ReadOnly Property Day() As Day
Get
Return _day
End Get
End Property
Public ReadOnly Property Night() As Night
Get
Return _night
End Get
End Property
Public ReadOnly Property Population() As UInteger
Get
Return _population
End Get
End Property
Public Overridable Sub CreatePerson(Optional ByVal numberOfPeople As Integer = 1)
_population += numberOfPeople
End Sub
End Class
Now, these two classes - Day and Night - will never be used outside of the Planet class. Is this a good way to organize my methods and attributes for this "parent" class Planet? How else would I neatly organize similar?
I've read about refactoring but I don't think this helps my case. I like the idea that I can call on an Planet object like this: Earth.Night.BlowUpMoon.
Think in terms of discoverability. If someone else were to use your object would they know that they have to go to a specific time of day to blow up the moon, which is the same as BirthdayCard.September25th.Send()? Any by "someone else" I also include you in 6 months. Are you organizing for the sake of organizing or are you putting similar methods and properties together in a way that makes sense?
Although your example is contrived, this situation is common practive in Domain Driven Design. Your Planet class would be an aggregate - a root object that manages its own internal entities. Outside the aggregate boundary all interaction is via the root aggregate object.
Refactor your class and split it to several smaller classes, each with a single responsibility. It doesn't matter that each of them will only be used once - the code will still be better, easier to understand, and far more testable.