|
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.
|
|
|
|
|
What exactly is meant by "WinC++"? I'd be interested into the background of this recommendation... In my (humble) opinion, the further away you get from Win32 APIs (assuming this is what you meant) the better off you might be in the future. Or did you mean the plain ANSI C++ as implemented by Microsoft?
|
|
|
|
|
If you want to know more about WinC++, this[^] article is a good place to start.
|
|
|
|
|
Unit Testing and Test Driven development are becomming more mainstream these days so definately improve in that area if need be. There is a lot of ASP work around so that could be a good direction but as a Winform developer, you may find Silverlight/WPF a more natural progression. I wouldn't throw your .NET skills in the bin. I'd work on developing them in new directions. Also LINQ, WCF and EF aren't looking like going away any time soon.
"You get that on the big jobs."
|
|
|
|
|
Porting your well-running apps to a different technology/platform is something I wouldn't suggest. It has a very heavy price that does not justify the benefits. Continue to develop/support your apps in their current platform as long as they're good to go. Porting to a different platform is something to be considered only when the current platform does not support the features required, then it makes sense to do a complete rewrite.
|
|
|
|
|
Personally to me, this is a very interesting question. Many moons ago (over 15 years), I had to make a decision similar to this. Of course, many moons ago technology choices were a little limiting with defined camps. So my decision was based on what I enjoyed doing the most? To which technology will can I see myself doing every day?
Back in the day, many may laugh and some reminisce, I was mainly doing DOS based development and before any type GUI based development. The ole command line with line numbers in BASIC when the IBM/Intel based PC was a relatively new technology. Development languages were emerging and technologies growing in all directions. Being a little seasoned, already in the in industry for several years, experience with microcomputers and main frames. I did a little of this and a little of that from desktop publishing, database development and applications on the various platforms, the question was still what do I enjoy doing every day?
I have digressed, but to make a longer story short, I did pick a technology I enjoyed. I learned every aspect of it inside and out. Like looking through the source code, understanding its design structures, how the entire system ran and relationships between the systems. I understood the system to the point where, I could make the thing sing and a cup of coffee. And I learned not just the technology or system, but I also picked up design, architecture and the appreciation of how development is an art form.
Not knowing your background the answer would be make a choice that you will enjoy doing.
|
|
|
|
|
I completely agree with you and know where you are coming from. I too 'back in the day' enjoyed every day. Today is a bit different though. We use to be able to learn a language and be pretty sure that we could compete for 5 to 10 years and we could master our craft. Today sadly it is not the same IMHO. Everyday MS gives us 14 new things that we MUST learn... **RANT OVERTED**
I have loved everyday of my life as a developer/architect for the past 25+ years. I have no intention of changing just trying to get a feel for where to bet my training time over the next 10.
Thanks
JD
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
