صحیح میفرمایید ، بنده مخالفتی با این موضوع ندارم و در واقع مثال DataSet از جانب بنده مطزح نشد ، در بسیازی از سازمانها هنگام طراحی معماری چند لایه بدینصورت عمل میشود که یکسری کلاس واسط میان DataSet و اشیاء آن و Class Consumer در سمت کلاینت ایجاد میگردد و اعضای تیم ارتباط مستقیمی با شیء DataTable ندارند و امکان آن وجود دارد که در آینده DataSet با یک شیء دیگر جهت دسترسی به داده جایگزین شده و از مدل دیگری جهت دسترسی به داده ها استفاده گردد ، در آنصورت تنها کافیست که کدهای Class Creator تغییر یابند.مایکروسافت هم زمانی که میخواست کلاس DataSet رو بسازه، مقرر کرد که خاصیت Tablesبه صورت public تعریف بشه، برنامه نویسان باید اینو بدونن که این خاصیت به صورت public وجود داره و هرگونه استفاده ی ناشایست از این کلاس(Tables) تبعات سختی رو متوجه برنامه شون خواهد کرد پس باید با چشمان باز از اون استفاده کنن، ولی این عمل ممکنه باعث سوء استفاده ی برخی از برنامه نویسان(حالا چه عمدی و چه سهوی) بشه، آیا تقصیر مایکروسافته که این خاصیت رو در DataSet به صورت public معرفی کرده ؟
پس ممکنه این کلاس به خاطر وجود اعضای public (و احیانا استفاده ی نابجا از این اعضا) در آینده مشکل ساز بشه!
برای رسیدن به یک هدف ، همواره یک روش بهتر وجود دارد ، همیشه باید روشی انتخاب گردد که کمترین میزان خطا را در حالت کلی و در هر شرایطی داشته یاشد و روش ذکر شده که مبتنی بر اصل Encapsulation میباشد ، در شرایط کلی ، نتایج بهتری را بدست میدهد و مشکلاتی که پیش از این ذکر شد را به وجود نمی آورد و به همین خاطر اگر بخواهیم منطبق بر قوانین OOP عمل کنیم و این دو روش را نسبت به هم بررسی کینم ، روش تغییر Modifier - مجددا" تکرار میکنم در حالت کلی - صحیح نخواهد بود ،ولی یه سوال، برنامه نویسان حرفه ای دنیا این شیوه رو پیشنهاد کردند یا شیوه های دیگه رو غلط معرفی کردند ؟
پ.ن : از مهدی ، حامد ، آرژنگ و linux به سبب شرکت در این بحث تشکر میکنم و امیدوارم از این دست گفتگوها در آینده بیشتر به وجود بیاید ،
پاسخ با نقل قول