Conversation
|
Overall I think it is necessary to have some layers of abstractions as it helps to reach the ultimate goal of the project which is support for multiple calendar system, but can you answer this question; In what ways this abstraction going to improve the project? |
|
Also in the side note I'm interested on your view of Remark and UserEvent, I see that you inherit both Remark and UserEvent from Event and doing the same for their DataStore. I think although some similarities exist they are different entities. |
اگر بخوام چندتا مثال به عنوان نمونه بگم که این لایههای abstraction چطوری به پروژه کمک میکنن، میتونم به اینا اشاره کنم:
۱- اگر نیاز باشه تقویم میلادی ساخته بشه، کافیه فقط یه پیادهسازی جدید از CalendarManager نوشته بشه. ۲- اگر نیاز باشه این امکان به پروژه اضافه بشه که کاربر بتونه رویدادهاشو بجای Google Calendar روی یه وبسرویس ذخیره کنه، کافیه فقط یه پیادهسازی جدید برای MutableEventDataSource نوشته تا رویدادهارو از وبسرویس گرفته و ثبت بشن. ۳- شاید کاربری دوست داشته باشه بجای رویدادهای رسمی کشور، رویدادهای مرتبط با دین زرتشت رو روی تقویمش ببینه. خودش میتونه یه پیادهسازی از EventDataSource بنویسه و بدون تغییر بخش دیگهای، تقویمی که دوست داره رو داشته باشه. پینوشت اول: البته این مدل نهایی نیست، مثلا برای مورد ۲ باید اینترفیسها بصورتی تغییر کنن که Async ساپورت باشن، الان همه رو بصورت Sync درست کردم. منظورم اینه که این یه مدل اولیه هست. |
من اینجوری در نظر گرفتم که هرچیزی روی تقویم داریم یه رویداد حساب (اینترفیس Event) میشه. فرق رویدادها فقط اینه بعضیهاشون قابل تغییر هستند و بعضیشون غیرقابل تغییر هستند. بخاطر این مدل نگرش برای نوشتن EventDataSource و MutableEventDataSource نیاز بود که Remark و UserEvent یه اینترفیس رو پیاده کنن.
البته به این هم فکرکردم جدا باشن. شاید حتی جدا باشن، پیادهسازی این مدل تمیزتر هم بشه. جزء چیزهایی هست که نیاز |
3bd1a31 to
bd2aefc
Compare
اضافه کردن لایههای انتزاعی به پروژه برای اینکه وابستگی بین کدها کمتر بشه، در نتیجه راحتتر بشه تقویم رو توسعه داد یا حتی از کدها در جاهای دیگه استفاده کرد.