Bir projem var. Bu projede bir özellik eklemek için yenilemek istedim ve özelliği eklemek için projeyi yeniden düzenledim.
Sorun şu ki, bittiğinde, uyum sağlamak için küçük bir arayüz değişikliği yapmam gerektiği ortaya çıktı. Ben de değişikliği yaptım. Ve sonra tüketici sınıf, yeni arayüzle mevcut arayüzüyle uygulanamaz, bu yüzden de yeni bir arayüze ihtiyacı var. Şimdi üç ay sonra ve hemen hemen hiç ilgisiz sorunları çözmek zorunda kaldım ve şu andan itibaren bir yıl boyunca yol haritası çeken sorunları çözmeye bakıyorum ya da bir şey derlenmeden önce zorluk nedeniyle çözmeyeceği için listeleniyor tekrar.
Gelecekte bu tür basamaklı yeniden yapılandırmalardan nasıl kaçınabilirim? Birbirimize çok sıkı bağlı olarak önceki sınıflarımın bir belirtisi mi?
Kısaca düzenleme: Bu durumda, refactor oldu refactor kodun belirli bir parçasının uzanabilirliliğinin arttığını ve bazı bağlantı azalmış beri özellik. Bu, dış geliştiricilerin daha fazlasını yapabileceği anlamına geliyordu, ki bu sunmak istediğim özellikti. Bu yüzden, orijinal refraktörün kendisi işlevsel bir değişiklik olmamalıydı.
Beş gün önce söz verdiğim daha büyük düzenleme:
Bu yeniden yansıtıcıya başlamadan önce, bir arayüze sahip olduğum bir sistem vardı, ancak uygulamada, dynamic_castgönderdiğim tüm olası uygulamalar aracılığıyla basitçe . Bu, açıkçası, sadece bir şey için arayüzden miras alamayacağınız ve ikincisi, bu arayüzü uygulamak için uygulama erişimi olmayan herkesin imkansız olacağı anlamına geliyordu. Bu yüzden, bu sorunu çözmek ve kamu tüketimine yönelik arayüzü açmak istediğime karar verdim, böylece herkesin bunu uygulayabilmesi ve ara yüzün uygulanmasının gerekli olan sözleşmenin tamamı olduğu açıkça görülüyordu.
Bunu yaptığım bütün yerleri bulup ateşle öldürürken, belli bir problem olduğu kanıtlanan bir yer buldum. Tüm çeşitli türetme sınıflarının uygulama detaylarına ve daha önce uygulanmış fakat başka bir yerde daha iyi olan çoğaltılmış fonksiyonelliğe dayanıyordu. Bunun yerine kamu arayüzü açısından uygulanabilir ve bu işlevselliğin mevcut uygulamasını yeniden kullanabilirsiniz. Düzgün çalışması için belirli bir bağlam parçası gerektirdiğini keşfettim. Kabaca konuşursak, önceki çağrının uygulanması gibi görünüyordu
for(auto&& a : as) {
f(a);
}
Ancak, bu bağlamı elde etmek için, onu daha çok benzer bir şeye dönüştürmem gerekiyordu
std::vector<Context> contexts;
for(auto&& a : as)
contexts.push_back(g(a));
do_thing_now_we_have_contexts();
for(auto&& con : contexts)
f(con);
Bu, eskiden bir parçası olan tüm işlemlerde, bir kısmının bağlamsız çalışan fyeni bir işlevin gbir parçası yapılması ve bir kısmının şimdi ertelenen kısmın bir kısmından yapılması gerektiği anlamına gelir f. Ancak, tüm yöntemlerin fbu içeriğe ihtiyaç duymadığını ya da istemeyeceğini - bazılarının ayrı yollarla elde ettikleri farklı bir içeriğe ihtiyaçları olduğunu söyleyin. Yani her şey için f(kabaca hemen hemen, konuşma hangi çağıran biter herşey ), onlar onu almalısınız ve eski onları bölmek nasıl nerede bağlam onlar gerekli varsa belirlemek zorunda fyeni içine fve yeni g.
Ve şimdi olduğum yerde böyle bitirdim. Devam etmemin tek nedeni, bu yeniden düzenlemeye zaten başka nedenlerle ihtiyaç duymamdı.