Showing posts with label Architecture. Show all posts
Showing posts with label Architecture. Show all posts

Tuesday, August 9, 2016

Use lots of small simple classes instead of big complex classes

Favor complex network of simple objects over a simple network of complex objects
http://stackoverflow.com/a/2947823

That's one more voice in favor of the "tiny pieces" method of breaking down applications.


Tuesday, October 7, 2014

Big Ball of Mud and Intolerance of it

The following may be one of the most quoted paragraphs in software literature (my emphasis added):
A BIG BALL OF MUD is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.
http://www.laputan.org/mud/mud.html

Saturday, September 27, 2014

Getters/Setters is Fine-Grained Interface is good OOP?

Martin Fowler seems to agree with this notion by mentioning all three in the same breath in an article on the disadvantages of distributing objects.

from http://www.drdobbs.com/errant-architectures/184414966
A local interface is best as a fine-grained interface. Thus, if I have an address class, a good interface will have separate methods for getting the city, getting the state, setting the city, setting the state and so forth. A fine-grained interface is good because it follows the general OO principle of lots of little pieces that can be combined and overridden in various ways to extend the design into the future.

Saturday, September 7, 2013

Two-tier vs. N-tier

Two-tier approaches, while allowing more rapid development, are inherently less scalable than N-tier solutions (such as Web-based database solutions).[citation needed] In a two-tier solution, there must be one connection to the database for each concurrent user, whereas with N-tier solutions, which incorporate connection-pooling technology, a limited number of database connections - sometimes, just a single connection - are multiplexed among a much larger number of actual concurrent users.
http://en.wikipedia.org/wiki/PowerBuilder