Hot answers tagged

43

So is there a reason why isn't this a OOP convention? My best guess: because it violates CQS You've got a command (changing the state of the object) and a query (returning a copy of state -- in this case, the object itself) mixed into the same method. That's not necessarily a problem, but it does violate some of the basic guidelines. For instance, ...


29

Saving a few keystrokes isn't compelling. It might be nice, but OOP conventions care more about concepts and structures, not keystrokes. The return value is meaningless. Even more than being meaningless, the return value is misleading, since users may expect the return value to have meaning. They may expect that it is an "immutable setter" public ...


12

I don't think this is an OOP convention, it's more related to the language design and its conventions. It seems you like to use Java. Java has a JavaBeans specification which specifies the return type of the setter to be void, i.e. it is in conflict with chaining of setters. This spec is widely accepted and implemented in a variety of tools. Of course you ...


8

In the MVC design pattern, the Controller part is responsible for translating user actions into modifications of the various Model classes that are involved in a piece of functionality. There is no one-to-one relation between Controllers, Views and Models. In particular, if a user action requires changes to multiple Model classes, then it is the ...


5

I think much of the reason it's not a convention to chain one setter after another is because for those cases it's more typical to see an options object or parameters in a constructor. C# has an initializer syntax as well. Instead of: DTO dto = new DTO().setFoo("foo").setBar("bar"); One might write: (in JS) var dto = new DTO({foo: "foo", bar: "bar"}); ...


5

Objects are models. They don't have to correspond to real-world objects. Sometimes actions need to be modelled. Take, for example, the typical Bank Account Scenario, that is used in many introductory OO courses. The design that is taught looks a bit like this: class BankAccount { Money balance; void deposit(Money amount) { balance += amount; } ...


5

As other people have said, this is often called a fluent interface. Normally setters are call passing in variables in response to the logic code in an application; your DTO class is a example of this. Conventional code when setters don’t return anything is normal best for this. Other answers have explained way. However there are a few cases where ...


5

That technique is actually used in the Builder pattern. x = ObjectBuilder() .foo(5) .bar(6); However, in general it is avoided because it is ambiguous. It is not obvious whether the return value is the object (so you can call other setters), or if the return object is the value that was just assigned (also a common pattern). Accordingly, ...


3

I'd argue no-ish. I'm not sure it's really the "module pattern" if you return anything other than a singleton. But, you can certainly use the same "pattern" to accomplish other things. The module protects the global scope from the internal variables used to build the return-value; but the return value can itself be a function -- including a constructor. To ...


1

Load them all in again … but make use of caching more generally in your application. Now you don't have to worry about double-loading. Congratulations: you've just written your first "scalable" application. :)


1

I do not know the pattern name (but it's probably using the Reflection pattern, see below), but many Web frameworks natively implement what your are trying to do here. For example if you look at Ruby on Rails, ActiveRecord and Mongoid are the components used to represent a Database entity, and programmers usually implement their model like this : class ...


1

This sounds like combination of strategy and composite patterns. Individual validators are strategy pattern. Then, composite is used to invoke multiple strategies as single one.


1

You're going to need an overflow area, perhaps a stack, or some chunk of memory. You'll also want to get the generated code correct before optimizing it, because optimizing broken code is basically impossible. So , given a stack, you should have something like: PUT b,2; Push b; Put b,7; Put c,3; ADD; Pop b; MUL and if using memory, PUT b,2; Store b @1; ...



Only top voted, non community-wiki answers of a minimum length are eligible