|
I don't know, and I'm interested in the replies you will get.
I guess the fitting quote will be this one:
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
|
|
|
|
|
ruanr wrote: should I be super-abstracting my data?
This is exactly what I recently found I needed to do using a MS TreeView and a STL-like Tree container.
I set out wanting a series of low level instructions to be sequentially sent to a cell of electro/mechanical devices including a robot arm and other automated bits of laboratory kit. But wanted to give the User control of this instruction sequence by presenting them with simple control buttons much like those of a Video or DVD player: Forward, Pause, Step and Stop. But critically I also wanted to be able to undo/redo the instructions and add Back and Step-Back to those options presented to the User.
I also wanted to be able to eventually throw away my development GUI and have someone then integrate what was left into a nice shiny Application GUI alongside all the other bells and whistles needed.
I found a tree view was the 'natural' way to display to the User and the MS TreeView Control did this, but it didn't do other things I wanted so found another STL type Tree container class that I could use to accomplish the other things.
ruanr wrote: Design patterns always sound so good in theory
I based each instruction to a device on a combination of Design Patterns: Command and Do/Undo so that a Do-instruction could be loaded into a Leaf (of the STL-type tree) with a corresponding Undo-instruction. Of course I had to link the corresponding nodes on the View tree to the Container tree but this wasn't that difficult.
Though non-'super-abstraction' is tempting, separating the view from the the actual data like this I've found to be an essential development approach. From so many perspectives: Project-Management; Maintenance or Further-Development, separation like this turns one problem to two nicely defined smaller ones, reduces the overall complexity and makes the whole much cleaner, more likely to actually work and much more understandable to others.
|
|
|
|
|
ruanr wrote: Am I using the wrong design architecture?
Only if you are overdesigning. It's ideal if you have a complex datasource, lots of developers, and/or lots of different ways of visualizing the data. If you're only displaying a list from Microsoft Access and asking the user to select an item therefrom; by all means, just databind it.
As a question to you; what benefits do you gain from using an MVC/MVP pattern, and what benefits would you have without this design?
I are Troll 
|
|
|
|
|
ruanr wrote: at some point, will have to manipulate items in a grid
As I understand it, to perform tasks like manipulating items in a grid, we will be using constructs like Commands and Attached Behaviours (at least in WPF and Silverlight).
However, I would be curious to know the best ways to do this in ASP.Net.
Me, I'm dishonest. And a dishonest man you can always trust to be dishonest.
Honestly. It's the honest ones you want to watch out for...
|
modified on Sunday, March 28, 2010 11:43 AM
|
|
|
|
|
I think there are 2 distinct levels of understanding with data binding. The newbie uses the MS wizardy things and is led into the mire of controls bound directly to the dataset/table etc.
This lasst until they actually want to do something beyond displaying an Access list for the user to select from, at which point the new dev finds a whole new universe of DAL, object layer, OOP and all the stuff a more seasoned developer already deals with. Then the learning really begins.
IMHO tightly coupled controls have absolutely no place in anything but a learning/prototype application. MS is doing the newbie a great disservice even creating the wizardy things.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Looking for any good software development magazines to help keep me informed. Anyone have any suggestions?
|
|
|
|
|
www.code-magazine.com
Everything makes sense in someone's mind
|
|
|
|
|
One of our clients are looking to develop LMS for SCM and Sales departments.. here are the requirements specified by them:
Technical
Primary systems: Flash and Adobe Captivate
Other: We will be rolling out an SAP LMS (learning management system) soon and would like to understand how LMS are supported technically
Content
What does the story boarding process look like?
What are the capabilities around instructional design and graphic design?
It will be very helpful if someone provides their ideas..
Regards,
Chiranjeevi
|
|
|
|
|
So let me get this straight: you've taken on a job for which you have no prior experience and not a clue as to how to proceed and you want one of us to tell you what to do? What have you already done to understand the requirement? What money, as a business, have you invested in bringing on board or acquiring the requisite skill sets to accomplish the task? Does the client know that you're asking these questions?Tychotics
"The dinosaurs became extinct because they didn't have a space program. And if we become extinct because we don't have a space program, it'll serve us right!"
Larry Niven
|
|
|
|
|
Hi,
I have question regarding architecture when dealing with composition/aggregation hierarchy. The three classes below "House", "Room" and "Door" describes a simple nested architecture used for this question. This architecture means that when I use a House object and want to refer to a door nested in a Room I will brake the "Law of demeter" rule that states that I should only use direct connection like House.ToString() not indirect connection like House.Room.Door.ToString(), is this okay or bad practise, is there any better way of organising the architecture?
Would it be better to do helper functions for the door in the Room Class, and not expose a Door object public, like:
DoorOpen();
DoorClose();
If this arhitecture is prefered, what should be done with the events inside the Door class, should they also be defined once again in the Room class and be "chained" back thru it's parent classes some way ?
Any thoughts, tips and ideas would be helpful.
public class House
{
public House()
{
Room = new Room();
}
public Room Room { get; private set; }
}
public class Room
{
public Room()
{
Door = new Door();
}
public Door Door { get; private set; }
}
public class Door
{
public event EventHandler<EventArgs> OnOpen;
public event EventHandler<EventArgs> OnClose;
private bool _isOpen;
public Door()
{
}
public void Open()
{
_isOpen = true;
OnOpen(this, new EventArgs());
}
public void Close()
{
_isOpen = false;
OnClose(this, new EventArgs());
}
}
|
|
|
|
|
I don't know if this will help you or not, but internal doors will be shared - two rooms will both have the same door that opens and closes between them.
|
|
|
|
|
yep. Give Room a public CloseAllWindows() method and let it keep the windows to itself.
(I substituted windows for doors, to keep Graham happy).
|
|
|
|
|
It's correct a Rooms will share a door in my example, but it was just ment as an example
So let's continue and consider a window class instead. What happends if I have alot of member data in my Window class should I still use the class 'Window' as a private member inside 'Room' and make "wrapper" Methods and events inside Room like: Room.CleanWindow(int index), Room.OnWindowCleaned(), Room.OpenWindow(int index). etc etc. Sort of chaining methods and events.
This seems to duplicate Methods and Eventsin a way, thoughts about this ?
|
|
|
|
|
One advantage of using "wrapper" methods is that you can use them to do things that the Window class doesn't know about:
class Room {
public:
void OpenWindow(int index)
{
try {
plants[index].Remove();
windows[index].Open();
plants[index].Replace();
} catch(DroppedPlantPotException& dppe) {
CleanTheFloor();
}
}
private:
std::vector<Window> windows;
std::vector<PlantPot> plants;
};
|
|
|
|
|
To model the real world it seems to me as if you should have a WindowCleaner class which has a public method CleanWindows(House) and which should fire events. Maybe WindowCleaner inherits from WindowOpener or a class Person who is a WindowOpener? The room is pretty inanimate, it's the people who do things - unless this is a very high tech house.
|
|
|
|
|
There are various patterns that you could apply here, but the one that immediately springs to mind here is that you could use a Mediator here. Depending on the implementation of the Mediator, what you might want to do is:
public class Door
{
public Door()
{
}
public void Open()
{
_isOpen = true;
Mediator.Instance.NotifyColleagues(DoorState.Open);
}
public void Close()
{
_isOpen = false;
Mediator.Instance.NotifyColleagues(DoorState.Closed);
}
}
public class House
{
private int _ambientTemperature = 22;
public House()
{
Mediator.Instance.Register((object o) => { _ambientTemperature -= 2; }, DoorState.Open);
Mediator.Instance.Register((object o) => { _ambientTemperature += 2; }, DoorState.Closed);
}
}In this example, House is decoupled from Door; it registers an interest in the DoorState messages and reacts accordingly without any events having to tunnel up. It's the responsibility of the Mediator to route the message to the appropriate targets, so everything becomes nice and decoupled - more importantly, this is easily testable. If you want a sample Mediator, this is based around the one I use here[^]."WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Thanx for the responses.
The classes "House", "Room", "Door" was just an example, I'm not looking for designs to solve the specific design of a House which have a CleanWindow method.
I will try to rephrase my question.
The question is about nested class architecute with composition/aggregation, it could be anything that tries to model the real world, but in this specific question it's not important what it is, just that composition/aggregation is uesd, see below for examples of nested class structures, maybe these aren't the best examples but there must be valid relationsships like this in reel world:
Computer/Cpu/Processor
Database/Table/Column
The question is should I use, which sort breaks the law of demeter:
Computer.Motherboard.Cpu.Temperature();
Computer.Motherboard.Cpu.IsOverheated();
Or should I make "Motherboard" and "Cpu" private and wrap/chain method calls and events thru the nested structure:
Computer.CpuTemperature()
Computer.CpuIsOverheated()
I hope the question is clearer this time.
|
|
|
|
|
Based on this[^] your first example pair fails due to "too many dots".
|
|
|
|
|
Ok, So it will be a benefit to make nested classes private and create extra code for wrapper methods and events in the main class for this sort of architecture instead of make a direct connection to the Cpu object?, will this even be true if I referenced Motherboard and Cpu as interfaces ?
|
|
|
|
|
DiiJAY wrote: Ok, So it will be a benefit to make nested classes private and create extra code for wrapper methods and events in the main class for this sort of architecture instead of make a direct connection to the Cpu object?
Yes. Using Computer.Motherboard.Cpu.IsOverheated() means the calling code has to know about not only Computer class but also the the Motherboard and Cpu classes as well. Using just Computer.CpuIsOverheated() means the caller doesn't know about, or care, how the temperature is obtained internally.
As an example of the benefit, if you upgraded your PC with a motherboard that had 4 parallel CPUs the call to Computer.CpuIsOverheated() will still work from the caller's perspective. Internally the new motherboard code might average out the temperature of the 4 CPUs but this internal change is hidden from the caller. With this upgrade the Computer.Motherboard.Cpu.IsOverheated(); call runs into problems: Which of the 4 CPUs does this call refer to?
DiiJAY wrote: will this even be true if I referenced Motherboard and Cpu as interfaces ?
Interfaces I use to refer to a set of related methods, if you wanted the temperature of, say, a Car, Room and a PC an ITemperature interface with a ITemperature.GetTemp() method would be handy but you would still want to hide your Motherboard and Cpu classes for the reasons already mentioned.
|
|
|
|
|
Thank you Jonathan, that made the picture clear!
|
|
|
|
|
|
All very true and all good advice. However, the danger is that your Computer interface is going to become very bloated. Consider that a computer contains not just a motherboard and one or more CPUs, but also hard drives, a USB bus (plus any USB devices which may or may not be connected), a floppy drive (if your computer is as old as mine), a graphics card, a network card, a sound card, RAM, etc. etc. etc. (I'm sure you can think of a few more components.)
Exposing every possible operation for every possible component through the Computer class interface leads to a very unwieldy design. The danger is that your Computer class becomes a sort of "god" object which tries to do everything and be all things to all men.
There are no hard and fast rules for object design. There is a certain amount of give and take to end up with the best solution, balancing one consideration against another.
|
|
|
|
|
I agree. In general I'm all for an architecture designed someone who recognises there can be rules there in the first place. Investigating what the Law of demeter is (I knew the principle but not the actual rule) and why it's used, and why in other cases it's perhaps not used, can only be a good thing.modified on Tuesday, March 9, 2010 5:41 AM
|
|
|
|
|
I'm a C#.Net programmer and what I like to do is separate classes that only hold data and those that have functionality.
I like that architecture because it's clear cut and I can immediately find any data or method and don't have to think long about it or search around where some method is.
I think it's a good approach for multitier architecture, so when I'd change the database I wouldn't have to change all classes but only the ones that handle db connection.
On the other hand I'm not quite sure if that's really object oriented programming.
For example I need to read some data about hotels out of a db, edit it and write it back. I'd have a hotel class and a dbconnection class.
The hotel class only holds data like rooms, prices, etc. without any methods (except for a deep copy method I add to all my classes) and dbconnection class has all the methods.
I can't really see the advantage of adding the methods for connecting to the db to the hotel class, but that would be actual oop, while I'm doing something close to procedural programming or?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
