|
Public Sub New()
MyBase.New
End Sub
Sort of implied anyway - but the fun fact is that the class that has this constructor doesn't actually explicitly inherit anything...so Mybase is object.
(Fortunately the compiler just ignores this so no actual harm done)
|
|
|
|
|
|
Zen coding.
cheers
Chris Maunder
|
|
|
|
|
Duncan Edwards Jones wrote: Fortunately the compiler just ignores this so no actual harm done
Which proves that we already have machine that outsmarts the men... 
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
When I see code like this, I sometimes suspect it may have been copied/pasted from a De-Compiler (such as IL Spy). I mean why on earth would someone go to the trouble of typing that?
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Yeah - or it could be a stub left behind when whatever extra work used to go on in the constructor was removed...or worst of all it may be a cargo cult coding issue.
|
|
|
|
|
I write constructors such as that. Only when I have multiple constructors though.
At least when you're going to change that code to call another constructor you know the call to the base class's constructor is gone (and probably going to be the default).
I'd rather write too much code (such as access modifiers even though they're the default) and make sure everyone knows I really wanted to call that constructor or have that access modifier than write too few and accidentally use a default I didn't intend. Especially since I switch a lot between VB and C# and both have different defaults.
Like a co-worker who doesn't write access modifiers. When I confronted him about it he said "everyone knows the default is public!". Turned out the default was internal 
|
|
|
|
|
Yet another disastrous example from the VB6 project I'm porting. In many ways this one is truly eye-popping...
(Note, the code is paraphrased to avoid spilling "secrets" (like anyone would steal this carp)).
Dim con As ADODB.Connection
Sub DoSomething()
...
con.BeginTrans
...
On Error GoTo MyRollback
... Various statements that insert records ...
con.CommitTrans
...
Exit Sub
MyRollback:
MsgBox Err.Description
con.RollbackTrans
Resume Next
End Sub
So, if an error is detected, the current transaction is aborted but the code then attempts to write the remaining inserts anyway - only not outside of a transaction.
Of course it all goes pear-shaped when the Commit is attempted, but by that stage a whole bunch of detritus will have accumulated in the database.
And as there are pretty well no relationships in this DB, there's nothing preventing those records being utterly invalid (and they will be).
I predict a monumental data cleanup task approaching!
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Whoah - are we working on the same system? 
(I saw a bit of code that detects is a record exists by attempting to insert it and trapping the error - of course, it traps any SQL error so if the record doesn't exist but you haven't passed in the mandatory fields we just assume it does...)
|
|
|
|
|
That sounds like the same culprits.
I wonder if there's a "special" team of programmers who travel the world sabotaging projects.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Guild of Master Underground Programmers (GUMP)
They're actually part of small group (paid for by a hidden tax in you pay) that goes out to deliberately code to make large amounts of guaranteed employment for other coders.
[Applications for membership have been outsource]
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
And its always good to keep that transaction locked while waiting for the user to dismiss the message box.
|
|
|
|
|
How do you even know enough to know you should use transactions and not realise that this code is a massive WTF?
|
|
|
|
|
I know. Your emotion may be even worse if you got to see some of the code I've substituted with ...
It's a shame I cannot use the old Asterix code: @%*%£&$!!!
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
New PM!
He has strong (& abysmal) opinions about development. That I just can't follow, that's bad.. 
What to do!?!
Some example
All business class have all private constructor and private setter properties.
They have a public static Create() method (mind you it's not a factory method, only create instance of that particular class)
To set properties (when we pass the business object to the persistence layer) we use Automapper, which override the private attribute using reflection
This afternoon we spend 2 hours to refactor 20 lines of code (in 2 method) that I had written (it was working) We had to stop because of time, but 3 classes, 6 methods, 200 lines of code later the new "improved" version was still not operational (improved version we have to duplicate at all time)
And mind you this new "improved" version is not reusable. Only improve these particular 20 lines. I have to DUPLICATE the improved version for every single method I write... I just CAN'T DO IT!    
|
|
|
|
|
Sounds like she/he wants the business classes to be immutable[^] - not a bad idea if parallelism is likely/needed but overkill otherwise.
|
|
|
|
|
Now explain the static create method.
|
|
|
|
|
Again - a common part of the immutable pattern. If there is only one way you can create a class from outside then you have complete control over its creation...
What I don't understand is why the persistence layer needs to access the private members - why aren't the properties you need from the business class exposed as readonly?
|
|
|
|
|
Now explain the difference between the constructor and the static method, keeping in mind that the static method is not a factory.
thing is, the only way to have SOME control over how an object is created is using the constructor. AutoMapper and Serialization don't even know about your method.
|
|
|
|
|
That is the rub - auto-mapping and serialization of the business objects is the issue. Business objects shouldn't be persisted - there should be a specific shearing layer with its own classes for that (a repository or data access layer for example).
|
|
|
|
|
Just like Sentenryu, constructor will be just as good for immutability.
Better, they are overridable if you create a subclass
And before you said 'haha, this prevent subclassing', there is the 'final' keyworkd for that!
|
|
|
|
|
The only language I can think of that the create method would be useful is C++ for use with templates and pointers, but it would have to be an instance method, so you can take a Base* and create an instance of the right derived type.
I guess it could be useful for the same reason on C# or Java, but i see less reason to use it on those languages.
|
|
|
|
|
Quote: New PM!
He has strong (& abysmal) opinions about development.
Project Manager? The PMs I have worked with never knew anything about code. Their job was to manage the customer mostly.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
Right, sounds more like a micro-manager to me.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Haha, that must be it! ^^
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
