Tag Info

New answers tagged

0

Use Factory(either factory method or factory object) to accept a version number(preferably enum, but string or numbers can also work) and construct the appropriate subclass. That way, naming won't matter that much since you'll never use them directly in the code. As for the naming themselves, if your language has namespacing you can create a namespace for ...


1

If you won't need to support the original version ever again, then simply overwrite the class and keep the same name. However, I suspect if it were that simple you wouldn't be asking. I'm a big fan of unambiguous names. Does the protocol specification have a unique identifier? Something like an RFC number? If so, I'd name it something like ...


3

There are two issues here: good naming, and the abuse of fluent interfaces. A good API has two jobs: It must be straightforward to write code using this API, and the function of the resulting code should be obvious to a reader. While fluent interfaces excel in the latter matter, languages that try to be overly English-like fail the former requirement. Any ...


2

well, "with" is a awkward name... "has" is a much better one. Has and Is are very well established terms, as is Get. You should use those terms as it makes discoverability easier - people are familiar with GetParent for example as returning a parent object. This makes it a good term to keep using. 'And' seems to be "return parent", but in your naming ...


1

your proposed method just doesn't look maintainable to me it's much easier to give Person a addCat and addDog method that does just that Dog dog = new Dog(); dog.addBone(); person.addDog(dog); this way you can also create the dog with its bones somewhere else without passing person to the bone factory.


4

The book is full of good stuff, but I would still add "I" to the interface name. Imagine you have public interface ILog with a default implementation public class Log. Now, if you decide to have public interface Log, all of a sudden you have to change Log class to public class LogDefault or something on those lines. You went from having one extra ...


0

Most answers seem to assume that the programming language is either Java or C# where there is a concept (or keyword) for interfaces / abstract classes. In these cases, in a decent IDE, it is immediately visible with which type of class one deals and writing public interface IMyClass is unnecessary duplication. It is like you wouldn't write public final ...


1

Ruby and its commonly used libraries and gems tend to blur the lines between method/property and key/property using attr_accessor, essentially giving an object both a property and getter/setter methods in one line. Either explicitly or implicitly, you'd have def tentacles_count @tentacles_count end def tentacles_count=(n) @tentacles_count = n end def ...


1

I would discard any MVC concepts and focus on what the interface means to you. From what little I know, IComplexActivity is a start. If there are no possible conflicts, you could reduce this to IActivity. That might be inviting trouble. IApplicationActivity makes it less general. You might consider smaller, composable interfaces as well. Golang favors ...


1

Just my opinion, but I would call it timestamp (or more precisely, modification timestamp), not revision. It is a timestamp, so when it's named timestamp, someone seeing the field can infer when the file was last changed, whereas when it's called revision, people might be confused to see a huge number, like 1395653358, when it's just the first or second ...


0

Revision to me is a count of how many times the object has been edited, and possibly even with an audit history. A timestamp though is just that, a stamp of he last time changed, often used for concurrency checks. I'd obsolete the old property and create a new one for the timestamp.


0

Revision implies that the field is updated when the object is changed. Revision does not necessarily imply that the field is a date/time, just that value is bumped each time the object is revised. Timestamp implies that the field refers to the date/time that something happened. What? That's not implicitly clear. Last change? Creation? Last time examined? ...


1

If it's simply a time stamp, and that is its only function, then call it a timestamp. If it has a larger purpose (i.e. Revision), then name it that. Generally, it is better to name things by their function rather than their type. As you yourself pointed out, the type can change over time.


1

I've done software development professionally in many different languages: C, C++, Java, Perl, C#, C++/CLI, Python and Objective-C. The more I use Objective-C, the more I like the clarity of its names. Non-altering methods are nouns named after the return type. -stringByTrimmingWhitespaceCharacters and -capitalizedString are both descriptive and are ...


0

I suspect the major problem is readability, and that your idea doesn't flow as well for objects. foo = capitalised(stripped(bar)) Seems perfectly reasonable English. But when you use objects, especially fluent ones, it starts to get less fluent: foo = bar.stripped().capitalised() Perhaps to Germans the fluent version would read better (but I don't read ...


1

It's a little blurry about what the direct object is supposed to be. By default, with no parameters, since "self" is an implicit first parameter, you'd expect the direct object of tenderize to be self. void MyObject.tenderize() myObject.tenderize() If you pass a parameter, it's reasonable to expect that parameter to be the direct object: void ...



Top 50 recent answers are included