StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
16839487
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-05-30T14:58:09.280
FavoriteCount
0
LastActivityDate
2013-05-30T15:56:02.567
LastEditDate
2013-05-30T15:56:02.567
LastEditorUserId
463206
OwnerUserId
463206
ParentId
16836115
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
<blockquote> it make better sense to pass parameters </blockquote> In your example I think it does, but design intent clarifies the issue. <ul> <li>Allow maximum flexibility. This sacrifices encapsulation to some degree and is potentially more error prone for the client code.</li> <li>Is the <code>Class1</code> object immutable? I.E. does changing the current <code>URL</code> or <code>Proxy</code> of an existing <code>HttpRequest</code> make sense vice an all new <code>HttpRequest</code>?</li> <li>Guarantee a valid object state</li> </ul> Make a <code>HttpRequestBase</code> constructor requiring 2 parameters - the <code>URL</code> and <code>Proxy</code>. <pre><code>public HttpRequestBase (string url, IWebProxy proxy) { this.Proxy = null; this.URL = url; // how to handle null parameters? make defaults? throw exception? other? } </code></pre> Why a constructor? If <code>URL</code> and <code>Proxy</code> are central/essential to a (derived) <code>HttpRequest</code> - if the notion of a <code>HttpRequest</code> existing without them does not make sense then constructor parameters enforces that idea. If you don't want the client to arbitrarily change the object's <code>URL</code> and/or <code>Proxy</code> after instantiation. Why put this constructor at the base of the inheritance chain? Same reasoning. Why this instead of <code>Request()</code> method parameters? Same reasoning. Parameters make Flexible design As it is you "new-up" a proxy inside <code>HttpRequest</code>. This tightly couples <code>HttpRequest</code> to that proxy. I.E. every instance of <code>HttpRequest</code> must and will have the same proxy (state). What if that's not what the client code wants? What if you want to unit test (and you should) and you need to inject proxies and urls for testing? Instead let (force) the user to inject it via the constructor. Further, even if you intended this to be a default object (your public property <code>Proxy</code> leads me to this guess) loose coupling is more desirable. Encapsulation Encapsulation means that the client code does not need to know details of the class he's using. But in this case the client needs to know a whole lot about setting url and proxy. Does order matter? Why should he set proxy to null? Does he have to? Why does he have to? Does setting anything matter depending on what method he's calling? What must be set in order to call a particular method? blah, blah, blah. <blockquote> what is the purpose of the shared properties if i am not going to use them ? </blockquote> If you have no purpose for them, don't use them. But again, this goes to design intent. By "shared" I assume you mean <code>public</code>. In generic terms, to allow client code to customize the object (the object's state) at will. To the extent that you must not allow the client to shoot himself in the foot, don't. Your intent here may be for the client to set these values immediately after instantiation; or to never change them once set, but programming is not rainbows and unicorns. You need to bullet-proof your design as much as practical. As far as <code>private</code> or <code>protected</code> fields are concerned; to the extent that these are part of the essential being of a class then that's good. W/in that class they are simply there and passing these as "internal" method parameters is not as imperative as the public API.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POInheritance - passing parameters to method VS using inherited proprieties
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USradarbob
UserOwnerUserId
1. USradarbob
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.