More generally encapsulation refers simply to bundling the data (e.g. of an object) with the operations on that data. So you have a class encapsulating data – fields – along with the methods for manipulating that data. But encapsulation is also sometimes used in the same way as your answer, and indeed, one of the … Read more
They serve a similar purpose (encapsulating data for another layer of the application) but they do it differently and for different reasons. The purpose of a DTO is to reduce the number of calls between tiers of an application, especially when those calls are expensive (e.g. distributed systems). DTOs are almost always trivially serializable, and … Read more
If you have circular dependency then you doing something wrong. As for example: foo.h —– class foo { public: bar b; }; bar.h —– class bar { public: foo f; }; Is illegal you probably want: foo.h —– class bar; // forward declaration class foo { … bar *b; … }; bar.h —– class foo; … Read more
No. Interfaces are good for classes with complex behaviour, and are especially handy if you want to be able to create a mock or fake implementation class of that interface for use in unit tests. But, some classes don’t have a lot of behaviour and can be treated more like values and usually consist of … Read more
Coupling Loose: You and the guy at the convenience store. You communicate through a well-defined protocol to achieve your respective goals – you pay money, he lets you walk out with the bag of Cheetos. Either one of you can be replaced without disrupting the system. Tight: You and your wife. Cohesion Low: The convenience … Read more
First off, these concepts are Platform Agnostic and are not exclusive to Spring Framework or any other framework, for that matter. Data Transfer Object DTO is an object that carries data between processes. When you’re working with a remote interface, each call it is expensive. As a result you need to reduce the number of … Read more
Many examples of Adapter are trivial or unrealistic (Rectangle vs. LegacyRectangle, Ratchet vs. Socket, SquarePeg vs RoundPeg, Duck vs. Turkey). Worse, many don’t show multiple Adapters for different Adaptees (someone cited Java’s Arrays.asList as an example of the adapter pattern). Adapting an interface of only one class to work with another seems a weak example … Read more
The main reason to use Fragments are for the backstack and lifecycle features. Otherwise, custom views are more light weight and simpler to implement. At first, I actually tried to build a phone/tablet app using custom views. Everything appeared to work across phones AND tablets, even switching from single panel to split panel. Where I … Read more
Utility classes aren’t exactly evil, but they can violate the principles that compose a good object-oriented design. In a good object-oriented design, most classes should represent a single thing and all of its attributes and operations. If you are operating on a thing, that method should probably be a member of that thing. However, there … Read more
Interfaces are just contracts or signatures and they don’t know anything about implementations. Coding against interface means, the client code always holds an Interface object which is supplied by a factory. Any instance returned by the factory would be of type Interface which any factory candidate class must have implemented. This way the client program … Read more