|
Eddy Vluggen wrote: What would common sense do?
lol, for me common sense would be to avoid complicating things unnecessary. His idea is to work with "enterprise" applications. Performance is not his main concern (read, not important).
I can agree on an "enterprise" application if it is a large one, but for a simple module (most of them are) I'm not seeing the added value.
Looks to me like we're using a bazooka to kill the mosquito 
V.
|
|
|
|
|
Or wanting everything to be done the same way, every time, whether it's a large or small project.
I guess that has its points.
|
|
|
|
|
That's what he gives as a reason, but IMHO he just wants to put his mark on the team/company.
V.
|
|
|
|
|
Hey!
I'm just doing some research for the next project.
Can you provide me some imformation about Data Fusion? Is there a general approach on how to handle the data and how to combine it to get homogeneous?
regards
Torsten
I never finish anyth...
|
|
|
|
|
|
THAT is what I was searching for - +5 & a big thank you
regards
Torsten
I never finish anyth...
|
|
|
|
|
Hi! Can somebody explain to me why we use a Base interface as a return type in a Factory interface?
Second question in concerned with the code in Main.
I figured out that Factory factory = new ConcreteFactory2() is a reference to the implementation of a ConcreteFactory2 of GetObject() method. What is the next line?
Thanks. I appreciate your help!
abstractfactory
{
class Program
{
static void Main(string[] args)
{
Factory factory = new ConcreteFactory2();
Base obj = factory.GetObject();
obj.DoIt();
}
}
}
interface Factory
{
Base GetObject();
}
class ConcreteFactory1 :Factory
{
public Base GetObject()
{
return new Derived1(); // do we return an instance of derived 1 interface?
}
}
class ConcreteFactory2 : Factory
{
public Base GetObject()
{
return new Derived2();
}
}
interface Base
{
void DoIt();
}
class Derived1 : Base
{
public void DoIt()
{
Console .WriteLine("Derived 1 method");
}
}
class Derived2 : Base
{
public void DoIt()
{
Console.WriteLine("Derived 2 method");
}
}
|
|
|
|
|
Can somebody help me with this?
It's for my colledge presentation and I have to figure it out.
Thanks!
|
|
|
|
|
The abstract factory pattern is explained fairly well here:
http://en.wikipedia.org/wiki/Abstract_factory_pattern[^]
It returns Base as the object type because different factories will return different types of object, but those objects must have something in common.
Imagine a VehicleFactory interface with a method GetVehicle that returns a Vehicle. One type of VehicleFactory might be a PetrolVehicleFactory, that returns vehicles that run on petrol. Another might be an ElectricVehicleFactory that returns electric-powered vehicles. Both of these return type Vehicle, so I can use the factories interchangeably without having to worry about whether it is an ElectricVehicle or a PetrolVehicle that is being handed to me.
VehicleFactory myFactory = new PetrolVehicleFactory();
Vehicle myVehicle = myFactory.GetVehicle();
myVehicle.Start();
myVehicle.DriveOffIntoTheSunset();
I can swap PetrolVehicleFactory for ElectricVehicleFactory, and nothing else in my application needs to be changed:
VehicleFactory myFactory = new ElectricVehicleFactory();
Vehicle myVehicle = myFactory.GetVehicle();
myVehicle.Start();
myVehicle.DriveOffIntoTheSunset();
As long as ElectricVehicle and PetrolVehicle both do what a Vehicle is supposed to do, I don't care what exact type of Vehicle the factory gives me. I just want a Vehicle so that I can drive off into the sunset. It's the factory's responsibility to know what type of Vehicle to make and how to make it.
|
|
|
|
|
A nice, clear and concise explanation; have a 5. 
The best things in life are not things.
|
|
|
|
|
Thank you for your explanation. It's a lot clearer.
Could you just explain the client code?
I mean is Vehicle myVehicle = myFactory.GetVehicle();
a reference to GetVehicle?
Thanks
|
|
|
|
|
The variable myVehicle holds a reference to the Vehicle object returned from the GetVehicle() method.
|
|
|
|
|
Thank you for the answer!
I did well at my presentation! 
|
|
|
|
|
Hi!
I'm new to this forum, so I say hello to everyone!
My question about state diagram is about object states. How are they represented in code?
Are those methods or something else?
And I have another question about operations.
Are operations methods?
I didnt find many pages on google concerning these things so I decided to ask on this forum.
Thank you for your help!
|
|
|
|
|
A state diagram describes the state your program or a sub section of the program is in. So the implementation of a state diagram could be anywhere and everywhere, sorry to be so unspecific.
If your state is specific to one class in the entire application it could be a big switch or if block in the controller for that specific class, think about a car where you have an engine management class responsible for changing gears. The EngineManagement class could contain the switch or if block where each state calls different methods on the GearSystem and Throttle classes.
Also read up on the 'Software Implementations' section on the Finate-State machine, this describes with some examples on how you could implement a state diagram.
|
|
|
|
|
Ok!
Thank you for your help!
|
|
|
|
|
Take a look at this.
If this is the type of state diagrams you are talking about then you can make 1 type of implementation as follows in code:
1) Create a class e.g. MyState.
2) Add a string property State with a private setter and a public getter.
3) Add a public transition method e.g. Transition that takes an argument e.g. Target
4) Let the transition method set property State to Target.
If you instantiate MyState, you have the means to encapsulate a state diagram into an object.
Identify the transitions in other code and let those transitions call Transition of MyState.
In this setup you have a state object that is able to report the state of others.
Sometimes you see MyState as a property on another object. Sometimes MyState is just part of another object.
The later means that an object e.g. MyFoo encapsulates its own state information, which is quite a virtue in OOP.
Example: As a OOP developer you expect that a File object is able to tell if its read-only or closed. You don't want to shop around by other objects to figure that out.
If MyFoo not only encapsulates its state information, but also its state transitions, then MyFoo becomes quite handsome.
In this case the Transit method must implement all possible transitions with their conditions and throw an exceptions (or similar), if it cannot make a transition.
If you let MyFoo make some transitions by it self then it becomes partly autonomous.
If MyFoo becomes 100% autonomous then make the transition method private.
Usually the Transition method is a set of methods e.g. File.Open, File.Close, etc.
Usually the State property is an enum or similar. Some OOPs prefer however the State pattern.
Regards,
Keld
|
|
|
|
|
Thats's great.
Thank you for the post!
|
|
|
|
|
I was wondering what the best practises are for stored procedures. Basically, I'm still struggling with a kind of code explosion that occurs when writing code that's related to the database. In the end, what I need to do is move data into and out of the database while sometimes performing transformations and doing error checking along the way. I've found over and over again that it takes a lot of code to do this.
I'm curious if stored procedures are a good way to abstract out of code such things as queries, inserts, updates, etc., and move them into the database itself.
In a way, this relates to a thread I created here a few months ago about database code. I'm trying to get a handle on how to deal with complexity. I'm finding that database programming is largely procedureal in nature, so I'm not finding my experience with Object Oriented programming and patterns to be of much use.
|
|
|
|
|
I believe that the database and the stored procedures, or functions should only be used to guard data constraints. So they can be useful when you insert data into one row that always needs to be verified against another table, when a foreign key alone does not describe the full nature of the relation. For example one row depends on a range of rows existings in a foreign key. Another good reason to use them is to guarentee sequential execution of data insertion or deletion across multiple instances of the application.
From what I understand from your question you might be better of abstracting inside the code first by generating generic classes responsible specific parst of the applictions communicating with the database.
|
|
|
|
|
Leslie Sanford wrote: I was wondering what the best practises are for stored procedures. Basically,
I'm still struggling with a kind of code explosion that occurs when writing code
that's related to the database. In the end, what I need to do is move data into
and out of the database while sometimes performing transformations and doing
error checking along the way. I've found over and over again that it takes a lot
of code to do this.
Learn to use existing frameworks. Dynamic ones or generated static ones.
Database code is often something that is very amenable to those types of implementations.
Myself I have been write database layer code generators for years.
Additionally other common functionality is easily assigned into the same layer generation types. For example one can generate field generation code that validates such things a existence, length and even pattern for use in things such as GUI code.
Some of this is something that you are more likely to gain an advantage by learning to write your own code generators.
Leslie Sanford wrote: I'm curious if stored procedures are a good way to abstract out of code such
things as queries, inserts, updates, etc., and move them into the database
itself.
Yes. For the same reason that one create any layer code - to abstract the user from the implementation.
Leslie Sanford wrote: I'm finding that database programming is largely procedureal in nature, so I'm
not finding my experience with Object Oriented programming and patterns to be of
much use.
Relational databases have a very long and successful history. For a reason.
So avoid the inclination to even attempt to make it OO. There are in fact ways to do that and it is unlikely that it will lead to positive versus negative results.
You start with a data model. Then you use stored procs and the database layer to translate the relational model into an OO model. Just as you do with any other translational layer.
As a final note don't get to wrapped up in where the "best" place is for business logic. As an example don't avoid uniqueness keys in the database simply because that is expressed as a business rule. The database can implement that just as well, and probably better for standard business cases, versus attempting it in the database layer.
|
|
|
|
|
All,
Recently I have been doing a lot of thinking about where to invest my training time over the next 5 years. I am perplexed.
I do primarily Winforms development now, I have a couple of commercial products, with some ASP .net. I am ready to update my skills and have been trying to decide where to place that investment. Should I do WPF,Silverlight? Should I do Mono? Should I just give up on MS and do C++?
I think the reason for the quandary is that in all my research there are a number of people saying the MS is going to abandon this or that technology. I am all for learning what I need to in order to do my work but I don't have the desire to learn every piece of crap that MS puts out.
I am a pragmatist and I want to learn to a level of excellence what I need to do my work. I have a couple of large commercial products that I want to position on the correct platform but I can't be rewriting 100k lines of code at every MS whim.
Recently I have been thinking about just moving everything to C++ but that seems like a daunting task.
Anyway any constructive suggestions would be appreciated.
|
|
|
|
|
Conversations that I've had with some of the MS insiders recently suggest that the following are worthwhile technologies to invest in:
HTML 5 (this includes the WCF vNext, CSS 3, JavaScript and ASP.NET MVC)
Silverlight
WinC++
WPF (it's still going strong).
With HTML 5, you'll have a very transferrable skill because while there's an MS flavour, HTML 5 is not MS specific.
|
|
|
|
|
Thanks Pete. That was a good info to have.
|
|
|
|
|
You're welcome. I just wish MS would state their position clearer, then there wouldn't be this fud.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
