As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'd like to get some opinion of Naming Conventions for entity collections. In particular I'm designing a RESTful URI structure.
If I have an entity e.g. Account, I would call a collection of such entities Accounts. Similarly: Customer and Customers, Order and Orders. Generally adding an 's' to the end of the entity name. This is a consistent pattern good for a Naming Convention.
But what should I do when some plural words are not simply an 's' tagged on the end e.g. Mouse and Mice, Person and People or even Fish and Fish (plural and singular are the same)?
Should I stick with a simple pattern and just tag on a 's' irrelevant of English Language conventions, or go with the proper pluralised form of a word.
I've been tempted to name my collections e.g. PersonCollection or FishCollection but whilst consistent it is ugly and not the sort of thing I want to enter into URI which I want to be as succinct as possible.
Stick with the English language! It makes the code or the use of interfaces a lot more readable, maintainable and intuitive when somebody with a good understanding of the English language can sit down and work with it. It can be very frustrating to maintain code or interfaces that contain typos in class names, field names, URI parts, ... or other issues like using wrong plural forms as you mentioned. Therefore, I'd never use "Mouses" as the plural form for "Mouse".
Abbreviations might be of concern, too. If it's a known abbreviation, feel free to use it. However, try to keep one strict convention of naming them, like first letter is upper-case the rest lower-case, or all upper-case. Try to avoid mixing those.
Appending the type of the variable or field is like prefixing it. Depending on the programming language in question, I'd go with the general guidelines, e.g. in Java I'd remove the "Collection"-part. As far as URIs are concerned, I wouldn't use it. It doesn't improve readability.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Lately I have been struggling with method names in OOP and I decided to sort that out. For that purpose, I am trying to classify names of methods from natural language point of view. So far, I have figured out these categories:
1] Commands:
elem_list.append('x')
bank_account.deposit(50)
game.get_score()
append, deposit, get_score are commands here. You ask objects to do something (or ask interpreter to do something with them - depends on point of view). These methods contain a verb in various forms: just verb, verb + noun, verb + adjective + noun, sometimes noun + verb (to further clarify meaning of the verb). Commands are probably the most common names.
2] Queries:
connection.is_open()
snake.is_dead()
window.can_hide()
These are not so common. Their form is passive-verb + adjective (this form can be surely described better, I am not a native English guy). Basically, here you query about a state of an object.
The following are categories I am not sure about because I haven't really seen lots of method names like that (it can be my limited experience though):
3] Declarations:
button.widget_selected(event)
window.screen_changed(screen)
Here you notify an object that something has happened and expect it to do its job. The method is basically an event handler. The form is usually something like noun + passed-tense-verb. I am unsure about this category because you can transform it into a command just by prepending a verb e.g. handle: button.handle_widget_selected(event) which seems to be more natural when calling the method.
4] Noun-names
snake.crash_animation()
game.introduction()
I don't really like these because I think nouns should be reserved for data. And they can be transformed into the first category simply.
So my question is if you somehow agree with this classification and whether you consider names in the third and fourth category good or bad with respect to OOP paradigm.
I think you are looking for a style guide or coding standard.
e.g.
PEP-8 (common referred Python style guide)
Google JS styleguide
Having said that, imo it's better to be consistent throughout your coding than mixing in a style guide (stick to what you started with or refactor everything). Having your own scheme is fine, but you'd rather spend time on productivity.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been researching and looking for answers here to a problem that I suspect might be solved by a better understanding of design patterns. I think the problem is that I am a self-taught coder and people seem to tend to assume familiarity with a lot of esoteric terminology; I have ended up in Wikipedia spirals trying to determine what some phrases mean.
That said - on to the coding/structural problem.
Actually, just before I start, I should point out that I may well be making unknown presumptions in the way the code is structured in my question. If this is the case, could folks suggest alternatives to what I'm suggesting? I'd really appreciate learning how to better code as opposed to simply being told I'm doing it wrong.
OK...
Let's say we have a Room class, which has 4 Walls, a Ceiling and a Floor. These are instantiated 'inside' the Room. The Room also has a Table which has 4 TableLegs, again instantiated inside the Table, inside the Room. (This, I believe, is Composition, but please correct me if I've got that wrong!).
Finally, the problem:
If someone, somehow, pushes the Table, the TableLeg(s) will need to check the type of Floor they're standing on to trigger the appropriate sound. This, currently would be my solution:
The Table dispatches an event. The Room listens for that 'table pushed' event, quizes the Floor to determine its type, then passes that type to a method on Table, which in turn passes it to the TableLegs.
This, to me, seems fairly inelegant; hence my suspicion that knowledge of design patterns might be useful.
Is there something fundamentally wrong about the structure I've described that I'm not appreciating? If so, what is the alternative?
Finally, I have heard of the Gang of Four book. If that's my first port of call, is it written in an accessible style or will I have to have studied computer science to grasp it?
Sorry for the long, design-pattern-beginner's question.
The Floor could listen for objects Events. The Event interface could expose information about object geometry, material, etc. Then the Floor could check for collisions and play a sound.
I recommend the book Head First Design Patterns
I don't know if I can answer your question, but I can tell you something about the "Design Patterns" book.
It was an instant classic when it was published in 1994/1995. With examples in C++ and Smalltalk (there was no Java or C# back then), it listed solutions to 26 common problems in object-oriented programming. It provided a format for documenting forces and resolutions that was eagerly snapped up by academic conferences for years after. Lots of programmers, including myself, were studying it like holy writ in the hope that a single book could make them superstars.
Then reality set in.
Functional programmers said the patterns were work-arounds for flaws in OOP. What's the fuss? They could do these things without resorting to patterns.
The usual response on first reading the book is to try and fit as many patterns as you can into whatever code you happen to be writing at that moment.
You'll find yourself using the pattern names in design sessions: "I think we need a Chain of Responsibility here!"
Eventually you calm down and realize that patterns aren't the answers to your problems. The best way to use them is to think hard about your problems and solutions and suddenly realize that your answer happens to fall into a pattern.
As for your problem, I don't think you need a pattern. Have the Table send a message to the Floor to ask about its type before you generate the sound. That'll do it. Simplicity is a virtue.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
My understanding is that the fundamental tenant of OO design is that one should focus on modeling a class as the union of code and data. In day to day development, however, I tend to separate all of my business logic into classes of their own. The 'data' ends up being in tightly controlled POCOs/DTOs with basically no real code or logic. I then instantiate a business logic class and pass in POCOs to each method whenever I want an operation to occur.
But this feels like two separate approaches. In fact, the latter approach seems to be at odds with the purpose of OO!
I supposed I've always kept the two things separate since business logic may function on multiple POCOs. Plus, not forcing validation on the data in the POCOs made it easier to unit test since it seemed simpler to prepare the POCO for a test (no need to worry about internal class state, encapsulation, etc). Now that I'm looking back on those reasons, they seem weak.
I'm looking for a comparison/contrast of the two approaches. Specifically, why does it seem that making 'dumb' POCOs is the way to go these days? Why not just stick the data and the business logic into a single class? Are we abandoning the original goals of object oriented design?
Thanks!
Indeed, separating business logic from associated data goes against the principles of OOP, and this is what Martin Fowler refers to as an anemic domain model. Personally, I would always go with a proper domain model that puts data and behaviour together.
Specifically, why does it seem that making 'dumb' POCOs is the way to go these days?
I don't know why you thought this was so, but this is certainly not true. There are many "dumb" models out there, but there are also many well-designed domain models.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Currently my best tool for this is a thesaurus, but I would like to expand my horizons on the matter.
Invest in a tool that makes refactoring easier. Like in NetBeans, you can easily rename classes and variables. If you use that, you can make a mistake without much problems.
But it is wise to think about the structure of names.
A class I think of as an entity, so its name is noun, like Customer is the name for a class respresenting a customer.
A function (and method too) is a verb. It describes what it does, like getName() returns the name. get and set are common prefixes for functions that return or set a property. That's why they're even called 'getters' and 'setters'. A function name could also be saveCustomer to save a customer, or just save, if it is a method of the customer class.
With some basic rules like that, it should be easy to come up with a reasonable name, which you can always change using the refactory tools found in many editors.
Sometimes it is hard to find a good name. I'm not a native english speaker myself, while the code I write (and the comments) is in english, because it conforms more to existing libraries. Sometimes I find it hard to find the right word. In that case I use a disctionary or just Google to find a translation. Usually googling for 'WordInYourLanguage translation' will give you a list of entries on dictionary sites, from which you probably will recognize the right term.
Sounds a bit OCD to me...
Most of my code does not face a 2nd pair of eyes, so I sometimes name my variables things such as "BigBoobs"... At the end of the day, the only people that need to know the variable are you and anyone else who may be looking at the code...
As for seriously addressing your question:
I don't think there would really be a variable name generator out there, because that would involve it knowing what your program is actually doing as you do it. If technology like that exists, I guess I will be out of a job.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
My friend was asked the following question: what's the difference between object language and object-oriented language?
It's a little unintelligible question. What does term «object language» correspond to? Does that mean «pure» object-oriented language, like the Wikipedia article says:
Languages called "pure" OO languages, because everything in them is treated consistently as an object, from primitives such as characters and punctuation, all the way up to whole classes, prototypes, blocks, modules, etc. They were designed specifically to facilitate, even enforce, OO methods. Examples: Smalltalk, Eiffel, Ruby, JADE, VB.NET.
Unless the person was interviewed by a philosopher talking about an abstract metalanguage, or an old-school engineer talking about the end result a compiler produces, the question sounds like semantic masturbation by someone who doesn't speak the same language as the rest of the industry.
So in other words, the distinction is whatever the interviewer wants it to be. (Or perhaps the question was misheard). I don't think most developers would think that the terms are connected enough to be worthy of comparison and contrast.
The right response would probably be in the style of a psychoanalyst: What do you think it means? Ask clarifying questions to make sure you understand what the interviewer is asking and assuming. Then leave and don't call the employer back, because you don't want to work there.
The term object does not have an official, widely used or otherwise well-known definition.
The term object language does not have an official, widely used or otherwise well-known definition.
The term object-oriented does have an official definition, but that is usually completely ignored, not widely used nor otherwise well-known.
The term object-oriented language does not have a single official, widely used or otherwise well-known definition, it is usually understood to mean
a language in which object-oriented programming is possible or
a language in which only object-oriented programming is possible or
a language in which object-oriented programming is easy or
a language in which object-oriented programming is easy and non-object-oriented programming is hard or
a language in which everything is an object or
any combination of the above or
something completely different (and note that in any of the above you can substitute arbitrary definitions for "object" and "object-oriented")
In short: the interview question roughly translates to "what's the difference between this thing I'm not going to tell you what it is and that other thing I'm also not going to tell you what it is?"
I'd suspect that the interviewer was looking for a distinction between object-based and object oriented.
This is, for example, using structs in C, with no polymorphism or inheritance.
The difference between the two for C and C++ is highlighted here.