I have done a web site project in PHP using mySQL at school, which was not object oriented but that was in a manner on which I want to display my content. Then I changed the same project into object orientated classes where I use same CRUD queries in functions of that classes and they interact with a DBWrapper class. Or can say, I just cut the php content and pasted it into the functions and and call that functionality through object. that all was done without documentation. But now i am making a project in .net with documentation how ever its a web based app actually and i have the idea of getting data from database trough queries and o of course c# is different but CRUD is something which is similar in any language. so as i had decide first this thing will display and from thing the next this thing will display etc. about codding than how should i know my class diagram is the same as what i am getting and what that actually is. because i will connect both classes as i wnt to display . and plus is Do we write object of other class as an attribute of second class if that is going to use in it.
Most class diagrams I've seen and made include only the business model entities. Most of the time UML diagrams are used to communicate and document the workings of the system. I like to think of them as pseudo-code.
Please refer to this other question as well: https://softwareengineering.stackexchange.com/questions/190429/what-classes-to-put-exactly-in-a-class-diagram
However, if you feel your implementation ended up with a lot of helper classes then it's probably good to review your system's structure to make sure you are coding "object oriented". Actually making the class diagram is supposed to help you realize what you can improve.
I suggest you also take a look at design patterns. This link might be useful, as you mention experience with C# http://www.dotnettricks.com/learn/designpatterns
A diagram I made in the Microsoft Paint program to better understand PHP Objects.
Ok, so I have been reading up on php objects recently and they are becoming quite confusing the more i get into interfaces and encapsulations. I also seem to be confusing classes and objects, but now I am fairly certain that (as my diagram shows) Classes are actually "bigger" than objects, if you will- that objects are just new instances (or occurrences) of a class. I am aware of the crudeness of my drawing, but can anyone out there tell me if i am on the right track? I also referred to "interface" between properties and methods because, as i understand it, interface is the process by which methods (or functions within an object) can alter properties in some way. Correct me if i'm wrong.
In the book I'm reading "Learning PHP, MySQL & JavaScript: with Jquery, CSS, and HTML5" by Robin Nixon (5 Stars), I was given an example on creating and interacting with an object. I tried to alter the code (which was originally created to deal with 'Users' on a social media network) to instead echo out to the browser that 2 objects in the "Married" class would be Maj Kanaan, the Husband ($object1) and Wife Kanaan, his Wife ($object2), but with 3 properties: first_name, last_name, and title (husand or wife). However after trying several different things i came to believe that arrays should be used in this situation or at least the __construct method, but i am missing something big here. Can anyone help? Please and thank you. I really have no code to post as an example because everything i tried was way off so i just deleted it all. All i have in my feeble explanation. Hope someone is able to work with that. Thanks again!
-your friend Maj
"Classes are actually "bigger" " not certain where you are going with that but no. Quoting a title a professor forced on one of my early programming classes "Objects have class". Classes describe objects, objects are instances (actual manifestations of) classes. Classes are just a blueprint that don't do anything at all. Objects don't exist without that blueprint. You might find Differences between object and class in php useful.
Interfaces are actually templates for classes. A class can implement an interface. It's not really a go between methods and properties, but defines a set of properties and methods that a class that implements it should have defined. Most of the time one wouldn't need to use an interface unless you are working with libraries or similar shared code.
I have been given the class names, properties, and methods.
I'm not sure what the relationships are between them, so I'd appreciate it if someone can correct me below before I start drawing:
Games has a one to many relationship to Sport. Sport has a one to many relationship with Event.
Event has a one to many relationship with Race.
And Heat and Final are subclasses of Race.
What do you think?
What you have sounds like a pretty good foundation - I think you've captured the relationships pretty well. It seems to me to more of a data model than a class model per sé.
To fill your class diagram out, ask yourself the following questions:
What information do I want to be accessible from outside the system?
Who (or which class) is responsible for retrieving and collating this information? Should I be able to access Events directly, or should I access them via the Sport they belong to?
What questions should each class be able to answer about the information it knows? Then provide methods that answer those questions.
Post your solution in the question so we can see what you come up with :)
I've been starting to get into game development; I've done some tutorials and read lots of articles but one thing I'm not sure about is what is the best way to manage large numbers of temporary objects, e.g. bullets.
Should each entity manage its own bullets, should I have a global bullet manager or should I create each bullet as a new full-blown individual object (that seems pretty inefficient though)?
Also, when using a component pattern what should I do about properties that seems generic, e.g. position, velocity, etc..?
Some stuff I've read seem to think that everything should be in some kind of component while others seem to think that generic properties that will be commonly accessed by a variety of components should be a member of the entity class itself.
Forgive me, these are probably simple but I want to make sure I'm thinking in the right direction.
Thank you very much!
Creating each bullet as a "fully blown object" shouldn't be too inefficient - have a look at the Object pool pattern, which outlines a way to speed up these object creations.
As for your question re: components and generic properties, it depends on how strictly you wish to follow the component architecture. If you want to be really strict with the component architecture, every property should be in a component and different components should talk to each other. Otherwise, for efficiency reasons, share some properties in the main object. For more information, have a look at this page on the component behavioural pattern.
The original Quake uses a fixed-size pool for entities (which are also sometimes called edicts). Anything whose existence persists between frames is an entity. This includes "shaped physical" things like the world and doors, rectangular physical things like monsters, players, and nails, movetype-transparent things like weapons, invisible but touchable rectangular things like trigger fields, and entirely-nonphysical things like delay events.
I think the limit in Quake is something like 700 edicts; the game will crash if the limit is exceeded. I think edicts are simply stored in an array, since every property which exists for any edict exists for all of them.
Coming up with good, precise names for classes is notoriously difficult. Done right, it makes code more self-documenting and provides a vocabulary for reasoning about code at a higher level of abstraction.
Classes which implement a particular design pattern might be given a name based on the well known pattern name (e.g. FooFactory, FooFacade), and classes which directly model domain concepts can take their names from the problem domain, but what about other classes? Is there anything like a programmer's thesaurus that I can turn to when I'm lacking inspiration, and want to avoid using generic class names (like FooHandler, FooProcessor, FooUtils, and FooManager)?
I'll cite some passages from Implementation Patterns by Kent Beck:
Simple Superclass Name
"[...] The names should be short and punchy.
However, to make the names precise
sometimes seems to require several
words. A way out of this dilemma is
picking a strong metaphor for the
computation. With a metaphor in mind,
even single words bring with them a
rich web of associations, connections,
and implications. For example, in the
HotDraw drawing framework, my first
name for an object in a drawing was
DrawingObject. Ward Cunningham came
along with the typography metaphor: a
drawing is like a printed, laid-out
page. Graphical items on a page are
figures, so the class became Figure.
In the context of the metaphor, Figure
is simultaneously shorter, richer, and
more precise than DrawingObject."
Qualified Subclass Name
"The names of subclasses have two jobs.
They need to communicate what class
they are like and how they are
different. [...] Unlike the names at
the roots of hierarchies, subclass
names aren’t used nearly as often in
conversation, so they can be
expressive at the cost of being
concise. [...]
Give subclasses that serve as the
roots of hierarchies their own simple
names. For example, HotDraw has a
class Handle which presents figure-
editing operations when a figure is
selected. It is called, simply, Handle
in spite of extending Figure. There is
a whole family of handles and they
most appropriately have names like
StretchyHandle and TransparencyHandle.
Because Handle is the root of its own
hierarchy, it deserves a simple
superclass name more than a qualified
subclass name.
Another wrinkle in
subclass naming is multiple-level
hierarchies. [...] Rather than blindly
prepend the modifiers to the immediate
superclass, think about the name from
the reader’s perspective. What class
does he need to know this class is
like? Use that superclass as the basis
for the subclass name."
Interface
Two styles of naming interfaces depend on how you are thinking of the interfaces.
Interfaces as classes without implementations should be named as if they were classes
(Simple Superclass Name, Qualified Subclass Name). One problem with this style of
naming is that the good names are used up before you get to naming classes. An
interface called File needs an implementation class called something like
ActualFile, ConcreteFile, or (yuck!) FileImpl (both a suffix and an
abbreviation). In general, communicating whether one is dealing with a concrete or
abstract object is important, whether the abstract object is implemented as an
interface or a superclass is less important. Deferring the distinction between
interfaces and superclasses is well >supported by this style of naming, leaving you
free to change your mind later if that >becomes necessary.
Sometimes, naming concrete classes simply is more important to communication than
hiding the use of interfaces. In this case, prefix interface names with “I”. If the
interface is called IFile, the class can be simply called File.
For more detailed discussion, buy the book! It's worth it! :)
Always go for MyClassA, MyClassB - It allows for a nice alpha sort..
I'm kidding!
This is a good question, and something I experienced not too long ago. I was reorganising my codebase at work and was having problems of where to put what, and what to call it..
The real problem?
I had classes doing too much. If you try to adhere to the single responsibility principle it will make everything all come together much nicer.. Rather than one monolithic PrintHandler class, you could break it down into PageHandler , PageFormatter (and so on) and then have a master Printer class which brings it all together.
In my re-org, it took me time, but I ended up binning a lot of duplicate code, got my codebase much more logical and learned a hell of a lot when it comes to thinking before throwing an extra method in a class :D
I would not however recommend putting things like pattern names into the class name. The classes interface should make that obvious (like hiding the constructor for a singleton). There is nothing wrong with the generic name, if the class is serving a generic purpose.
Good luck!
Josh Bloch's excellent talk about good API design has a few good bits of advice:
Classes should do one thing and do it well.
If a class is hard to name or explain then it's probably not following the advice in the previous bullet point.
A class name should instantly communicate what the class is.
Good names drive good designs.
If your problem is what to name exposed internal classes, maybe you should consolidate them into a larger class.
If your problem is naming a class that is doing a lot of different stuff, you should consider breaking it into multiple classes.
If that's good advice for a public API then it can't hurt for any other class.
If you're stuck with a name, sometimes just giving it any half-sensible name with commitment to revising it later is a good strategy.
Don't get naming paralysis. Yes, names are very important but they're not important enough to waste huge amounts of time on. If you can't think up a good name in 10 minutes, move on.
If a good name doesn't spring to mind, I would probably question whether there is a deeper problem - is the class serving a good purpose? If it is, naming it should be pretty straightforward.
If your "FooProcessor" really does process foos, then don't be reluctant to give it that name just because you already have a BarProcessor, BazProcessor, etc. When in doubt, obvious is best. The other developers who have to read your code may not be using the same thesaurus you are.
That said, more specificity wouldn't hurt for this particular example. "Process" is a pretty broad word. Is it really a "FooUpdateProcessor" (which might become "FooUpdater"), for example? You don't have to get too "creative" about the naming, but if you wrote the code you probably have a fairly good idea of what it does and doesn't do.
Finally, remember that the bare class name isn't all that you and the readers of your code have to go on - there are usually namespaces in play as well. Those can often give readers enough context to see clearly what your class if really for, even if its bare name is fairly generic.