|
Hello,
I have a situation where I have a cycle:
Group <>---- Contact
..........-----<>
I have the class Contact which has name (eg. John), addr, etc.
And the class Group which has a name (eg. Friends) and a list of contacts List<contact>
The thing is that I want the Contact to know what groups contain him
For example lets say I have the groups Family, Friends, Job and they all contain John (and others)
I want that these groups contain John and that John knows he is member of these groups.
I want to avoid the cycle,
Should I use an Interface? or maybe other solution?
modified on Wednesday, April 15, 2009 6:14 PM
|
|
|
|
|
|
I don't see the problem.
A Group holds zero, one or more Contacts.
and each Contact wants to hold a list of all the Groups it belongs to.
So a Group either *is* a list, or *contains* a list.
and a Contact contains a list.
IIRC that is called aggregation: putting information (list of Groups) in members of the class (Contact).
Refinement: I didn't provide type information for the lists; it could be that:
a Group either *is* a list, or *contains* a list of Contacts.
and a Contact contains a list of Groups.
or you could define a common ancestor for Group and Contact, and use that type as the type held in both lists (Inheritance).
Conclusion: I don't need interfaces to "break" the cycle, there wasn't really a cycle if you ask me.
If you insist on having an interface, how about IListable; both Group and Contact implement IListable (not sure what the functionality would be though); and both lists could contain IListables.
|
|
|
|
|
Hi, thanks for replying!..
"there wasn't really a cycle if you ask me."
The cycle is between Contact and Group.. We've been told in University that we have to avoid these cycles because of dependency and coupling (which I don't see but was hoping that someone here could tell me)..
An example where I can see the solution more clearly is for example a Car that contains an Engine, and the Engine must notify the Car that contains him something..
One solution, the one I have to avoid is: Car contains Engine, Engine contains Car
In that case one would put an interface ISomething (Car : ISomething) and the Engine instead of having a Car would have an ISomething
The difference might be that the Engine must do something on the Car (turn it on for example). And here, the contact doesnt have to do anything on the group and viceversa.
Am i right? Should i go with the cycle anyway?
|
|
|
|
|
In the car-engine situation, I would do:
car contains an engine, and is fully aware of its functionality, not its internals of course.
engine knows nothing about cars, but holds one or more public events (.NET speak), where an event is a list of delegates, a delegate basically is a function pointer or a callback.
So the car tells the engine it is interested in some events;
the car engine signals those occurrences through the appropriate event, without knowing anything about the subscriber(s); all it knows is the syntax of the delegate (number and type of parameters, there normally is no return value).
Again no interface is involved; although you could achieve the same with an interface (your ISomething, I would say IAmInterestedInSomeEngineStuff). The advantage of events is they can hold and serve multiple listeners without the engine even being aware of that.
modified on Thursday, April 16, 2009 11:06 PM
|
|
|
|
|
In my opinion, also if you ask your profs, you should avoid cyclic dependencies between assemblies but not between classes. You should try to minimize coupling but you can not avoid it altogether. Afterall, the classes need to communicate with each other to accomplish whatever needs to be accomplished.
You can create an interface and you can always do so but remember you still have a cyclic dependency but it is less direct. Now you are tied to something which implements the interface.
If you never want to allow contact creation without group, then do not allow its creation unless from within the group: Contact c = aGroup.NewContact() and Group will call contact's constructor.
Cyclic dependency is bad between assemblies because of compilation race.
CodingYoshi
Visual Basic is for basic people, C# is for sharp people. Farid Tarin '07
|
|
|
|
|
Interesting topic. It is very frustrating when interfaces express very complicated dependencies between objects. Cyclic dependencies may result in endless loops and weird state control.
An interface specifies a unidirectional 'control panel': You can use it to push and pull, but you have the initiative and don't want be interrupted while using the interface. However, if cycles exist between interfaces (or between objects), you may be interrupted each time you try to operate a certain object via an interface. If this happens a lot, you have spaghetti code.
Our world is full of interconnected objects that control each others, so what to do about these when modeling them in software? A very simple example is a Nut and a Bolt. Sometimes the Nut turns the Bolt and sometimes the Bolt turns the Nut.
Lets say an interface for both Nut and Bolt is ITurnable and it contains a turn(float angle) method. No interface cycle exists.
Now, if Bolt is turned, it decides whether an attached Nut should be turned or not.
Likewise, if Nut is turned, it decides whether an inserted Bolt should be turned or not.
These decisions are implementation specific, and it may be that Nut and Bolt call each other recursively, but the ITurnable interface is clear about direction of control.
Yes, I know. The Bolt and Nut need to be connected, if they should know something about each other e.g. friction, or if they should be able to turn each other; how could that be expressed with interfaces?
A) Interface for a made up object. You can make a fictional interface that ties a Nut and a Bolt e.g. an IConnection implemented by a 3rd class e.g. Connection. If a Nut actively unscrews itself, it will direct control to the IConnection implementor that is responsible for letting the Bolt know.
B) Interface for existing objects. You can implement an attach/detach interface for Nut and Bolt e.g. IConnector implemented in both classes. This interface could just have an attach(IConnector connector) and a detach(IConnector connector) method. Again the direction of control is clear, and it is specified via IConnector that Nut and Bolt can be interconnected.
C) Interfaces for existing objects. You can implement attach/detach in interfaces of Nut and Bolt e.g. INut and IBolt, respectively. INut could have an attach(IBolt bolt) and a detach(IBolt bolt) method, and IBolt likewise, but with INut arguments. Again the direction of control is clear, and it is explicitly specified that Nut and Bolt can be interconnected.
In my opinion, all of the above solutions could be used, and taste and priorities determine which one you would choose. Solutions B) smells of a cycle, but really just is an interdependency. I guess solution C) contains a cycle, but what to do, if you really want to avoid anything weird (very general) being connected to your Nut or Bolt?
What do you think? What does your teacher say about this?
|
|
|
|
|
I have an application that does some multiplication and division on numbers provided by clients.
After having gone through all the possible permutation and combinations.
I have a result set of about 2.5million. there number is unique based on the calculations we have to do. The 2.5million is summarised into a different unique groups totalling to 6000.
I can think of 2 ways to do this only and would like any suggetions that I have missed out in my thinking.
First is the easy way. Put the 2.5 million in a database with the coresponding group and let the database handle the optimization with the primary key. The primary key will not help since the 2.5million are unique numbers. which leads to the same thing as being dumb and use binary search from the application and store the result set in a text file and avoid the network traffic.
The second option is to use 64bits in binary and create a flag for every scenerio and try and work my way from there. Never done this before will be a good challenge however it will frustrating tried to look for some good articles on binary and was unsucessful. If you have any good articles. I would love to read up on the binary bitwise logic and algorithm.
I am having a difficult time making a decision looking for someone to shed some light.
Thanks to everyone who responds in advance.
|
|
|
|
|
Hi,
I have no idea what your app is about, however if I understood you correctly you have two phases right now, one creating millions of numbers somehow, and the second reducing that to a few thousand numbers. I would be inclined to not split that in two phases at all, avoid all storage and searching, instead calculate the numbers if and when you need them. Of course, if those calculations are really expensive then that would not be a good idea.
Anyhow, when considering two alternatives, one you fully grasp and one you are not familiar with, I would be pragmatic and go for the former unless there are good reasons to expect big advantages from the latter.
You might get more specific replies if you provide more context and more details.
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
I should elaborate more I guess.
Clients have a variable number of choices to decide what they wish to do and what there best scenerio is.
Lets say they have 50 numbers to chose from and depending on their choices there is a certain path that needs to be taken to do the calculations. I have tried all the possible combinations and permutations on this. I have come up with a static 2.5million unique numbers. Those 2.5 million numbers are grouped into 6000 and from there depending on the group the number has fallen they get their best choice for their buck.
Change the 50 to 7 to simplify -> from 7 select 5-> 21 possible ways the result of 21 from 21 pick the best. My 21 is 2.5million different combinations. Instead of doing the calculations everytime, I was thinking of creating the final 2.5million records with all possible combinations.
Initially never thought the number would be this high. The idea however was as soon as the choices were made go get the static result back and display it as opposed to doing the calculations over and over again everytime. However once the number got to 2.5 million the idea went to the shelf as it would be crazy to create a lookup function in the app with that many records.Even though we are currently doing them as soon as we get to the office in the morning.
However not willing to give up, since the calculations are done everyday. It would be worth the effort to automate it.
Hence I could only think of the 2 ways.
Hope I have clarified further.
|
|
|
|
|
OK, I'd go with the database; 2.5 million records isn't extremely high. Databases such as SQL Server are quite capable these days and I expect they will do as good a job as any dedicated app one could come up with.
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
Thank you. I will do that.
|
|
|
|
|
hi, this is good information regarding the database,
thank you also i will don that,
|
|
|
|
|
hello friends ,
i have a problem my sight working good in IE6 but its not working in IE7.in ie7 design is not right. specilly date time picker and fileupload control.some controls are on the controls..what may be the problem...?thnx in advance
|
|
|
|
|
hey, i am trying to make a new file extension, i have looked on the internet and cant find and thing. this is what I'm trying to do. when the user clicks on the .hnh it executes the exe in side of it, along side of the exe is a text file and i am aiming for the exe to write records in the text file inside of the .hnh, if someone could help or point me in the right direction that would be great.
also i was not sure where to post this if there is a better place please tell me, thanks
If at first you don't succeed
Redefine success
J.Hardy
|
|
|
|
|
Huh? You want to nest a file inside a file?
Why would you want to hide an exe inside another file type, unless you want a user to execute it without knowing it's executable? I can't imagine any reason for this that isn't a crime. Why not store the executable as an exe file, and its data file as txt? You wouldn't be thinking of writing something malicious would you? If so, this would be a really good time to go somewhere else. If not, please clarify.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
the point of it was so the people who use the .hnh dose not have to copy 7 files, just 1 .hnh if that make more sence
If at first you don't succeed
Redefine success
J.Hardy
modified on Tuesday, April 21, 2009 10:05 PM
|
|
|
|
|
Can you package the files together in an installer, and have the user install the program? That way all the need to copy is setup.exe, run it once, and then access the program from the start menu or application menu, or desktop shortcut, or whatever.
Dybs
|
|
|
|
|
i would like to avoid the installer if possible, i would like them to be able to copy the .hnh file from computer to computer without installing it
If at first you don't succeed
Redefine success
J.Hardy
|
|
|
|
|
I don't think you can do that, as far as I recall is only .EXE and .COM files can be executable in Windows/DOS (going all the way back to the beginning of time).
I have seen something similar done that is the opposite of what you're describing. Where-in you have an .exe "program" that is labeled as such, and it stores or has extra data written to it after then end of the executable code. So basically the file structure on the drive looks something like this:
"[exe header][exe executable code]||[extra data]".exe
This way, the OS can run the file, as the header, entry point of program, and all executable code addresses are retained, while the data that needs to be accessed is appended to the end. It would be up to the program to track where the end of the code was for instance:
Const FixedProgramLength = (an integer that represents how many bytes the exe code is)
Const StartOfDataAddr = FixedProgramLength + 1
The only other way I could think of to make a .hnh file executable would be to make an axillary service that would be running prior (at startup) and somehow initiate the executable code stored within. (Similar in concept to Java .jar files, in that without the Java Runtime library installed and running the OS doesn't know that it's a program of any kind).
However, I would venture that the first solution would be the easiest... And besides, as mentioned, there's no good reason that a program should have a different extension that isn't unethecal
|
|
|
|
|
that sounds great! could you point me to some articles on how to do that please (first solution)
If at first you don't succeed
Redefine success
J.Hardy
|
|
|
|
|
After a break to clear my head and read some more, I'm back to trying to develop a simple database program for my own use at work. Rather than continue with my previous project, I'm starting fresh.
The problem - track the purchase, installation, maintenance, and movement of three types of equipment for a power company. Simple, right? I thought so, but maybe not simple enough for me yet.
One approach I tried was to have the user select one of the main functions - Add, Edit, Move, Service - from the main form, then use hide/show to move to a subform for that function. My thought at the time was to then use a string of dialog boxes to walk the user through the selection of the target equipment, enter the data required (it changes depending on the equipment type), then return the data to the subform for updating the database. In my thinking, that would make it easy to simply "Add another?" from the base subform. That got rather complicated, and I got lost.
The next shot was to create forms for each function and equipment type, then walk through them depending on user selections, and updating the database through the final form in each sequence. Not only is that wasteful (having all those forms lurking about whether needed or not) but it just strikes me as awful design. There ought to be a single point of control for the data access, a separate layer that is common to all functions. I just have no idea how to implement it.
At the moment I have a nice Main form with a side-panel menu, a .mdb database file with sample data already loaded, and a very attractive company logo in the top left corner. I also have a nagging feeling that I'm missing something important in a conceptual way, something that hours of studying MSDN and C# programming books isn't helping. The simplistic examples used in most books aren't very useful for learning how to do real world tasks - sample programs have one Form, dialogs do only one thing, then close, etc...
I've found that what I can learn from three or four helpful posts here usually exceeds what I can glean from a month or more of study, so I thought I'd give it a shot. Last time I did I received several very helpful tips that helped me a lot, and I appreciate them all. I also got a few snide, insulting comments from a few who are very active, but whose histories show that they've never once posted anything else. I've been here a long time, and I'm immune to those.
Thanks, in advance, for any helpful suggestions as to how I should structure this solution to make it as painless for me - a tyro - and as efficient as is practical for a beginner. I'm eager to learn, and it's going to make my job a hell of a lot easier if I can get this working. I'm doing it on paper now, and it's a time vampire.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Reading you was like remembering some past adventures in programming. I remember on several occasions thinking that it was just a simple solution and it turned out not to be. For myself I just stopped thinking that, pretty much ever.
That said for a nominally complex software project starting at the beginning means requirements or functional specifications, at a minimum in the form of Use Cases.
Again for a small project, you then run those through some scenarios. This results in people (in this case it sounds like you are on your own, not sure) gaining a clearer picture of the realities and a level of confidence that the requirements are complete enough to begin working on things like UI design prototypes, application architecture and finally the OO Design.
You might find this series of articles[^] helpful.
|
|
|
|
|
As always, an excellent piece of writing from Joel... Thanks for the link! It doesn't actually address my quandry, but it's a great reminder that some things never change. I was weaned on DOD-STD-2167 and MIL-STD-490, using type B5 specs. They were a pain to implement, especially for a young programmer chomping at the bit to start coding. Unit Design Folders and Interface Control Documents were a way of life, and though they weren't the fastest way to market, they remain the fastest way to market with a product that actually works. That's probably the root of my frustration with Microsoft - the shortcuts they take to be first on the shelf are the direct cause of their complete failure to release products that work correctly out of the box. The other point Joel touches on, however indirectly, is the need for technically adept tech writers, and clear documentation. Not just for the spec, but to provide pre-emptive customer support in the form of usable help and printed manuals. That was another invaluable concept killed by Microsoft.
In my old age I tend to take shortcuts - no formal specs, just a written description of what the program must do. Along with that I hand craft every screen on paper, naming each control and assigning an appropriate data type to each if it has a member that must be manipulated. I also love flowcharts - I use them in my day to day work, even though it has nothing to do with software. Every task - running errands on a weekend, for instance - can be improved by writing down the flow and optimising it to make efficient use of every step. My flowcharts start out at the top level - no detailed steps, just a written visualization of what a user would do with the program, with big blocks that contain "Do something useful and save the changes somewhere." Later I expand the blocks into their own flowcharts, constantly reducing until I can almost code each block in a line or two.
That works great if I have a clear idea of how the overall program structure should look, of what techniques are easy to implement and which are okay but tedious. There always exists more than one way to accomplish the job, but some ways are smarter than others. The architecture is critical, and that's what I was asking about. Yeah, I'm on my own here, which is why I'm asking. I've lived here 16 years and never met another person who can make a computer say "Hello world" without typing it in Word. 
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Roger Wright wrote: The architecture is critical, and that's what I was asking about.
Couple things
Roger Wright wrote: user select one of the main functions - Add, Edit, Move, Service - from the main form
User selects from Menus and toolbars, not forms.
Roger Wright wrote: The next shot was to create forms for each function and equipment type, then walk through them depending on user selections, and updating the database through the final form in each sequence. Not only is that wasteful (having all those forms lurking about whether needed or not) but it just strikes me as awful design. There ought to be a single point of control for the data access, a separate layer that is common to all functions.
The problem with that section is that you are coupling the UI design to the Code design. This is not correct. Arrive at a UI design from considering usability. The problems with code design are not related to UI design.
Now let's talk about the last part of that section.
Roger Wright wrote: There ought to be a single point of control for the data access, a separate layer that is common to all functions.
Yes, that and many other Software Design Patterns are already common knowledge. This statement can only have us conclude that you are not yet studied enough in design and patterns to understand the solutions to these problems. Furthermore trying to cover all that ground in an internet forum reply is not an appropriate reaction.
My advice is that you stop development and continue with your studies of design and patterns. As you learn well known design principles and patterns you will recognize some of them as solutions to your current problems. Well at least that's how it works for me. 
In case you have not seen these folks ( there are many others as well) here is where they share their expertise:
Martin Fowler[^]
Ward Cunningham[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
